What your customers actually experience on your store

Largest Contentful Paint answers whether the page appears before patience runs out. Interaction to Next Paint answers whether it responds when a thumb taps. Cumulative Layout Shift answers whether it holds still while being read. Google publishes thresholds for each, and the tool colours the result against them. The number to watch is the one furthest from its threshold, not the average — a store with a good LCP and a terrible INP feels broken to shoppers even though two thirds of the metrics look fine.

• LCP: does the main content appear quickly
• INP: does the page respond when tapped
• CLS: does the layout stay still while loading
• Fix the worst metric first, not the easiest one

Not every site has it, and that is not a failure. The Chrome UX Report only reports origins with enough traffic to anonymise the sample, so newer or smaller stores show nothing. If that is you, the lab run is still useful for diagnosis, but treat it as a simulation rather than a verdict, and remember that it says nothing about the devices your particular customers use. The honest version of this tool tells you when it cannot see your customers, rather than presenting a lab score as if it could.

Where a specific URL has enough traffic of its own, the result describes that page. Where it does not, the tool falls back to origin-level data — an aggregate across your whole site — and says so. Origin data is still meaningful, but it averages your homepage together with your product pages, and on most stores those perform very differently. If you want a template-level picture, check a category URL and a product URL separately rather than trusting a single origin number.

They almost always do, and neither is lying. The lab run uses one simulated device on a throttled connection with no cache, no cookie banner interaction and no logged-in state. Your real visitors arrive on a spread of devices and networks, some with a warm cache, many with a consent dialog in the way. A green lab score with poor field data usually means real-world conditions — third-party scripts, marketing tags, slower devices — are worse than the simulation. That gap is information, not an error.

Work in the order that finds causes fastest. If Time to First Byte is high, the bottleneck is hosting or the database and no frontend work will fix it. If LCP is poor but TTFB is fine, look at the hero or product image: its size, its format and whether it is lazy-loaded when it should not be. If INP is poor, the browser is executing too much JavaScript, which usually traces back to plugins and marketing tags. If CLS is poor, images and embeds are missing dimensions. Why is WooCommerce slow walks each of those causes properly.

Run the check before you change anything, write the numbers down, then run it again after the change — but remember field data moves on a rolling 28-day window, so a genuine improvement takes about a month to appear in full. Lab data updates immediately, which makes it the right tool for verifying a fix landed and the wrong tool for judging whether it mattered. Stores that skip this discipline end up unable to say whether an expensive project worked.

The result appears on this page and is not saved, logged against you or emailed anywhere. Asking for contact details before showing a number would make this a lead form wearing a tool's clothes, and there are enough of those. If you want a human to look at what the numbers mean for your specific store, the free audit is a separate step you choose to take, and it answers with the plugin stack, the checkout path and a recommendation — including "do nothing yet" when that is right.