We measure directly from the network side: server response time, page weight broken down by file type, request count, compression, browser caching, and the assets holding the page back from rendering. Every finding comes with a concrete fix.
*10 free checks per visitor per day, no sign-up.
Measure a page's speed and find what is weighing it down.
A number on its own does not make a website faster. What helps is knowing which file is heavy and which setting is not switched on.
TTFB - the time until the first byte arrives. It mirrors the speed of your hosting and the software behind the site.
The total bytes actually downloaded, split by type: HTML, CSS, JavaScript and images. The culprit shows up immediately.
How many files the browser has to fetch. More files means a longer queue - especially on mobile networks.
Checked on HTML, CSS and JS. This single setting usually cuts text size by 60-80%, and often turns out not to be on.
Which assets have no cache lifetime, forcing returning visitors to download the same files again.
Older protocols fetch files one at a time. Newer ones pull many at once over a single connection.
CSS and JavaScript in the head that hold the page back from appearing until they finish downloading.
How many images are already WebP/AVIF, how many are lazy-loaded, and how many lack width/height so the layout jumps.
Every redirect adds another round trip before the page even starts loading.
Nothing to install. It all runs on this page.
Pick the page visitors open most - your homepage or main service page. That is where a fix pays off most.
We download the page and its assets to measure their real size, so it takes a few seconds. The figures are real, not estimates.
Start with compression and caching - those two are usually just a change in hosting settings, and the effect is immediate.
So you know what is already safe and what needs chasing.
| Measure | Benchmark & What to Do |
|---|---|
| Server Response Time | Good under 0.5 seconds, watch up to 1.2 seconds, problematic above that. If it is slow, the cause is hosting, heavy plugins or the database - not images. Fix this before anything else. |
| HTML Load Time | Good under 1 second. This is the time until the whole HTML document arrives, not counting images and scripts. |
| Page Weight | Light under 1.5 MB, heavy above 3 MB. Images are almost always the biggest contributor - check the colour breakdown to confirm. |
| Request Count | Comfortable under 30 files. Above 60 starts to tell, especially on slow connections. Combine small CSS/JS files where you can. |
| Compression | Should be on for HTML, CSS and JS. This is the cheapest fix there is: usually one switch in the hosting panel or one line in .htaccess. |
| Browser Cache | Images, CSS and JS should have a long cache lifetime. The effect shows on returning visitors and on anyone who opens several pages. |
| Blocking Assets | Ideally zero. Add defer to scripts and move non-critical CSS so it loads later. |
| Image Format | WebP or AVIF is usually 25-50% smaller than JPG/PNG with no visible difference. This is often the biggest weight saving for the least effort. |
Visitors do not wait. A slow page loses people before the content is even read, and Google treats speed as one of its considerations. If the results above are too technical to tackle yourself, that part is what we handle.
Speed is the foundation. Here is what decides whether the page actually appears.
What people most often ask before using the tool.
TTFB (Time To First Byte) is the time from the request being sent to the first byte arriving from the server. It reflects the speed of your hosting and the software behind the site - not its images or design. Under 0.5 seconds is good. If TTFB is already slow, no amount of image or code optimisation will help much, because the visitor is already waiting before anything has been sent.
Not exactly, and we would rather be straight about it - the two measure different things. PageSpeed Insights runs a real browser to judge the visual experience, such as LCP and CLS. This tool measures from the network side: server response time, page weight, request count, compression and caching. They complement each other, and almost every fix suggested here will also lift your PageSpeed Insights score.
From our server in Indonesia. If your audience is in Europe or North America, treat the response time as indicative rather than exact, since network distance affects it - the same site will test faster from closer by. Page weight, compression, caching, protocol and render-blocking assets are location-independent, so those findings apply wherever your visitors are.
As a rule of thumb, under 1.5 MB is light and over 3 MB is heavy - particularly for visitors on mobile data. Images are almost always the largest contributor, so converting them to WebP usually gives the most noticeable result for the least effort.
Because we actually download each asset to find its real size, rather than guessing from headers. Many servers do not report file size correctly when the response is compressed, so this approach is far more accurate. Assets are capped at 30 files per check to keep it fast and avoid loading the site being tested - if the page has more, the figure is marked with a plus sign.
In order of effort against result: (1) enable gzip or Brotli compression, usually one switch in the hosting panel; (2) set browser caching for images, CSS and JS; (3) convert images to WebP; (4) add defer to JavaScript and loading="lazy" to below-the-fold images. If TTFB is the red one, those first three will not be enough - the hosting is what needs sorting.
Yes, as long as the page is publicly accessible. Comparing response time and page weight against a competitor often gives a quick sense of where you stand - and sometimes shows the problem is not at your end.
Free and no sign-up. Each visitor gets 10 checks per day. Results are only cached on the server for about 15 minutes so the same address is not measured repeatedly.
Send the address you measured and we will explain which fix will make the biggest difference first.
π Your details stay with us and are never shared with any third party
You are being redirected to WhatsApp. The Akudigital team is ready to help speed up your website.