You’ve been here. You ran your site through PageSpeed Insights, got a number somewhere between red and yellow, and felt that familiar sinking feeling. So you installed the speed plugin everyone on Reddit said to install. You cleared the cache, ran the test again, and the score moved three points. Maybe four. The homepage still stutters when the hero image loads. The button still shifts right as you try to tap it. Something is clearly wrong, but the dashboard doesn’t explain what.
There’s a reason for that gap. Google measures three distinct things under the name Core Web Vitals — and in 2024 it updated which three. According to the HTTP Archive Web Almanac 2024, only about half of all websites pass all three. WordPress sites do slightly worse. The problem isn’t that your site is slow. The problem is that “fast” was never the right word.
Key Takeaways
- Only 40% of WordPress origins pass all three Core Web Vitals on mobile (HTTP Archive Web Almanac 2024).
- “Speed” is actually three separate metrics — LCP (loading), CLS (visual stability), and INP (responsiveness) — and optimizing one can worsen the others.
- Most caching plugins target LCP alone, which is why PageSpeed scores barely move after you install them.
- INP officially replaced FID as a Core Web Vital on March 12, 2024.
Why “Fast” Is the Wrong Word
“Fast” is a marketing word. It describes a feeling, not a measurement. A page can deliver its HTML in 300 milliseconds and still feel completely broken. A site can score 95 on PageSpeed and still lose shoppers at the checkout button. Speed in isolation tells you almost nothing about whether someone will stay on your site long enough to read, click, or buy.
The industry figured this out the hard way. Google’s own research found that 53% of mobile users abandon a site if it takes longer than three seconds to load. That statistic got framed for years as an argument about raw speed. But Google kept studying the data, and a harder question emerged: what exactly were people waiting for? Not the HTML. Not the CSS. They were waiting for the page to become usable. And usable turned out to be three different things.
Think about the last time a site frustrated you. Was it the blank screen? Or was it the moment a banner popped in and pushed the article down just as you started reading? Was it the tap that did nothing for half a second? Each of those is a different failure, with a different cause, and no single “speed plugin” addresses all three.
What Google Actually Measures Now
Core Web Vitals is Google’s admission that raw speed scores weren’t capturing real user pain. Each of the three metrics targets a distinct dimension of experience: how quickly the main content appears, how visually stable the page is while loading, and how responsive it feels when you interact with it. Google publishes specific thresholds for each — LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds — measured at the 75th percentile of real users (web.dev).
The gap between CMS platforms on this is wider than most people assume. Here’s what the 2024 data actually looks like:
WordPress sits at the bottom not because the software is bad, but because its plugin ecosystem lets owners bolt on optimization tools that address one metric while degrading another. Duda, a more controlled platform with fewer third-party extensions, leads at 73%. The difference is architectural, not about raw speed.
What Is LCP (Largest Contentful Paint)?
LCP measures the moment the largest piece of visible content finishes rendering — usually your hero image, a headline, or a video thumbnail. Google’s threshold is 2.5 seconds at the 75th percentile of real visits, and according to the HTTP Archive Web Almanac, 59% of mobile origins currently meet it. That makes LCP the metric most sites struggle with.
LCP isn’t “load time.” A server can deliver HTML in under a second and still fail LCP because the hero image lives on a slow CDN, because the headline is hidden behind a web font that’s still downloading, or because a render-blocking script delays the browser from painting anything at all. On WordPress, the usual culprits are unoptimized images uploaded from a phone, a theme that ships four megabytes of CSS, and hosting that throttles during traffic spikes.
The fix isn’t one thing. It’s right-sizing your hero image, preloading critical assets, deferring non-essential scripts, and making sure your host actually sends the first byte quickly. Any plugin promising to “speed up” your site without touching those specifics is probably addressing the symptom, not the cause.
What’s a good LCP score?
Under 2.5 seconds is “good.” Between 2.5 and 4 seconds is “needs improvement.” Over 4 seconds is “poor.” That’s measured at the 75th percentile, which means three-quarters of your actual visitors need to hit the threshold — not just the fast ones on fiber connections.
What Is CLS (Cumulative Layout Shift)?
CLS is the weird one. It doesn’t measure time at all. It measures how much the page moves while you’re trying to use it — that jarring jump when a banner loads, when a font swaps, when an embedded tweet finally renders and pushes the article down by 80 pixels. The threshold is 0.1, and 79% of mobile origins already pass it. Of the three metrics, CLS is the one the web is closest to solving.
The fixes are mechanical. Set explicit width and height attributes on every image and video. Reserve space for ad slots before they load. Avoid injecting content above existing content after the page has rendered. Use font-display: optional or preload key fonts so the text doesn’t swap halfway through reading. Each of these sounds small. Stacked, they’re the difference between a page that feels composed and one that feels like it’s being assembled while you watch.
CLS is also the metric most likely to get quietly worsened by a “speed” plugin. Lazy-loading everything sounds efficient. Lazy-loading your hero image, or stripping dimension attributes to “simplify” markup, creates layout shifts that didn’t exist before. Your dashboard shows the overall score went up a few points from faster loading. Your actual CLS metric cratered. The dashboard shows a win. Your users feel a loss.
What Is INP (Interaction to Next Paint)?
INP is the newest of the three. It replaced First Input Delay on March 12, 2024, and it measures something FID couldn’t: how responsive your page feels across every interaction, not just the first one. Google’s threshold is 200 milliseconds. On mobile, 74% of origins currently pass.
Here’s the short video from the Chrome team explaining why this metric exists:
INP is the metric that exposes bloat. A page can load its pixels in under two seconds and still feel broken, because every tap triggers a main-thread JavaScript stampede — analytics, chat widgets, cookie banners, page builders, A/B testing scripts — all fighting for the same single thread the browser needs to respond to your touch. The feeling users describe as “the site is slow” is, nine times out of ten, an INP failure, not a load-time failure.
The fix isn’t smaller — it’s harder. You have to audit which scripts run on interaction, defer or remove what isn’t essential, break up long tasks so the browser can answer the tap, and in some cases rewrite how widgets hook into the page. There is no plugin that does this automatically, because the answer depends on which plugins you’ve already installed.
Why “Speed Optimization” Plugins Often Fail
This is the diagnostic question: what actually goes wrong when you install a popular caching plugin and the PageSpeed score barely moves? Three things, usually, and none of them are obvious from the plugin’s marketing page.
First, most speed plugins optimize exactly one metric: LCP, through caching and minification. Caching serves HTML faster. Minification shaves kilobytes off CSS. Both help LCP. Neither touches CLS, because layout shifts happen in the browser after the HTML arrives. Neither touches INP, because interaction delays are about JavaScript execution, not file size. Two-thirds of the scoring weight is sitting outside the plugin’s effect.
Second, some “optimizations” actively damage the other metrics. Aggressive lazy-loading strips dimensions from images, which causes layout shifts. Deferring all JavaScript to after load can push critical interactive handlers out of the first-paint window, tanking INP. Combining CSS into one giant file can delay LCP on pages that only needed a fraction of the styles. The plugin’s dashboard shows a green checkmark next to “combined CSS.” The user’s experience shows a page that now jumps twice before it settles.
Third, plugins operate blind. They don’t know which image is your LCP element, which script is blocking INP, or which embed is causing your CLS score to tank. They apply generic transformations to every page and hope the average improves. Sometimes it does. Sometimes it doesn’t. You can’t tell from the plugin’s interface, because the plugin isn’t measuring what Google measures — it’s measuring its own before-and-after file size.
Real-world case studies show what happens when teams actually target the right metric. Economic Times reduced INP and saw page views rise 43% and bounce rate drop 50%. RedBus optimized INP and lifted sales by 7%. Those gains came from diagnosis, not from a plugin.
Treating Core Web Vitals as a System
This is the prescriptive question: how should you think about the problem instead? The shift that matters is moving from chasing a score to diagnosing an experience. The three metrics aren’t independent. They’re coupled. Any intervention on one has consequences for the other two.
Preloading your hero image helps LCP. It can also starve the bandwidth needed for a critical font, which creates a CLS event. Deferring JavaScript helps INP. Defer the wrong script and you delay the analytics event that triggers your hero carousel, which delays LCP. Setting explicit image dimensions helps CLS. Set them wrong and you’ve locked in a layout that breaks on mobile, which hurts LCP on the devices that matter most. Every fix is a tradeoff.
The way out is to measure real user data, not lab scores. Lab tools like PageSpeed Insights simulate a page load on a single device profile. Field data — the kind Chrome collects from actual visitors, aggregated in the Chrome User Experience Report — tells you what your users actually experience across their real devices and networks. When the lab score and the field data disagree, the field data is right. That’s the number Google uses for ranking, and that’s the number your users feel.
A system-level approach starts with field data, identifies which of the three metrics is the actual bottleneck, traces that metric back to its root cause, and makes a targeted change. Then it measures again. It doesn’t install six plugins and hope.
Where Lightify Comes In
We built Lightify because this is the gap every WordPress owner we spoke to was stuck in. The diagnostic work is possible, but it requires reading waterfalls, understanding Chrome DevTools, and knowing which plugin to blame. Lightify treats LCP, CLS, and INP as the single coupled problem they actually are, and it handles the tradeoffs in the right order for a WordPress site. That’s the whole pitch.
Your site doesn’t need to be just faster. It needs to load right. Try Lightify →
A passing score means all three metrics meet their thresholds at the 75th percentile of real visits: LCP under 2.5 seconds, CLS under 0.1, and INP under 200 milliseconds (web.dev). For WordPress specifically, only 40% of mobile origins currently hit all three at once (HTTP Archive).
Most caching plugins only affect LCP, which is one of three metrics Google measures. Your CLS (layout stability) and INP (responsiveness) scores are governed by image dimensions, font loading, and JavaScript execution — none of which a caching plugin touches directly.
Yes, the replacement happened industry-wide. Google retired FID and promoted INP to a Core Web Vital on March 12, 2024. FID only measured the delay before the first interaction. INP measures responsiveness across every click and tap during a session, which is a harder and more honest test.
Yes, but indirectly. Google uses page experience, including Core Web Vitals, as one ranking signal among many. A site that fails CWV won’t drop off search results entirely, but sites that pass tend to retain users longer, which compounds into better engagement signals and, eventually, better rankings.
The Reframe
You don’t have a speed problem. You have a loading-correctly problem, and it lives in three different places. LCP is about how quickly the main content appears. CLS is about whether the page stops moving once it’s there. INP is about whether it actually responds when you touch it. A tool that only addresses one of them is solving one-third of a coupled problem, which is why your score never moves the way the plugin promised.
The next time someone tells you your site needs to be faster, ask them which metric they mean. If they can’t answer, they’re not talking about performance — they’re talking about a feeling. Performance is measurable now. Start with your PageSpeed Insights report, read which of the three metrics is failing, and fix that one. Then measure again.