WordPress Core Web Vitals: What They Are and How to Fix Them
Core Web Vitals are three metrics Google uses as part of its ranking algorithm. The marketing copy makes them sound like a critical SEO factor; the engineering reality is they’re one input among many and affect rankings modestly but consistently. They matter more for user experience than for rank, and the fixes for both purposes are the same.
This guide explains each metric in WordPress-specific terms, what causes most sites to fail, and the working fixes.
The Three Metrics
Largest Contentful Paint (LCP). How long it takes for the largest visible element on the page to render. Usually the hero image, a video, or a large block of text. Google’s thresholds: under 2.5 seconds is good, 2.5–4 seconds needs improvement, over 4 seconds is poor.
Interaction to Next Paint (INP). How long the page is unresponsive when a user clicks, taps, or types. Replaced First Input Delay in 2024. Thresholds: under 200ms is good, 200–500ms needs improvement, over 500ms is poor.
Cumulative Layout Shift (CLS). How much the page jumps around as it loads. A score, not a time. Thresholds: under 0.1 is good, 0.1–0.25 needs improvement, over 0.25 is poor.
How to Measure Them
PageSpeed Insights (pagespeed.web.dev) is the canonical source. It uses two data streams:
- Field data (from real Chrome users) — what Google actually uses for ranking. Available when your site has enough Chrome traffic.
- Lab data (from a controlled test) — what you see immediately. Useful for diagnosing but not what affects ranking.
Google Search Console → Core Web Vitals report — shows field data trends over time across all pages. The right place to check whether changes are moving the actual numbers Google sees.
WebPageTest — more detailed, shows the waterfall and identifies which specific assets are slow.
Don’t trust the PageSpeed “score” number — it’s a composite that weights metrics in ways that hide what’s actually wrong. Look at the underlying metrics directly.
Fixing LCP (Largest Contentful Paint)
The most common LCP problems on WordPress sites, in order of frequency:
1. Slow server response (TTFB). If Time to First Byte is over 1 second, nothing else matters — LCP can’t be fast on a slow server. Fix: better hosting, page caching, or eliminating slow plugins that run on every request.
2. Hero image too large. A 4 MB unoptimized hero image takes seconds to download even on fast connections. Fix: compress to under 200KB, serve as WebP, and ensure dimensions match the rendered size.
3. Lazy-loaded hero image. Lazy loading is good for below-the-fold images, bad for the hero. WordPress’s automatic lazy loading sometimes catches the hero image and delays LCP. Fix: add fetchpriority="high" and loading="eager" to the hero image, or use a plugin that excludes above-the-fold images from lazy loading.
4. Render-blocking JavaScript. Scripts in the block rendering until they load and execute. Fix: defer non-critical scripts. Most caching plugins (WP Rocket, LiteSpeed) do this automatically; verify the configuration is enabled.
5. Render-blocking CSS. Large stylesheets block rendering. Fix: inline critical CSS (the styles needed for above-the-fold content), defer the rest. Same caching plugins handle this.
Fixing INP (Interaction to Next Paint)
INP is the harder metric to fix because it’s about JavaScript execution time, not file size.
1. Too many JavaScript plugins. Each plugin that adds JavaScript (chat widgets, popup tools, analytics, A/B testing, page builders) increases the script the browser must execute. Fix: audit installed plugins and remove anything not earning its place. The five plugins that “just add a small script” sum to a real performance cost.
2. Heavy page builders. Elementor, Divi, WPBakery render with significant JavaScript overhead. Fix options: use lighter page builders (GenerateBlocks, Kadence Blocks), or accept the tradeoff if the builder’s productivity gains outweigh the performance cost. There’s no free lunch here.
3. Third-party scripts loading synchronously. Tag managers, chat widgets, embedded videos. Fix: load these with async or defer, or use a tag manager configured to load scripts on user interaction rather than page load.
4. Long tasks in your theme’s JavaScript. Custom theme code that does heavy work on every page load. Fix: requires actual code review — this is the case where DIY hits its limit and a technical SEO review is more economical.
Fixing CLS (Cumulative Layout Shift)
CLS is usually the easiest of the three to fix because the causes are specific.
1. Images without dimensions. When an image loads, if the browser doesn’t know its dimensions in advance, the page jumps to accommodate it. Fix: every width and height attributes. Modern WordPress adds these automatically for media library images; verify they’re present on custom or third-party images.
2. Ads or embedded content loading late. A YouTube embed, an ad block, a chat widget — anything that loads after the page renders and then pushes content around. Fix: reserve space in advance using a fixed-height container that matches the expected dimensions of the late-loading content.
3. Font swap (FOUT/FOIT). Custom fonts load late, the page re-renders with the new font, layout shifts. Fix: use font-display: optional in CSS or preload critical fonts. WP Rocket and other optimization plugins have font display settings.
4. Animations that change layout. Sliders, accordions, expanding menus that push other content as they animate. Fix: use transform (which doesn’t trigger layout) instead of changing properties like width, height, or margin.
What Plugin Does Most of This
Caching plugins increasingly include all of the above optimizations. The honest comparison:
- WP Rocket — paid, comprehensive, easiest to configure, handles most Core Web Vitals issues out of the box.
- LiteSpeed Cache — free if your host runs LiteSpeed servers, comparable feature set to WP Rocket.
- WP Super Cache — free, basic caching, doesn’t address most non-caching optimizations.
- W3 Total Cache — free, more granular, requires more configuration knowledge.
For a single site with budget for it, WP Rocket is the path of least resistance. For multi-site setups or hosts that already include caching, LiteSpeed or the host’s built-in caching is fine.
When the Plugin Approach Hits Its Limit
Plugins handle 80% of Core Web Vitals issues. The remaining 20% require:
- Theme-level changes (replacing a heavy theme, refactoring custom code).
- Image optimization that requires reviewing each asset.
- Database optimization beyond what plugins handle.
- Identifying specific JavaScript files causing INP failures.
This is the case where DIY stops being economical. Synergetic’s Technical SEO service covers Core Web Vitals work as part of the broader technical health audit — fixed price, scope defined in advance, results measured against PageSpeed Insights field data. The Services page lists what’s included.
Realistic Expectations
A neglected WordPress site can usually go from “Poor” to “Good” on all three Core Web Vitals with a week of focused work. From “Needs Improvement” to “Good” is usually a few days of focused work. From already-Good to “even better” yields diminishing returns and isn’t worth pursuing for its own sake — Google doesn’t reward you extra for a 90 over a 95.
For the broader speed optimization picture, see WordPress Speed Optimization. For ecommerce sites specifically, the speed-conversion relationship is detailed at WooCommerce Speed vs Conversion Rate.