Website Speed Test

It measures how fast a site's server responds. We request the page's HTML document from our server and time the round trip: DNS resolution, time to first byte, total time to receive the document, its size, any redirects along the way, and whether compression and caching headers are set. We then read the returned HTML and count how many images, scripts, stylesheets and external resources the page asks the browser to fetch.

Worth being clear about the boundary: we time and measure the HTML document itself — the referenced images, scripts and stylesheets are counted but not downloaded. So the reported size is the size of the HTML, not the full weight of the finished page.

Because most of them measure something different. Browser-based tools load the page in a real (often throttled) browser and report rendering metrics such as Largest Contentful Paint and Cumulative Layout Shift. Those numbers depend heavily on the simulated device, connection speed and test location.

This test measures server responsiveness from a fixed location with no throttling, so the figures are cleaner and far more repeatable — but they answer a narrower question. Use this to check whether the server and network are healthy, and a browser-based test to judge the visitor's rendering experience. Slow results here mean the problem is upstream of the browser, which is the more valuable thing to know first.

Time to First Byte is the delay between the request being sent and the very first byte of the response arriving. It covers DNS lookup, connection setup, TLS negotiation and — usually the largest share — the time the server spends generating the page.

• Under 200ms: excellent.
• 200–600ms: good. Google's guidance is to keep TTFB under 600ms.
• 600ms–1s: needs attention.
• Over 1s: a real problem — everything else on the page is stuck waiting.

TTFB matters disproportionately because nothing can start rendering until it completes. A second of TTFB is a second added to every single metric downstream.

In rough order of impact for most sites:

• Add full-page caching. Serving a pre-built page instead of assembling it per request is usually the single biggest win, often cutting TTFB by an order of magnitude.
• Fix slow database queries. Missing indexes and queries running inside loops are the classic culprits.
• Put a CDN in front of the site. This shortens the physical distance to the visitor, which matters greatly for international traffic.
• Upgrade cheap shared hosting. On oversubscribed servers you are competing for CPU with hundreds of other sites, and no amount of code tuning fixes that.
• Eliminate redirect chains. Each hop is a full extra round trip before the real page even begins.

If TTFB is high but the server itself is not busy, check the TLS setup with the SSL certificate checker. An incomplete certificate chain forces every client to fetch the missing intermediate before the connection can finish, and that delay lands squarely inside TTFB.

Under two seconds is a sound target, and under one second is excellent. The evidence on abandonment is consistent: bounce rates climb steeply between one and five seconds, and mobile visitors are the least patient.

Judge yourself against your competitors rather than an abstract benchmark. Being a second faster than the other results on the same search page is worth more than hitting a round number.

Yes, but its weight is often overstated. Google uses page experience signals, including Core Web Vitals, as a ranking factor — and has said plainly that relevance wins: a slow page with the best answer will still outrank a fast page with a worse one.

Speed works mainly as a tie-breaker between pages of comparable quality, and as an indirect factor through user behaviour. Visitors who abandon a slow page never convert, never link to it and never return, and those signals compound. Fix speed because it affects revenue and retention; treat the ranking benefit as a bonus.

Aim for under 1MB in total transfer for a content page; under 500KB is very good. Images are almost always the bulk of it, followed by JavaScript.

The quickest wins are switching images to a modern format such as WebP or AVIF, serving them at the size they are actually displayed rather than full resolution, lazy-loading anything below the fold, and auditing third-party scripts — analytics, chat widgets, ad tags and A/B testing tools routinely add more weight than the site's own code.

Some variation is expected. Common causes are cache state (the first request may miss a cache the next one hits), current server load, network routing differences between runs, and dynamic pages that do more work for some requests than others.

Run the test three or four times and take the median rather than trusting a single result. Consistently wide swings are themselves a finding — they usually point to an overloaded server or unreliable hosting.

Most failures are not speed problems. The usual reasons are a bot-protection or firewall layer blocking automated requests, a login-only page, a server too slow to answer within the timeout, an invalid or expired TLS certificate, or a URL that redirects somewhere unreachable.

If a browser loads the page fine but this test cannot, a security layer is almost certainly filtering the request — which is working as intended on their side, not a fault on yours.