Core Web Vitals are measured on your visitors, not in a lab

The three numbers Google uses

Google assesses each one at the 75th percentile of real page loads, using data from the Chrome User Experience Report (CrUX). A page needs all three in the good range to pass. INP replaced First Input Delay in March 2024.

A 99 in the lab, a fail in the field

A bilingual course store we look after had lab scores of 99 on desktop and 98 on mobile. Its SEO consultant flagged that the Core Web Vitals assessment was failing anyway. INP and CLS were fine. LCP for real visitors was 3.1 seconds on desktop and 3.0 on mobile, against a 2.5 second target.

A single lab run could not see the problem. Our diagnosis pointed at the server: the CrUX history showed its response time climbing from early May. The host’s application monitoring put a security plugin’s scan requests at the top of the list, and bot traffic was adding to the load. So the work was on the server side: firewall rules that challenge traffic from outside the countries the business serves and block bots probing for configuration files, a cache on the heaviest page, and the security plugin’s scans switched off while we measured.

Along the way, the mobile lab score dropped from 98 to 84. On September 11, our developer reported the mobile assessment passing in PageSpeed Insights. Desktop was close but still failing, and the consultant’s retest was still to come. The lab number and the number Google uses do not move together, which is why we now report both.

Our note to the client on how we would report it: “we’ll re-run PageSpeed Insights on the same URLs we used before so it’s a like-for-like comparison, and we’ll put the Cloudflare RUM numbers next to them.”

Where the time goes

Server response. If the first byte is slow, everything after it is slow. Uncached pages, bots, scheduled jobs and security scans all compete for the same server. Bot traffic has its own page: bot and AI crawler control.

The LCP image. The usual mistakes are a hero image that is lazy-loaded, one that is far bigger than the space it fills, and one the browser discovers late. On our own site the fix took three changes: we removed lazy loading from the hero image, added fetchpriority="high", and preloaded it. The image now starts loading 59 milliseconds into the page load.

Heavy files. A Florida contractor’s homepage came to us with a 20.5 MB hero image and a 42 MB video. Our rule of thumb: an image over 120 KB needs a reason, and a PNG over 2 MB becomes a WebP.

CSS and scripts. In a review of a Gutenberg build, we found 722 of 796 CSS declarations in an 86 KB stylesheet marked !important. The styling moved into the block editor’s global styles, where it belongs.

Images for high-density screens. Double-resolution images look sharp on retina screens and double the download for everyone else. For a software company whose images looked soft on retina screens, the answer was to serve the high-resolution versions only to screens that can use them.

INP: plugins buy points, structure sets the ceiling

One client site shows the whole arc.

In 2024, Search Console flagged INP above 200 milliseconds on 129 mobile pages. We removed a 500 KB reCAPTCHA script, an affiliate plugin and a session-recording script. Spam did not go up without the captcha, but INP improved only a little, and we told the client the real fix was structural: the page-builder theme itself.

In 2025, tuning a performance plugin lifted the homepage’s lab performance score from 32 to 92 on mobile and from 61 to 82 on desktop. In early 2026 the site failed its Core Web Vitals assessment again, and we found and fixed a layout shift in the hero.

The site is now being rebuilt, and every template has a performance budget: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, no regression against the old site’s baseline, first-load JavaScript under 200 KB and server response under 800 milliseconds. Lab results are the median of three runs, and field data from real visitors goes into analytics after launch.

Moving to a new platform? Take the baseline before you move. See website migration SEO.

CLS: reserve the space

Layout shift is usually something arriving late without space reserved for it: an image without dimensions, a font swap, or a bar or banner injected above the content.

• •Set width and height on images, or an aspect ratio in CSS. Our own site measures a CLS of 0 with CSS aspect ratios doing the work, but we still recommend both.
• •Give bars and banners a fixed height from the first paint. On a header redesign for a bilingual store, the brief requires a fixed, reserved height for the new utility bar for exactly this reason.
• •Don’t hide a shift behind a loading screen. We considered one on a project to mask text shifting during load. Our developer pointed out that it could make CLS worse, and we dropped it.

Speed work that breaks things

Caching is the biggest speed lever and the easiest way to break a site.

• •Forms and dynamic pages must skip the cache. After we moved a UK recruitment firm to new hosting with full-page caching, security “nonce” errors on job applications became far more frequent. The fix meant excluding the job pages from two separate caches: Cloudflare’s, and the host’s own server cache. More in nonce verification errors.
• •Carts and checkouts are never cached. On a tile store, a caching plugin was interfering with how the cart updated. More on stores in WooCommerce SEO.

What you get

1. 01A field baseline for each key template, from Search Console, PageSpeed Insights and real-user monitoring where it is available.
2. 02Lab runs on the same URLs, three runs each, with the median reported.
3. 03A list of causes ranked by impact and effort, not a list of 60 Lighthouse warnings.
4. 04The fixes, then the same URLs re-measured, field data next to lab data.
5. 05Ongoing monitoring on a maintenance retainer, so a plugin update or a traffic spike doesn’t quietly undo the work.

What we won’t do

We won’t chase a lab score of 100. We won’t promise rankings from speed alone. Core Web Vitals are one of the signals Google uses, and they will not lift a page above better content. The bigger reason to fix them is the visitors who give up while a page loads.

Sometimes the fix is a rebuild rather than a tune-up. When it is, we will say so. The rebuild described above started with a performance budget for every template. If your site needs the same, see our web design work.