Why independence from services changes what you can say about the data.
When a ranking signal launches, everyone with an optimization service to sell has a reason to amplify its importance. That's not a conspiracy — it's just how incentives work. An agency that says "Core Web Vitals might not affect your rankings much" is an agency that can't sell its CWV optimization package. So the industry, collectively, skewed toward alarm.
The public data doesn't support that alarm at the scale it was presented. That doesn't mean Core Web Vitals are unimportant. It means the relationship between vitals scores and rankings is more conditional, more contextual, and more nuanced than "fix your LCP or lose rankings."
The Chrome User Experience Report is the primary data source here. CrUX is a public dataset updated monthly on BigQuery, and it contains real user measurements from Chrome browsers across millions of web origins. It's the same data that feeds the Core Web Vitals report in Google Search Console.
We also reference Google's own documentation on how the ranking signal is weighted, third-party research from academic and independent groups, and the published Search Central blog posts where Google has clarified the signal's scope. Nothing behind paywalls. Nothing from tool vendors with a product to sell.
Google's ranking signal operates on threshold tiers, not on a continuous scale. A site that moves from 2.6s LCP to 2.4s LCP has crossed the threshold from Needs Improvement to Good. That crossing matters. A site that moves from 2.6s to 2.5s has not crossed any threshold. The ranking implication is zero.
This distinction gets lost constantly. Tools report decimals. Dashboards show trends. Agencies show improvement charts. But if the improvements don't cross a tier boundary, they're not ranking improvements — they may be user experience improvements, which is genuinely valuable, but it's a different claim.
We try to be precise about this. When we discuss CrUX data, we specify which tier a site falls into, not just the raw number.
Google evaluates Core Web Vitals at the 75th percentile of page loads, segmented by device type. That means 75% of your real users' sessions need to meet the threshold — not your median session, not your best-case lab score. The 75th percentile is harder to hit than the median, especially for sites with variable performance based on user geography or device capability.
Many sites that appear to pass CWV in lab testing fail in the field because their lab tests represent an idealized session, not the range of real sessions. A fast fiber connection test doesn't represent the slow 4G user at the 75th percentile. Understanding this gap is central to reading CrUX data correctly.
First Input Delay measured only the delay before the browser first responded to a user interaction. It was a narrow window — often just a few milliseconds. Sites could pass FID by ensuring the main thread wasn't completely blocked during initial load. Many sites achieved this without fundamental architectural changes.
INP measures the full duration of the longest interaction throughout a user's session. It includes input delay, processing time, and presentation delay. A complex click handler that takes 400ms to resolve contributes to a poor INP score even if the page loaded fast. This is a fundamentally different measurement.
Sites with heavy client-side JavaScript frameworks, complex filtering interfaces, or large amounts of third-party scripts tend to have the highest INP scores. E-commerce product pages with dynamic cart interactions are a common example. Single-page applications with complex state management are another.
CrUX began collecting INP data before it became an official vital. Historical data exists. Querying CrUX for INP distribution across site categories reveals which types of sites are most affected. The distribution is notably wider than LCP — more variance, more sites in the Poor range than the industry acknowledged when FID was still the standard.
The fix for CLS seemed straightforward when Google announced it. Reserve space for images. Set width and height attributes. Use aspect-ratio in CSS. These fixes work for static content.
Ad networks are not static. A header bidding auction completes after the page renders. The winning ad creative has different dimensions than the placeholder. The page shifts. Users notice. CrUX records it.
Publishers who fixed their image-related CLS and considered the job done often discovered their CrUX CLS score remained in the Needs Improvement range. The culprit was almost always the ad stack. The fix requires coordination with the ad serving setup — not just front-end CSS changes.
This is one area where the gap between lab scores and field scores is most pronounced. No lab tool loads your live ad network. Testing CLS accurately requires specific tooling setups that most site owners don't use.
