Speed test your website: read the numbers that matter

A test run loads your URL in a real browser engine, records a timeline of network and rendering events, and distills that timeline into metrics. Everything on the report derives from timestamps: when the first response byte arrived, when the first pixel painted, when the largest visible element finished rendering, and how much the layout jumped around while loading.

There is a crucial distinction between lab data and field data. A speed test is lab data: one synthetic load, from one location, on one simulated connection. Google's ranking signal, by contrast, comes from field data — the Chrome User Experience Report, which aggregates real visitor sessions over a trailing 28-day window. Lab and field can disagree. A page can test fine from a datacenter on fiber while real users on mid-range phones over cellular see a five-second render. Use lab tests for diagnosis and iteration, and treat field data as the scoreboard that actually counts.

That also explains why lab numbers are deliberately pessimistic. Tests typically throttle the connection and CPU to approximate a mid-range mobile device, because that is closer to the median visitor than your development machine. A page that passes under throttling has headroom everywhere.

TTFB, time to first byte, clocks the span from navigation start to the first byte of the HTML response. It bundles DNS lookup, the TCP handshake, TLS negotiation, and server think-time. Nothing can render before the HTML arrives, so a slow TTFB drags every downstream metric with it. As a working guideline, under 200 ms is excellent, under 800 ms is acceptable, and anything past that points at hosting, an uncached CMS response, or a missing CDN.

LCP, largest contentful paint, marks when the largest image or text block in the initial viewport finishes rendering — the moment the page looks loaded to a human. The browser tracks render times of candidate elements and reports the largest one standing when loading settles. Google's threshold for good is 2.5 seconds. In practice, the LCP element is a hero image or headline, and its render time decomposes into TTFB plus resource discovery plus download plus render — which is why the fixes are things like preloading the hero image and shipping it as WebP or AVIF instead of a 1.2 MB JPEG.

CLS, cumulative layout shift, is the odd one out: a unitless score, not a duration. Every time visible content moves without user input — an image loads and shoves the paragraph down, a late banner appears — the browser multiplies the fraction of the viewport affected by the distance things moved, and sums these shifts over the worst burst. Good is 0.1 or below. The usual culprits are images without width and height attributes, web fonts swapping late, and ad slots with no reserved space.

Responsiveness is measured by INP, interaction to next paint, which replaced first input delay as a Core Web Vital in March 2024. INP observes every tap, click, and keypress during a visit and reports roughly the worst latency between input and the next painted frame; 200 ms or less counts as good. Because INP needs real interactions, a lab test can only approximate it through proxies like total blocking time — heavy JavaScript main-thread work is the thing both are detecting.

Read the metrics in causal order, because upstream problems masquerade as downstream ones. Start at TTFB: if it is 1.5 seconds, fix that first — page caching on your CMS, a CDN in front of the origin, or better hosting — and re-test, because a slow first byte inflates FCP and LCP mechanically. Optimizing images while TTFB is broken is polishing the wrong end of the pipeline.

If TTFB is healthy but LCP is not, the gap between FCP and LCP tells you where to look. A large gap means the main content itself is slow: almost always an oversized hero image, cured by compressing it, serving modern formats, sizing it to the actual display dimensions, and adding a preload hint so the browser fetches it immediately instead of after parsing the CSS. A small gap with both metrics late means rendering is blocked before anything paints — render-blocking stylesheets and synchronous scripts in the head.

CLS fixes are the most mechanical of the lot: give every image and video explicit dimensions, reserve fixed-height containers for ads and embeds, and load web fonts with font-display swap plus a well-matched fallback. Poor INP or high total blocking time points at JavaScript — typically a tag manager hauling a dozen third-party scripts, which no image optimization will ever fix. Defer what you can, delete what nobody remembers adding, and be ruthless about chat widgets on pages where nobody chats.

One fix at a time, one re-test per fix. Batch three changes together and you cannot tell which one produced the improvement — or which one quietly made CLS worse.

Paid traffic landing pages. If you buy Google Ads, landing page experience feeds your Quality Score, and slow pages raise your effective cost per click while bleeding conversions on top. Testing the exact URL you point ads at — not the homepage — routinely surfaces a marketing page built on a heavyweight page builder that nobody ever profiled.

Ecommerce product pages. Product templates carry galleries, reviews widgets, size charts, and recommendation carousels, and they are where the money is. Test your best-selling product's page on mobile settings. A product photo shipped at 4000 pixels wide for a 400-pixel slot is the most common single finding, and fixing the template fixes every product at once.

Regression checks after changes. Test before and after installing a plugin, switching themes, or adding a marketing tag. A single A/B testing snippet can add half a second of render-blocking delay; catching that the day it ships is a two-minute rollback, while discovering it in a quarterly audit means archaeology.

Competitor benchmarking. Run the same test against the two or three sites that outrank you. If they render in 1.8 seconds and you render in 4.5, you have found a concrete, fixable gap. If you are already faster, stop investing in speed and spend the effort on content — the test just saved you a month of misdirected optimization.

Two consecutive runs of the same page will not produce identical numbers, and that is expected. Your server's load varies moment to moment, a CDN edge node may serve one run from a warm cache and the next from cold, third-party scripts respond in variable time, and network jitter adds noise everywhere. Treat any single run as one sample: run three and reason from the median, and only believe differences bigger than the spread between your own runs.

Different tools disagree for structural reasons, not because one of them is lying. Test location changes TTFB by hundreds of milliseconds — a US-east server tested from Frankfurt pays a transatlantic round trip on every request. Throttling profiles differ between tools, desktop and mobile modes differ within the same tool, and field data differs from all of it because real visitors carry real devices on real networks. Pick one tool and one configuration as your baseline and track direction over time; cross-tool score comparisons are noise dressed up as data.

The habit that makes speed testing useful is consistency: same tool, same mode, a median of three runs, recorded after every meaningful site change. Direction is the signal — a page drifting from 2.1 to 3.4 seconds over six months of plugin accretion is a trend worth acting on, whatever the absolute number.