The problem with Core Web Vitals as a diagnostic tool
Google confirmed Core Web Vitals as a ranking signal in 2021. Since then, a lot of SEO effort has flowed into shaving milliseconds off LCP, suppressing layout shift, and — more recently — wrestling with INP on JavaScript-heavy sites. Some of that effort is genuinely worthwhile. A lot of it is displacement activity: fixing the thing that’s measurable while ignoring the thing that’s actually hurting you.
What we keep seeing: sites with CWV scores in the green, PageSpeed Insights looking clean, rankings still declining quarter over quarter. And sites with mediocre LCP times, some layout shift, passable INP — outranking everything in their niche because their topical coverage is airtight and their entity relationships are legible to Google’s systems.
CWV are a threshold signal, not a differentiator. Clear the floor and you’ve removed a penalty risk — you’re not earning extra credit. That framing changes what you should actually be optimizing.
What the CWV signal actually measures (and what it doesn’t)
Largest Contentful Paint measures how fast the largest visible element renders from the user’s perspective. Cumulative Layout Shift catches visual instability — images without dimensions, late-loading ads shoving content down. Interaction to Next Paint (which replaced FID in March 2024) measures responsiveness to input events like clicks and keypresses.
All three are user experience signals. They were designed to proxy “did the page feel usable” — not “is this page semantically authoritative” or “does this document belong to a coherent topical cluster.”
Google’s ranking system runs hundreds of signals in parallel. CWV sit in the page experience bucket alongside mobile usability, HTTPS, and absence of intrusive interstitials. That bucket matters. But it doesn’t compete with relevance signals and entity authority — it runs alongside them, and relevance almost always wins ties.
The clearest evidence: search any competitive informational query and look at the top 5. Several will have yellow or red CWV scores in PageSpeed Insights. They’re there because Google trusts them topically. Their LCP score didn’t save them, and it didn’t disqualify them.
Where CWV optimization actually does move the needle
Dismissing CWV entirely is wrong too. Three situations where fixing them produces measurable ranking or traffic changes:
- E-commerce category and product pages at scale. If you have tens of thousands of product pages and a large portion are failing CWV due to unoptimized image loading or third-party script bloat, the cumulative signal matters. Google’s crawl and indexing systems are sensitive to quality signals across large sitemaps — a site-wide pattern of poor page experience correlates with reduced crawl frequency on the long tail, which compounds into indexing lag.
- News and freshness-dependent content. For publishers chasing Top Stories or Discover, page experience carries more weight because Google is surfacing content to users who haven’t opted in with a specific query. The tolerance for a slow load is lower when there’s no strong search intent pulling someone through it.
- Mobile-first markets with constrained device profiles. If a significant chunk of your audience is on mid-range Android devices in a market with variable connectivity, INP problems that don’t surface in your own testing will show up in field data (CrUX). Lab scores from PageSpeed Insights are synthetic — they run on a specific emulated device. Field data from the Chrome User Experience Report is real, and per Google’s documentation, it’s what feeds ranking decisions.
Outside these three scenarios, the ROI on CWV optimization is usually lower than the same effort applied to content coverage gaps, internal linking structure, or entity disambiguation.
The misdiagnosis pattern we keep running into
We’ve been doing SEO since 2010. The pattern that produces the worst outcomes is always the same: someone picks up a tool — site audit, PageSpeed, rank tracker — finds something that scores badly, and optimizes toward that score without first establishing whether that metric is actually correlated with the problem they’re trying to solve.
CWV is particularly susceptible because the scores are vivid. Red, orange, green. A number. A percentile. It feels like a diagnosis. It’s usually not.
Actual diagnostic sequence for a site losing organic traffic:
- Separate the traffic loss by query type: branded vs. non-branded, navigational vs. informational vs. transactional. Different drops have completely different causes.
- Check index coverage in Search Console before anything else. If pages you expect to rank aren’t indexed, no CWV fix helps anything.
- Cross-reference the timing of the drop with known algorithm update windows. If the drop started during a core update rollout, the cause is almost certainly quality or relevance — not speed.
- Only then, if CWV is still a candidate, look at CrUX field data for the specific URLs losing traffic. Lab scores are a proxy; field data is the ground truth Google uses.
Steps 1-3 identify the actual problem most of the time. CWV is rarely the smoking gun for informational or service sites.
The INP migration deserves a specific callout
Interaction to Next Paint replaced First Input Delay in March 2024, and it’s a meaningfully stricter metric. FID measured the delay before the browser started processing the first interaction. INP measures the full duration of every interaction during the page session — not just the first one.
That distinction matters a lot for React and Vue SPAs where the main thread gets clogged with re-renders after hydration. A page can pass FID and fail INP badly — because the first click was fine but subsequent interactions on a content-rich page triggered expensive reconciliation cycles.
If your site is built on a JavaScript framework and you haven’t looked at INP in CrUX data specifically (not PageSpeed Insights lab scores), do that now. The mechanism: long tasks blocking the main thread prevent timely input response, which drives up your p75 INP, which feeds into the field data Google uses for ranking. Fixing it usually means code-splitting, deferring non-critical JS, and sometimes rethinking which interactions are handled client-side versus server-side.
Worth flagging: on pages where you can’t meaningfully reduce JavaScript, INP has a real ceiling. There’s no clever compression trick that fixes a framework doing expensive reconciliation on every interaction. Knowing that before you start is more useful than chasing a green score with synthetic tools.
How to use CWV without letting it own your roadmap
Treat CWV as a hygiene check, not a strategy. Run a quarterly audit — CrUX dashboard for field data, Lighthouse for lab diagnostics, Search Console’s Core Web Vitals report to catch pages Google has flagged as poor. Fix anything in the red, especially on high-traffic templates. Then stop.
The sites outperforming on organic in competitive verticals aren’t winning because they scored 98 on PageSpeed. They’re winning because Google’s systems have high confidence about what they cover, who they are as an entity, and what queries they should surface for. That’s a harder problem than optimizing image loading — and a more load-bearing one.
If your CWV scores are already passing (p75 LCP under 2.5s, INP under 200ms, CLS under 0.1) and traffic is still declining, stop looking at performance. The answer is in your content coverage, your link profile, or how legible your entity is to Google’s knowledge graph. Where would you put your next sprint?