The speed score you're optimising isn't the one being graded

Two numbers, and only one of them is graded

Run your homepage through PageSpeed Insights, get a 98, and find the Core Web Vitals assessment on the same report marked Failed. Google’s own Search Central forum carries thread after thread with that title, some of them about Search Console flagging the same pages as Poor. Both numbers are working as designed. They measure two different things, and only one of them decides anything.

The 0-to-100 score in a PageSpeed report is a Lighthouse score. Lighthouse loads your page once, on an emulated mid-tier Android over a throttled connection, and scores five lab metrics against a curve: First Contentful Paint at 10%, Speed Index at 10%, Largest Contentful Paint (LCP) at 25%, Total Blocking Time (TBT) at 30%, and Cumulative Layout Shift (CLS) at 25%. It’s a benchmark: repeatable, fast, and genuinely useful for catching a regression before it ships. It describes a machine in a lab, and your visitors are somewhere else.

The assessment is field data: real Chrome users on your real pages, aggregated into the Chrome User Experience Report. Three metrics there, not five. LCP, Interaction to Next Paint (INP) and CLS. Good means 2.5 seconds or less, 200 milliseconds or less, and 0.1 or less, taken at the 75th percentile across a rolling 28-day window.

That percentile is worth sitting with. Line up every page load from best experience to worst, and your number is the one three-quarters of the way down. Your typical visit sits halfway, so the grade is set by a worse one.

Nothing about those three thresholds has changed, which needs saying because the search results on this topic currently suggest otherwise. Several well-ranking articles describe a fourth metric called Engagement Reliability, and an LCP threshold tightened to 2.0 seconds in a March 2026 update. Google’s documentation describes three stable metrics at the numbers above, and commits to changing them no more than once a year through a public changelog. What actually shipped recently is narrower and more interesting: Chrome 151, released on 28 July 2026, emits a performance entry when it detects a route change inside a single-page app. That gives developers one standard way to measure the in-app navigations these metrics have always struggled to see. How Chrome’s field data will count them is still undecided.

Read the field data first, then look at the lab

Open PageSpeed Insights and skip the score. The panel above it is the one that matters, and the line to read first is the one telling you whether this data covers your URL or the whole origin.

If it says origin, that page doesn’t have enough traffic to qualify for its own field data, and you’re reading a site-wide average with your page somewhere inside it. Search Console does something similar and less obvious: it groups URLs into pages with a similar user experience and applies one verdict to the whole group. So a group can fail on the strength of pages you’ve never opened, and pass on the strength of one page that gets all the traffic.

This is where an expensive mistake in site-speed work begins. A team tests the homepage and calls it done. The homepage is the page with enough traffic to have its own field data, and it’s the page everyone looks at, so it gets the attention. Category and product pages run on different templates and carry more of the buying decision, and they get judged as part of a group nobody measured directly.

So before touching anything: pull your top ten pages by impressions out of Search Console, run each one through PageSpeed Insights, and write down which ones return URL-level field data and which fall back to origin. The second list is the set of pages you’ve been flying blind on. If a template is represented there, test one page from each template rather than ten of the same shape.

Fix in the order the failing metric dictates

The insights list in a Lighthouse report (called opportunities before Lighthouse 13) is sorted by how much each fix is estimated to lift the lab score. It is not sorted by what’s failing in the field, and following it top to bottom is how a month disappears into shaving 400ms off a metric that was already passing.

Order the work by what the field data says is failing, and be strict about it. One metric failing means you work that metric and leave the others alone. When LCP fails alongside anything else, start with LCP: its fixes are the least tangled, and the ones aimed at render delay, deferring render-blocking script and breaking up long tasks, take work off the main thread, which helps INP on the way past. When the pair is INP and CLS, clear CLS first, because its fixes are a short list. Nothing failing means stop. Moving a lab score from 92 to 97 buys you nothing a customer can feel and nothing Google grades.

The reason order matters this much is the feedback loop. Field data is a 28-day rolling window, and Search Console’s validation runs a 28-day monitoring session before it will confirm a fix. So a change you ship on Monday starts influencing the number gradually, and you get a clean read on it roughly once a month. That is the whole budget: 365 days at one clean read per 28 comes to about thirteen measurable attempts a year. Spend them in the right order.

LCP: most of it happens before the image

Start here if LCP is failing alongside anything else. The obvious suspect is the hero image, and Google’s field data points further back. In its 2024 analysis, the median site with poor LCP waited 2,270ms for the first byte and another 1,290ms before the LCP image started downloading, then spent 350ms downloading it and 360ms rendering it. At every level of LCP Google looked at, the download was the shortest of those four parts.

So check TTFB first. A slow first byte comes from uncached database work, a redirect chain in front of the page, or a host that’s simply far from the person asking. If you sell into more than one country, that last one is worth settling before you spend money on hosting, because the answer changes a lot between markets.

Then make the LCP element easy to find and quick to fetch. It should be present in the initial HTML rather than injected by script, and it should never be lazy-loaded. Lazy-loading tells the browser to defer the exact element the metric is timing, which makes it an optimisation that reliably makes the number worse. Add fetchpriority="high" to it so it doesn’t queue behind less important requests. Compress it properly, serve it at the size it’s displayed, and give it real dimensions.

