Core Web Vitals Mistakes That Quietly Kill Your Rankings
Most people assume Core Web Vitals are a Google checkbox you either pass or fail. Fix a few images, run a speed plugin, job done. That assumption is exactly why so many sites carry poor scores for months without understanding why. The real mistakes tend to be quieter and more specific than that, and they rarely show up on a surface-level audit. A few are so widespread it is worth going through them plainly.
On this page
Thinking a good PageSpeed score means you’ve passed
PageSpeed Insights gives you a number out of 100. It is tempting to treat a score of 90+ as a pass. It is not. The score you see there is a lab result, simulated in controlled conditions. What Google actually uses for ranking is field data, collected from real visitors on real devices through the Chrome User Experience Report.
A site can score 94 in the lab and still fail LCP in the field because real visitors on mid-range Android phones over a patchy 4G connection have a completely different experience. The lab score is useful for spotting issues. It is not the thing you are being graded on.
Fixing the wrong metric first
There are three Core Web Vitals that matter right now. LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). Most people reach for CLS fixes first because layout shifts look dramatic in videos and reports. In practice, CLS failures tend to be the easiest to resolve and often the least damaging to real visitor experience.
LCP is where most sites genuinely bleed. It measures how long it takes for the main content, usually a hero image or a large heading, to appear on screen. A slow LCP means visitors are staring at an incomplete page. That is the one worth diagnosing first.
Nine times out of ten, LCP is slow because the hero image is not preloaded, is too large, or is being served through a slow third-party origin. None of those are plugin problems. They are architectural ones.
Expecting a caching plugin to sort it all out
Caching plugins help. WP Rocket, W3 Total Cache, LiteSpeed Cache, they all reduce server response times and cut down on repeat load requests. What they cannot do is fix a 400kb uncompressed hero image, a render-blocking Google Font loaded in the head, or a theme that adds six JavaScript files before the page even starts painting.
The mistake is treating a caching plugin as a solution rather than one layer of a larger answer. If the underlying build is heavy, the cache makes it faster but not fast. A cleaner approach to Core Web Vitals fixes on WordPress starts with what is loading, not how it is being cached.
Assuming the desktop score reflects what mobile visitors see
Google uses mobile-first indexing. The scores it uses to judge your site are based on mobile visitors. Most people run their audits on desktop. These two things do not tell the same story.
A desktop audit might show a perfectly healthy LCP of 1.4 seconds. The same page on mobile, throttled to simulate a typical connection speed, might come back at 4.2 seconds. That is a Core Web Vitals failure. The ranking signal is coming from the mobile result, not the desktop one.
Always test mobile explicitly in PageSpeed Insights. The tab is right there. It is the one that matters.
Treating Core Web Vitals as a one-time fix
Scores shift over time. A plugin update adds a new inline script. A new page template introduces a layout shift. A theme update changes how fonts are loaded. Sites are not static things, and Core Web Vitals scores reflect that.
The real lesson from rebuilding sites like Dragonfly from the ground up is that a clean rebuild is not the end of the work. Getting back to page one for competitive terms after a rebuild takes sustained attention to what is happening under the surface, not just at launch.
Worth checking quarterly at a minimum, field data in Search Console, PageSpeed scores on mobile for key templates, and any new third-party scripts that have crept in.
One thing genuinely not worth obsessing over
TTFB. Time to First Byte gets a lot of attention in performance discussions because it sounds fundamental. A slow server response does matter, but chasing a TTFB improvement from 180ms to 120ms rarely moves your Core Web Vitals scores in any meaningful way.
If your TTFB is over 600ms, yes, look at your hosting. Below that, the time is better spent on what actually drives LCP and CLS. That is where the field data tends to improve, and that is what moves the page speed numbers that count.