Reading CrUX data step by step. What the numbers mean, and what they don't.
An audit walkthrough here means working through a real scenario using publicly available data — not a paid service engagement. The goal is to show how someone can read their own CrUX data, understand what the numbers actually say, and avoid the interpretive errors that are common when sites first look at their Core Web Vitals reports.
The Core Web Vitals report in Search Console is the most accessible entry point to your site's CrUX data. It shows the distribution of page URLs categorized as Good, Needs Improvement, or Poor for both mobile and desktop. This is field data — real user sessions — not lab scores.
The first thing to check is which device type is failing. Mobile and desktop are evaluated separately. Many sites pass on desktop but fail on mobile. The mobile score is usually more important because it represents a larger share of traffic for most sites.
Search Console groups similar URLs together. A product page template gets grouped with other product pages. This is useful for prioritization — if a URL group representing your highest-traffic pages is in the Poor category, that matters more than a low-traffic URL group with similar issues.
Click into a URL group to see which specific metric is causing the failure. LCP, INP, and CLS are reported separately. A group might pass LCP but fail INP. Identifying which metric is the problem determines what kind of investigation is needed.
CrUX data aggregates over a 28-day rolling window. A fix deployed today won't show up in CrUX for 28 days — it will take that long for the new sessions to dilute the older ones. This is a common source of frustration. Sites make improvements and expect to see CrUX scores change within days. They don't.
Plan for a full month of data collection after any significant change before drawing conclusions about whether the change moved the field score.
CrUX data requires a minimum number of sessions to appear. New sites or low-traffic pages may not have enough data for a CrUX report to generate at all.
LCP measures the render time of the largest visible content element. On most pages, this is either a hero image or a large heading. Knowing which element is your LCP candidate is the starting point for understanding why the score is what it is.
Chrome DevTools' Performance panel identifies the LCP element. It's labeled in the timeline. The element that appears tells you whether the issue is image loading, server response time, or render-blocking resources.
Google breaks LCP into four phases: Time to First Byte (TTFB), Resource Load Delay, Resource Load Duration, and Element Render Delay. Each phase can contribute to a slow LCP score. Knowing which phase is largest tells you where to focus investigation.
A large TTFB suggests server or network issues. A large Resource Load Delay often means the LCP image isn't preloaded or is discovered late in the HTML. Resource Load Duration relates to the image file size and transfer speed. Element Render Delay is typically caused by render-blocking scripts or stylesheets.
The broad improvement in LCP scores visible in CrUX data over the past year reflects a few widespread changes. CDN adoption increased. Image optimization became more automated through build tools and CMS plugins. The fetchpriority attribute for images became widely documented and adopted.
These are real improvements. LCP is genuinely easier to improve than INP, because the main lever — image loading speed — is more straightforward to address than JavaScript execution architecture.
INP is reported as a single number representing the worst interaction in the session (with some outlier exclusion). But the path to improving it requires finding which specific interactions are slow. Chrome DevTools' Performance Insights panel can record a session and flag slow interactions.
Common high-INP interactions include search autocomplete fields, accordion expand/collapse, add-to-cart buttons with inventory checks, and filter panels on product listing pages.
Every interaction has three phases contributing to INP: Input Delay (time from user action to when the browser begins processing), Processing Time (time to execute event handlers), and Presentation Delay (time from handler completion to next frame render).
Long input delays often indicate main thread contention — another script is running when the user clicks. Long processing times indicate the event handler itself is doing too much work. Long presentation delays can indicate forced layout recalculations triggered by the handler.
Improving LCP often involves configuration changes and asset optimization. Improving INP often requires code changes — breaking up long tasks, deferring non-critical work, or restructuring how event handlers execute. This is a meaningfully higher bar than image optimization.
For sites built on major CMS platforms or JavaScript frameworks, INP improvements may require waiting for platform updates. Framework-level changes are outside the control of individual site operators.
The Layout Instability API provides shift attribution — which elements shifted, how far, and when. This is accessible via JavaScript and is the most reliable way to identify CLS sources in production. Running this in a real browser session with live ads active will surface shifts that lab tools never see.
The PerformanceObserver API with the "layout-shift" entry type captures this data. Building a simple logging snippet that sends shift data to your analytics allows you to collect real-world CLS attribution.
The most common CLS fix for ad-supported sites is reserving space for ad slots before the auction completes. This means giving the ad container a minimum height that matches the most common ad creative size. The tradeoff is visible empty space if the auction fails or returns a smaller creative.
Some publishers use a CSS approach with aspect-ratio on ad containers. Others use JavaScript to pre-size containers based on historical bid data. Neither approach eliminates CLS from ads entirely — they reduce it.
The gap between lab CLS and field CLS is wider for ad-supported sites than for any other site category. Lab tools run without ads. Field data includes every ad-loaded session. The only way to get an accurate CLS measurement for an ad-supported site is to measure it in production with ads enabled.
The web-vitals JavaScript library from Google provides a CLS measurement that includes all shift sources, including those from ad networks. Adding this library to your site and logging the output gives you the same CLS score that CrUX would record for that session.
PageSpeed Insights runs a lab test from a Google server. It does not represent your real user population. Treating a 90+ PSI score as evidence of good field performance can be misleading, especially for sites with variable server response times or heavy third-party scripts.
Moving from 2.8s LCP to 2.6s LCP when your threshold boundary is 2.5s does not change your ranking tier. It's a real improvement. It's not a ranking improvement. Conflating these two different types of improvement leads to misallocated effort.
CrUX data is segmented by device type. A site that passes on desktop and fails on mobile has a real problem, because Google's mobile-first indexing means the mobile score carries more weight. Reporting aggregate scores without device breakdown hides this split.
The 28-day rolling window means CrUX is a lagging indicator. Sites that deploy fixes and check CrUX the next day are measuring the wrong thing. The field score won't reflect the change for several weeks. Short-term validation requires lab tools, not CrUX.
