Core Web Vitals Suddenly Dropped: How to Find What Changed (2026)
The Core Web Vitals score you're panicking about and the one Google actually uses are probably two different numbers — here's how to find the real cause before you touch any code.
The number you're panicking about and the number Google actually uses to rank you are probably two different scores. You ran PageSpeed Insights, saw red where there used to be green, and assumed the site broke overnight. Maybe it did. But there's a good chance you're reading lab data — a single simulated test run — when the score that matters for search is field data, a 28-day rolling average of what real visitors on real phones and real connections actually experienced. Those two numbers move on different clocks, and mixing them up is the single most common reason Core Web Vitals "emergencies" turn into weeks of chasing the wrong fix.
This is the diagnostic. Not a list of things that theoretically affect page speed — a way to work out, on your actual site, what changed and when.
Field data vs lab data: know which one you're reading
Every Core Web Vitals number comes from one of two sources, and they answer different questions.
Lab data is a single simulated page load — the report you get from running PageSpeed Insights or Lighthouse right now, on one connection speed, one device profile, one moment in time. It's useful for reproducing a specific problem and testing a fix, but it's one sample. It can swing between runs based on server load, network jitter, or which CDN edge you happened to hit.
Field data comes from the Chrome UX Report (CrUX) — real measurements from real Chrome users who actually visited your pages, aggregated into a rolling 28-day window. This is what shows up in Google Search Console's Core Web Vitals report, and it's the version Google has confirmed page experience signals draw from. It moves slowly by design — a fix you ship today won't fully show up in field data for close to a month, because the last four weeks of pre-fix visits are still baked into the average.
The three Core Web Vitals thresholds, measured at the 75th percentile of page loads, are the same across both: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1, per Google's own vitals documentation. INP is the newer of the three — it replaced First Input Delay as the official interactivity metric on 12 March 2024, and a lot of older advice online still talks about FID as if it's still current. If you're reading a "how to fix Core Web Vitals" guide that mentions FID, it predates the switch and may be pointing you at the wrong metric.
The practical upshot: if PageSpeed shows a bad lab score but Search Console's field report is still green, you've found something reproducible but not yet widespread — worth fixing, not yet an emergency. If Search Console shows field data going red across a chunk of your URLs, that's real visitors having a bad time right now, and it's been building for weeks before you noticed.
Step one: work out when it actually started, not when you noticed
Search Console's Core Web Vitals report groups URLs by status and shows the trend over time — that's the first place to look, because "I noticed today" and "it started today" are usually different dates. Open the report, filter to Mobile, and look at when the number of "Poor" or "Needs improvement" URLs actually began climbing.
If the line moved sharply on one specific date, you're looking for a cause on that date — a deploy, a new script, a content change. If it's been drifting for six to eight weeks, you're looking for something that degraded slowly: image weight creeping up post by post, a third-party tag someone added quietly, or the site simply not being fast enough for where Google's bar sits now. The two patterns need different fixes, and the shape of the graph tells you which one you've got before you open a single line of code.
The five things that usually did it
Once you know roughly when it started, check the deploy or content history against these, in order of how often they're the actual cause.
A new script got added. A chat widget, a marketing pixel, a cookie consent tool, an A/B testing snippet — any third-party script loaded in the <head> can block the main thread and push out both LCP and INP. This is the single most common cause of a sudden Core Web Vitals drop, because it's usually added by someone in marketing or sales through a tag manager, with zero visibility to whoever owns the site's performance. Check your Google Tag Manager container's version history if you use one — it logs every change with a timestamp, which lines up neatly against the date the CWV graph moved.
An image shipped without dimensions or lazy-loading. Every <img> without explicit width and height attributes forces the browser to guess its size until the image loads, then shift the layout when it doesn't guess right — that's a CLS hit. A large hero image without loading="eager" and proper preloading, or one that's simply too heavy for what it needs to be, is a common LCP culprit. If a new blog post or campaign landing page went live around the date things dropped, check its hero image first.
A web font swap or a late-loading font. This is the one that catches people out because it feels cosmetic. Load a custom font the wrong way — no font-display strategy, no preconnect to the font host, no self-hosting — and the browser either shows invisible text until the font arrives (a delay that can itself count against LCP if the hero heading is the largest element) or swaps in a fallback font late and reflows the page, which counts against CLS. It's a small, boring technical decision that quietly determines whether your headline paints on time. Anyone who's rebuilt a font-loading strategy properly once tends to never make the mistake again, because the fix is cheap and the penalty for getting it wrong is disproportionate.
Something changed in hosting or the CDN. A hosting plan downgrade, a CDN configuration change, a caching rule that got switched off, or simply more traffic hitting an under-provisioned server all show up as a straightforward LCP regression with no code change involved at all. Worth ruling out, especially if the drop coincides with no deploys at all.
Hydration or client-side rendering got heavier. This one's specific to sites built with a lot of client-side JavaScript — a new component, a heavier state library, or a third-party embed that runs its own JS framework inside yours can all delay how quickly the page responds to the first tap or click, which is exactly what INP measures. If your INP specifically got worse while LCP and CLS stayed flat, this is where to look.
Step two: reproduce it in lab data before you fix anything
Once you have a suspect, confirm it in lab data before touching code, because lab data lets you isolate variables that field data can't. Run PageSpeed Insights on the affected page and check the diagnostics section — it names the specific resources blocking render, the largest contentful element, and any layout shift culprits by CSS selector. Chrome DevTools' Performance panel, run with the throttling set to a mid-range mobile CPU and a Fast 3G or Slow 4G connection, will show you the actual script execution timeline, which is where a rogue third-party tag becomes obvious.
If you can toggle the suspected cause off — disable the tag in Tag Manager, revert the font-loading change, roll back the deploy — and the lab score recovers immediately, you've confirmed the cause. That's also your test for the fix: don't ship a change and wait a month for field data to tell you if it worked. Confirm it in lab data first, deploy the fix, then watch field data over the following weeks purely to confirm the fix held at scale — not to find out whether it worked at all.
Why the fix doesn't show up immediately
This is the part that causes the most frustration and the most premature panic. Because field data in Search Console is a rolling 28-day average, a fix shipped today is diluted by roughly four weeks of pre-fix data still sitting in the window. You'll often see the "Poor" URL count barely move for a week or two after a genuine fix, then drop sharply as the bad data rolls out of the 28-day window. If you fixed the right thing and the lab score confirms it, resist the urge to keep changing things because the field number hasn't caught up yet — that's usually how a good fix gets undone by a second, unnecessary change made out of impatience.
When the fix isn't a fix, it's a ceiling
Sometimes the honest answer is that there's no single script or image to blame — the platform itself has a performance ceiling you've already hit. Page-builder platforms ship the CSS and JavaScript for every feature they support, whether the page uses them or not, and there's a limit to how far image compression and plugin removal can take you within that constraint. If you've worked through the five suspects above, found nothing that explains the drop, and the site has been on the same platform for a few years accumulating plugins and integrations, that's usually what's happening. This is a separate diagnosis from "something changed" — it's covered in more detail in our breakdown of why Google rankings actually drop, which walks through the site-versus-SEO question this same graph tends to raise.
If the platform is the ceiling, the practical options are narrowing what's loaded on the pages that matter most, or accepting that a hand-coded rebuild is the only way to reset the baseline — which is a bigger decision than a Core Web Vitals dip on its own usually justifies, but worth knowing which category you're in.
Where to start
Before doing anything else: run a free audit. It checks your Core Web Vitals, flags what's dragging LCP, INP, and CLS specifically, and takes about thirty seconds — which is a faster way to see the current state of your site than opening five different tools and cross-referencing them by hand.