You installed the caching plugin everyone recommended. WP Rocket. LiteSpeed Cache. W3 Total Cache. Something else with a rocket icon. You flipped the big green switch, purged, ran PageSpeed Insights again, and watched the score crawl up by four points.
The homepage still paints the hero late. The Add to cart button still feels sticky on mobile. Search Console still nags about LCP or INP on your URL groups. The cache is clearly working. Your Core Web Vitals are still failing.
That gap is not a mystery, and it is not proof that caching is useless. Caching fixes one slice of the problem. Google grades you on three different ones. Mixing them up is why so many WordPress sites buy a cache plugin, celebrate a faster TTFB, and then wonder why field data refuses to turn green.
This post is the diagnosis path we wish more people followed before they buy another optimizer or turn on every toggle at once.
The wrong assumption: “faster HTML” equals “pass Core Web Vitals”
A full-page cache does something specific and valuable. After the first render, WordPress stops rebuilding the page from PHP and MySQL for every anonymous visitor. It serves a flat file instead. Time to First Byte drops. That is real. On a busy shared host, it can be the difference between a 1.8s TTFB and a 60ms one.
Google’s Core Web Vitals are not TTFB.
They are:
- **LCP (Largest Contentful Paint):** when the largest visible piece of content finishes painting. Threshold: under 2.5 seconds at the 75th percentile.
- – **INP (Interaction to Next Paint):** how quickly the page responds to taps and clicks across the session. Threshold: under 200 milliseconds.
- – **CLS (Cumulative Layout Shift):** how much the layout jumps while loading. Threshold: under 0.1.
TTFB and FCP matter for the overall picture, but they are not the three Core Web Vitals Google uses for page experience. A cache that makes the HTML arrive quickly still leaves the browser with a 2.4MB hero, a render-blocking theme CSS file, a chat widget that owns the main thread on every tap, and a cookie banner that shoves the headline down after paint.
We covered the three metrics in depth in [Core Web Vitals explained](https://daftplug.com/blog/performance-optimization/core-web-vitals-explained-why-a-fast-website-isnt-enough/). The short version for this article: if your only move was “install a cache plugin,” you optimized the server side of the first byte. LCP, INP, and CLS mostly fail on the client after that.
Why LCP still fails after the cache is hot
LCP is usually your hero image, a big heading with a web font, or a video poster. On WordPress themes and page builders, it is almost always an image.
Here is what a healthy cache does not fix on its own:
**The hero is still huge.** A 2400px JPEG uploaded from a phone and displayed at 960px still has to download as a 2400px file unless something resizes and reformats it for the slot. Caching the HTML that references that file does not shrink the file.
**The hero is lazy-loaded.** Lazy loading below the fold is correct. Lazy loading the LCP element is a self-own. The browser waits to fetch the thing Google is timing. Many “optimize everything” defaults get this wrong.
**The hero is competing with render-blocking CSS and fonts.** The HTML can arrive in 80ms. The browser still has to download and parse the theme’s CSS, wait on a Google Fonts request, and only then paint the largest element. Cache hits do not reorder that work.
**Third-party scripts delay paint.** Tag managers, A/B tools, and chat widgets often run early. They steal bandwidth and main-thread time from the LCP element even when the page shell came from disk.
If LCP is your failing metric, start with the LCP element itself. Open Chrome DevTools, Performance or Lighthouse, and confirm what Google thinks the LCP node is. Then ask: is it sized for the display slot, served as a modern format, preloaded, and not lazy-loaded? Those questions beat another afternoon of cache TTL tuning.
For the image half of that, we already argued against sweeping the entire Media Library in [Don’t convert your entire WordPress media library to WebP](https://daftplug.com/blog/performance-optimization/dont-convert-wordpress-media-library-webp/). The page needs the images it actually shows, at display size, as WebP from cache. The archive of unused uploads is a distraction.
Why INP still fails on a “fast” site
INP replaced FID in March 2024. It is the metric that catches the feeling users describe as “the site is slow” when the pixels already appeared.
Caching does almost nothing for INP. The HTML was served from disk. The problem is JavaScript fighting for the main thread when someone taps.
Typical WordPress INP culprits:
- Chat widgets and live support scripts on every page
- – Heavy page-builder runtime JS
- – Analytics stacks that fire on every interaction
- – Cookie consent libraries that reflow and re-bind on load
- – Carousels and mega-menus that register expensive listeners
- – Multiple overlapping “optimization” plugins all rewriting the same scripts
Minification helps file size. It does not magically make a 400ms task under 50ms. Deferring and delaying non-essential scripts does. Removing scripts you do not need does more.
If INP is red in field data, your next job is not another cache warm. It is an audit of what runs on interaction. Chrome’s Performance panel and the Long Tasks view are blunt but honest. Anything that cannot justify its presence on a product page should leave, or wait until the visitor actually interacts.
Why CLS is a different disease entirely
CLS is not a speed metric. It is a stability metric. Images without dimensions, ads that inject above content, web fonts that swap late, sticky bars that appear after first paint: none of those care whether your HTML was cached.
Some cache-adjacent “optimizations” make CLS worse. Aggressive lazy loading that strips dimensions. Combining CSS in a way that delays the styles the first viewport needs. Injecting a preload that starves a critical font. The plugin dashboard shows a green checkmark. The layout still jumps under the reader’s thumb.
Fix CLS with reserved space and fewer late injections, not with a lower cache TTL.
Field data vs lab data (and why your scores disagree)
People get stuck here constantly.
**Lab data** (Lighthouse inside PageSpeed Insights, WebPageTest on a profile you choose) is a controlled experiment. One device profile. One network throttle. One run. Excellent for finding a specific problem on a specific URL.
**Field data** (Chrome User Experience Report in Search Console and in PSI when you have enough traffic) is what real visitors experienced at the 75th percentile. That is what Google uses for page experience. That is the number that decides whether a URL group is “Good.”
A site can look mediocre in a cold lab run and fine in the field if most visitors are on fast phones near the server. The reverse is also common: a lab score of 92 on a desktop profile while mobile field LCP fails because the hero is still oversized on real phones.
Use both. Lab to debug. Field to decide whether you are done.
One more wrinkle on WordPress: the first uncached hit is a different animal from the cached hit everyone else gets. If your lab test keeps landing on a cold page (no cache, or a purge between runs), you are measuring the worst case, not the typical visit. That is useful for finding server problems. It is misleading if you treat it as “what my audience feels after the cache is warm.”
What to fix first (order that actually moves CWV)
Do not enable twenty toggles in one evening. You will not know what broke, and you will not know what helped.
A practical order for most WordPress sites:
1. Confirm the page cache is actually serving
View response headers on an incognito load. Look for your cache plugin’s HIT header, or your host/CDN equivalent. Cart, checkout, and account pages should stay uncached. Everything else that is public should eventually be a HIT.
If caching is not active, nothing else in this list matters as much. Fix that first. Our broader [2026 speed checklist](https://daftplug.com/blog/performance-optimization/how-to-speed-up-your-wordpress-site-in-2026-the-complete-checklist/) starts in the same place for a reason.
2. Read which Core Web Vital is failing in the field
Search Console → Experience → Core Web Vitals. Or PSI’s field section. Pick the metric that is actually red for the templates that matter (home, product, post). Fix that metric. Do not “optimize in general.”
3. If LCP is the problem, fix the LCP element
- Right-size and modern-format the hero
- – Preload it
- – Keep it out of lazy load
- – Reduce render-blocking CSS above it
- – Stop third-party scripts from racing it on first paint
4. If INP is the problem, cut main-thread work
- Delay third-party tags until interaction
- – Defer non-critical theme and plugin scripts
- – Remove plugins that inject global JS for one admin feature
- – Test mobile on a mid-range device, not only your laptop
5. If CLS is the problem, reserve space
- Width and height (or aspect-ratio) on images and embeds
- – No late banners shoved above existing content
- – Fonts that do not reflow the headline after paint
6. Only then get aggressive
Remove unused CSS. Delay more JavaScript. Speculative loading. Database cleanup. Those are real wins, and they are also the settings most likely to break a theme if you flip them all at once.
Pitfalls that keep WordPress CWV stuck
**Two full-page caches at once.** WP Rocket plus LiteSpeed plus a host cache plus a second “optimizer” that also caches HTML is a classic way to serve stale or broken pages. Pick one application-level page cache. Let the host or CDN sit in front of it if they already do. Do not stack two plugins that both think they own the HTML.
**Optimizing the archive instead of the page.** Bulk-converting every Media Library JPEG feels productive. The LCP element on the live template is what Google times. Convert and size what the page uses.
**Treating minification as an INP fix.** Smaller files help. Execution cost and long tasks matter more.
**Chasing lab 100 while field data is ignored.** A synthetic 100 on desktop is a nice screenshot. Mobile field LCP at 3.4s is still a fail.
**Lazy-loading the hero.** Still happens constantly. Still destroys LCP.
**Enabling “remove unused CSS” without testing menus and modals.** Styles for click-opened UI often look “unused” on first paint. Exclude them instead of turning the feature off forever.
**Ignoring third-party scripts because “marketing needs them.”** Marketing needs conversions. An unresponsive tap does not convert. Delay what you cannot delete.
Where Lightify fits (without pretending cache alone is enough)
[Lightify](https://daftplug.com/lightify/) is DaftPlug’s performance plugin. It is not “another cache toggle and hope.” The product page and docs are explicit about what it covers: full-page cache with background preload and smart purge, asset minification, defer and delay for JavaScript, unused CSS removal, media optimizations (including on-the-fly WebP for images the page actually uses, lazy load with the LCP image treated carefully, YouTube placeholders), bloat removal, speculative loading, database cleanup, and Core Web Vitals monitoring from real visitors.
That last part is the piece most pure cache plugins skip.
Lightify’s overview score is built from real visitor measurements on the cached homepage (LCP, INP, CLS, FCP, TTFB), weighted into one score and broken down so you can see what to fix next. It is field-shaped data from your traffic, not a single Lighthouse run on a simulated phone. Docs are clear about the tradeoffs: a quiet site needs time to collect samples, and the collector rides on cached pages, so you are measuring the experience you are trying to optimize.
It will disagree with a cold PageSpeed lab run sometimes. Both can be right. Lab finds a problem on a bad device. Lightify tells you what your visitors actually got.
On the fix side, the same plugin is where you turn on the levers that cache alone cannot pull: preload critical images, keep the hero out of lazy load, convert page-used images to WebP in the background, delay third-party JavaScript, remove unused CSS carefully, self-host third-party assets, and warm the cache from your sitemap so the first person after a purge is not the sacrificial cold hit.
Defaults are meant to be conservative. The aggressive switches (unused CSS, delay JS) are the ones to enable one at a time with a purge and a front-end check after each. Cart, checkout, and account pages are excluded from full-page cache automatically for WooCommerce-style setups. Do not run Lightify’s page cache beside another full-page cache plugin. Deactivate the old one first.
If you want the wider punch list beyond CWV diagnosis, use the [2026 speed checklist](https://daftplug.com/blog/performance-optimization/how-to-speed-up-your-wordpress-site-in-2026-the-complete-checklist/) and come back here when the remaining failures are clearly LCP, INP, or CLS rather than “the site feels slow.”
One membership, not another performance invoice
Lightify has a free version on WordPress.org. Pro unlocks the fuller optimization toolkit (including the heavier image and asset features called out on the product page).
It is also one plugin inside a DaftPlug membership. One Pro license unlocks all DaftPlug Pro plugins: Lightify, Progressify, Rankify, Generatify, and Snapshotify. Plans differ by how many sites you can activate. Features do not. New Pro plugins shipped while you are subscribed join the membership. Details and plan comparison live on [pricing](https://daftplug.com/pricing/).
That matters if your current stack is WP Rocket plus an image SaaS plus a separate CWV monitor plus something else for speculative loading. You are not required to rip everything out tomorrow. You should know the category can sit in one license instead of four renewals.
A sane weekly loop
- Check field CWV for the templates that make money.
- 2. Pick the worst metric.
- 3. Make one change aimed at that metric.
- 4. Purge cache. Retest lab on that URL. Wait for field data to move.
- 5. Only then touch the next toggle.
Caching belongs in that loop. It is step zero for TTFB and a foundation for LCP. It is not the whole exam.
If your cache plugin already did its job and the vitals are still red, stop buying another cache. Fix the hero, the scripts, and the layout shifts. Measure from real visitors. Use a performance layer that can see LCP, INP, and CLS in the same place you flip the switches.
That is the gap [Lightify](https://daftplug.com/lightify/) is built for. Install the free version, confirm cache hits, read the overview once you have traffic, and upgrade when you want the rest of the toolkit under the same membership as everything else DaftPlug ships.