The three measurements
| Measure | What it asks | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How long until the main thing on the page is visible? | Under 2.5 seconds |
| Interaction to Next Paint (INP) | When someone taps, how long before the page responds? | Under 200 milliseconds |
| Cumulative Layout Shift (CLS) | How much does the page move about while it loads? | Under 0.1 |
Source: Google's published Core Web Vitals thresholds
Two further measurements appear constantly in this conversation without being Core Web Vitals, and it is worth keeping them straight because the confusion is where a lot of bad reporting comes from.
- Time to first byte (TTFB) — how long the server thinks before it answers. Not a Core Web Vital, but the floor under all of them. If the server takes a second, nothing downstream can be fast.
- First contentful paint (FCP) — when the first pixel of content appears. Not a Core Web Vital either, but closely related to LCP and much easier to measure reliably from a single visit.
The five sites
These are the live sites, measured the same way on the same day, on their homepages. Every figure here appears on that client's case study page with the same source line.
| Site | TTFB | FCP | Full load | Requests | CLS |
|---|---|---|---|---|---|
| Pro Pave — bespoke WordPress, 27 pages | 0.05s | 0.56s | 0.68s | 11 | 0 |
| Beds.ie — 17,000+ product catalogue | — | 0.42s | — | — | — |
| CFC Wedding Lists — custom platform | — | 0.78s | — | 30 | 0 |
| Vehicles 2 Lease — WordPress | 0.19s | 0.89s | — | — | 0 |
| Roch Sweets — WooCommerce, 1,000+ lines | — | 0.86s | 1.27s | 71 | 0 |
Source: Browser Navigation Timing, Resource Timing and Layout Instability APIs, live homepages, 4 September 2026. Dashes are measurements not taken, not zeroes.
Three things are worth drawing out of that table, and one of them is a limitation.
- Cumulative layout shift is 0 on every site measured. This is the cheapest of the three to get right — reserve space for images and embeds, do not inject banners above content — and it is the one most commonly got wrong, which is why so many pages move under your thumb as you go to tap something.
- Request count tracks the build approach, not the content. Pro Pave renders from 11 requests because it is a bespoke theme; Roch Sweets needs 71 because it is a photography-led shop with a thousand product lines. Both are appropriate. A five-page brochure site needing 71 requests would not be.
- The server matters more than anything on the page. Pro Pave answers in 51 milliseconds and finishes loading in 0.68 seconds — the whole page, complete, in less time than many sites take to send their first byte.
How much do they matter for ranking?
Less than the tool that gives you a red score wants you to believe, and more than the developer who dismisses it wants you to believe.
Page experience is a real ranking input and a small one. It is a tie-breaker between pages of similar relevance, not a substitute for relevance. A fast page about the wrong thing does not outrank a slower page that answers the question. Nobody has ever won a competitive search term with performance alone.
The bigger effect is indirect and, in my experience, considerably more valuable. A fast, stable page is crawled more happily, keeps more of the visitors who arrive, and converts more of the ones it keeps. On a trade site opened at the kerbside on mobile data, the difference between 0.68 seconds and four seconds is not a ranking factor at all — it is whether the quote request happens.
So: fix performance for the conversion, and take the ranking benefit as a bonus. Prioritising it the other way round leads people to spend a fortnight chasing a lab score from 89 to 96 while their contact form is four fields too long.
How to measure your own, properly
- Start with field data. Search Console has a Core Web Vitals report drawn from real Chrome visits. This is what Google actually uses and it is free. If your site has too little traffic to report, that is itself a finding.
- Then run a lab test for diagnosis. PageSpeed Insights or Lighthouse will tell you what is slow and why. Treat the score as a diagnostic, not a target — the score is a weighted composite, and moving it is not the same as making the site faster for a person.
- Test on a phone, on mobile data, on the page people actually land on. Not the homepage on office wi-fi on a laptop. Every performance problem I have been shown looked fine under those conditions.
- Check time to first byte first. Under 200ms and the problem is in the build; over 600ms and you are compressing images on a server that has already lost.
- Re-measure after changes, and write the date down. A performance figure without a date is a claim about the past.
That last point is why every number on this website carries a date. Site speed is not a permanent property. It degrades — a plugin here, an unoptimised hero image there, a tracking script somebody added for a campaign in March. Measuring once and putting the result in a case study for ever is a way of being wrong slowly.
What actually makes a site fast
In order of effect, from doing this repeatedly rather than from a checklist.
- Build lean rather than optimise heavy. Pro Pave is fast because it is a bespoke theme rendering from 11 requests, not because a caching plugin was added to a page-builder site with 140. You cannot optimise your way out of an architecture.
- Fix the server. Managed hosting with proper caching is the single largest one-step improvement available to most WordPress sites, and it is a purchase rather than a project.
- Images. Correct format, correct dimensions, lazy-loaded below the fold, with width and height set so nothing shifts. This is the most common single cause of both slow loads and layout shift.
- Fonts. Loaded with a swap so text is never invisible, subset to the characters you use, and self-hosted or preconnected.
- Third-party scripts. Chat widgets, tracking, review embeds, cookie banners. Each one is somebody else's code deciding how fast your site is. Audit them yearly and remove the two nobody remembers adding.
- Reserve space for anything that loads late. Ads, embeds, banners. This is the whole of cumulative layout shift and it is close to free.
Notice that four of the six are decisions made when the site is built. Performance is much cheaper to build in than to retrofit, which is the practical argument for a lean build over a cheap one.