Fonts belong in that same fetch. When the largest element is text set in a web font, that font is the resource LCP waits on, and a font that blocks text from painting holds the metric back until it loads. Arabic makes this harder than most performance guidance assumes: every letter needs up to four contextual forms plus ligatures, so the glyph set runs to many hundreds, and the tables that substitute and position those glyphs have to travel with them. You can’t trim that the way you drop unused Latin characters. Subset to the ranges the page actually uses, serve WOFF2, preload only the face that renders above the fold, and let the rest arrive late.

The last stretch is render delay, the gap between the resource finishing and the element painting. Render-blocking stylesheets, synchronous scripts and long tasks on the main thread all widen it, so defer the script that can wait and break up the tasks that can’t.

INP: the one your tool can’t show you

INP comes last whenever another metric is failing with it. Here’s the awkward part: INP is not in the Lighthouse performance score at all. The 30% slice belongs to Total Blocking Time, which is a lab stand-in, and Google says plainly that some lab tools can’t report INP because they watch a page load without ever interacting with it.

INP measures the lag between a user acting and the screen updating, across every interaction on the page, and reports close to the worst one. Only clicks, taps and key presses count; scrolling and hovering don’t. Each interaction breaks into three parts: the input delay before your handler can start, the processing duration while it runs, and the presentation delay before the next frame paints. Which part dominates tells you what to fix, and they need different fixes.

When input delay dominates, the main thread was already busy when the user tapped: scripts still loading and compiling, timers firing, or an earlier interaction still being handled. Some of those scripts and timers can belong to third parties you don’t control, which puts auditing what’s actually loading on the page on the INP list next to anything you’d recognise as performance work. A long processing duration means the event handlers, every one that runs for that interaction, are doing too much in one go, so split the work, defer whatever isn’t needed for the visual response, and let the frame paint before the rest runs. And presentation delay points somewhere else again, at a browser left with too much layout and paint work once the handler had finished.

To see any of this, you need to interact while measuring. Record a DevTools performance trace with CPU throttling on and actually use the page the way a customer does: open the menu, apply a filter, add to cart. Or instrument the page with a real-user monitoring script that reports INP with attribution, which is the only way to learn which element is slow for people who aren’t you.

CLS: a short list, done properly once

Layout shift is the most tractable of the three. The fixes are well understood, they don’t require judgment calls, and once they’re in place the metric stays solved until something new goes live without them. That’s why it goes first when it fails alongside INP.

Every image and video needs explicit width and height attributes, or an aspect-ratio, so the browser can hold the space before the file arrives. The same goes for anything that arrives late and pushes content around: embeds, consent banners, promotional strips, ad slots. Fonts want a different treatment again. Match the fallback’s metrics to the real face with size-adjust and ascent-override so the swap doesn’t reflow the paragraph underneath. That matters in bilingual builds, where the fallback and the brand face can differ wildly in height.

One detail that catches people out: CLS is not a loading metric. It takes the largest burst of shifts anywhere in the page’s life, where a burst is shifts less than a second apart inside a five-second window. A shift within half a second of a click, tap or key press is left out, since the visitor asked for it. What counts is the shift that comes later or unprompted: filter results that reflow the grid after a slow fetch, a sticky bar that appears mid-scroll, a recommendations block that loads in above the text someone is reading. If your CLS is poor and the load looks clean, go and use the page.

Test on the network your buyers actually have

Lighthouse simulates a specific connection: 1.6 Mbps down, 750 Kbps up, 150ms round trip, with the CPU slowed by a factor of four. PageSpeed Insights uses the same profile. Lighthouse’s documentation says it represents roughly the slowest quarter of 4G, about the 85th percentile of mobile connection speeds. Every run simulates the same network, so treat the result the way you’d treat a dynamometer reading rather than a lap time.

That network is a long way from the GCC in particular. The UAE has been at or near the top of Ookla’s global median mobile download rankings, and the region generally runs well ahead of it. Reading the lab number as “what a real user sees” gets it backwards here. For a visitor on a good connection and a recent phone the simulation is far too harsh; for someone on an older budget Android it’s too kind, because the fixed 4x slowdown is set to bring a fast desktop down to a mid-tier phone, and theirs is slower than that. The score can’t tell you which of your visitors is which.

What we’d plan for instead is the spread between your best-served visitor and your worst, because the 75th percentile sits inside it and that’s the point you’re graded on. A budget built around the typical visitor will tell you you’re fine right up until the slower quarter of your traffic is the part that stopped buying.

So use the lab for what it’s good at: a stable before-and-after on a change you control, run the same way each time. Use field data for the verdict, segmented by device and by country if you sell in more than one. And where speed turns out to be genuinely fine, the leak is somewhere else in the journey: the checkout is the next place to look, and on a bilingual site, so is the Arabic version of the page, which needs its own review cycle.

Our Site Audit will tell you which of the three metrics your site is failing and on which templates, which is enough to pick where to start. What it can’t do is watch you use your own site, and for INP that’s still the step that finds the answer.

Standing offer

The hard part is deciding what to do first

Bring us a URL, an audit report, or a proposal you're not sure about. We'll tell you which problems deserve budget this quarter, and you'll leave with an order of operations you can hand to whoever does the work, whether that's us or not.

Book twenty minutes