October 08, 2026
"Core Web Vitals assessment: Failed" at the top of a PageSpeed Insights report means that real visitors to your site, measured over the last 28 days, had a poor experience on at least one of three numbers: Largest Contentful Paint (how long the main content takes to appear), Interaction to Next Paint (how quickly the page responds to a tap) and Cumulative Layout Shift (how much the page jumps while loading). It is a verdict on field data, which is what people's phones actually reported, and not on the lab test that sits underneath it in the same report.
That distinction matters more than anything else on this page. The lab test is a simulation on one throttled device. The field data is your visitors. They regularly disagree, and this week our own site was the example.
Our mobile lab run reported LCP 5.5 s, Total Blocking Time 359 ms and CLS 0.251, all of them in the red. Desktop on the same day was LCP 1.4 s and CLS 0.004. Then we ran the same page on a real phone on a throttled connection and measured CLS 0.006. The lab number was forty times the real one, and if we had spent a day chasing it we would have fixed nothing that a visitor could feel. The right order is: read the field data, find which metric is actually failing, then use the lab to find the cause.
Because there is not enough field data. The assessment is built from the Chrome User Experience Report, which collects anonymous measurements from Chrome users who opted in. If your page, or your whole site, does not get enough of those visitors in 28 days, PageSpeed Insights says there is no data to show and skips the assessment altogether. That is normal for a new site, a low traffic page or a site with mostly non Chrome visitors.
Two things follow. First, "no assessment" is not a pass and not a fail; it means Google has not measured you yet, and the lab numbers are all you have. Second, PageSpeed Insights sometimes shows origin level data (the whole domain) when the single page has too little traffic. The report says which one you are looking at in a small line above the numbers, and it is worth reading, because a homepage can be failing while the origin passes and the other way round.
Three places, in this order.
Search Console, Core Web Vitals report. This groups your URLs into poor, needs improvement and good, for mobile and desktop separately, using the same field data. It is the only view that tells you which pages are pulling the site down, which is what you need before fixing anything. A site can fail because of one template (say, every product page) while the homepage is fine.
PageSpeed Insights, for a single URL. Read the top block first (field data, 28 days). Only then read the lab block below it. Treat the lab as a diagnostic that points at causes, not as a score to be improved for its own sake. The "Diagnostics" list under the lab result is where the useful detail lives: which element was the LCP, which scripts blocked the main thread, which elements shifted.
A real phone on a throttled connection. Chrome's DevTools has a performance panel that records LCP, INP and CLS live as you scroll and tap, and can throttle the network and CPU to mimic a mid range Android phone on a patchy 4G connection. This is the test that told us our lab CLS was wrong. We run it on every site before launch, and it is worth ten lab scores.
Thresholds are the same everywhere: LCP good under 2.5 s, poor over 4 s. INP good under 200 ms, poor over 500 ms. CLS good under 0.1, poor over 0.25. The assessment uses the 75th percentile, so three out of four visitors must be in the good range for a metric to pass.
Find the LCP element first. PageSpeed Insights names it in the diagnostics; on most business sites it is the hero image, a background image, or a large heading waiting for a web font. Every LCP fix is about getting that one element on screen sooner.
If it is an image, the usual causes are size and discovery. Size: a 2,400 pixel photo served to a 390 pixel phone screen. The fix is responsive images with WebP variants at several widths so the phone downloads the small one. Discovery: the browser learns about the image late because it is a CSS background or loaded by a script. The fix is a plain img tag in the HTML with a preload hint, and never lazy loading on the hero.
If it is text, the page is waiting on a font. Preload the one weight the heading uses, use font-display swap so the text appears in a fallback face while the web font arrives, and question whether the hero needs a web font at all.
If everything is late, the server is slow to answer. Time to first byte over 800 ms on shared hosting is common in India. Caching the page output, moving to hosting closer to the visitors, and putting a CDN in front all help, and are covered in the loading speed article this one links to.
Our own 5.5 s lab LCP was mostly a hero animation and render blocking scripts on a simulated slow device, while the field figure was comfortably better. Still, 141 KB of unused JavaScript was real and got removed, because the lab is right about causes even when it exaggerates the effect.
INP replaced First Input Delay in 2024 and is stricter: it measures the slowest tap or key press over the whole visit, not just the first one. A page that scores well on load and then freezes for half a second when the menu opens fails INP.
The cause is almost always JavaScript doing too much on the main thread. Three common shapes. A large bundle still parsing while the visitor taps, so the tap queues behind it. A tap handler that does heavy work (filtering a big product list, rebuilding the whole page) before it paints anything. Third party scripts, chat widgets, analytics, tag managers, each taking their slice of the thread.
Fixes, in the order that usually pays. Remove scripts you do not use; the unused JavaScript audit in PageSpeed lists them. Load the rest after the page is interactive, and load widgets such as chat only when the visitor scrolls near them or after a delay. Split heavy interactions so the page paints a response first (the menu opens, the button changes state) and does the work afterwards. Keep animation on the compositor: transform and opacity, not width, height or top.
Total Blocking Time is the lab stand in for INP, which is why our 359 ms mattered even though INP is only measured in the field. Under 200 ms TBT in the lab usually means INP passes for real visitors.
CLS counts every time something on the page moves after it has been painted, weighted by how far it moved and how much of the screen it took. The visitor experiences it as the button that jumps just as they tap it.
The usual causes are predictable. Images and embeds without width and height attributes, so the browser reserves no space and the text jumps down when they arrive. Web fonts that swap in with different metrics and push every line. Banners, cookie notices and ads injected above content that has already rendered. And animations that move elements into place from off screen, which the lab can score as shifts even when a real visitor sees a smooth reveal.
The fixes match one to one. Put width and height on every image and iframe, or an aspect ratio in CSS. Use size adjusted fallback fonts so the swap does not reflow. Reserve the space for anything injected, or inject it at the bottom. Animate with transform, which does not count as a shift, and give reveal animations a starting state that occupies the same box.
This is where our lab and field numbers split. The lab saw 0.251 because of how it captured reveal animations on a simulated slow device; the throttled real device saw 0.006 because the animations occupy their boxes from the first paint. Before rewriting animation code, confirm the shift in Search Console or on a real phone. Fixing a CLS that only exists in the lab is a day lost.
Measure before launch, not after. Every site we build is run through PageSpeed and a throttled real device test before it goes live, on the templates that matter most: home, a category, a product, a contact page. Fixing a template fixes every page built on it.
Set a budget and hold the line. A homepage under 1 MB on mobile, no more than a handful of third party scripts, every image in WebP with size variants, fonts limited to two weights. Most regressions come from the months after launch: a new slider plugin, a chat widget, a video embed, a 4 MB banner uploaded from a phone. The budget is what you check new additions against.
Watch the field data monthly. Search Console's Core Web Vitals report changes slowly, since it is a 28 day window, so a fix takes up to a month to show. Our SEO reports carry it alongside the search numbers, because a page that slips from good to poor tends to slip in rankings a little later.
Page experience is a ranking signal, but a small one next to content and links. A failing site with the best answer still outranks a passing site with a thin one. What a failure does reliably is lose visitors before they read anything, which costs more than the ranking effect.
The lab test runs on a shared machine with simulated throttling, and small differences in the moment of the run produce different numbers. Treat any single lab run as a rough guide. Run it three times, and trust the field data and a real device over all of them.
Field data is a rolling 28 day window, so the assessment fully reflects a fix about a month after it goes live, and starts moving within a week or two. The lab score changes immediately, which is one more reason the two disagree.
Yes, and it is the common case. Our own site this week was LCP 1.4 s on desktop and 5.5 s in the mobile lab. Mobile devices are slower, connections are worse, and the assessment is reported separately for each, so always read the mobile tab first.
Sign in with Google to join the conversation. We use it for your display name and nothing else, and your email address is never shown.
No comments yet. Sign in above to write the first one.