In 2021, Google made Core Web Vitals an official ranking signal. Since then, the metrics have been refined — and in 2024, Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric. If your WordPress site is failing these scores, it is directly affecting where you appear in search results, not just how fast the site feels.
The three Core Web Vitals are LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and INP (Interaction to Next Paint). Each measures a different dimension of user experience. Many WordPress sites fail at least one of them without the site owner knowing.
What Are Core Web Vitals?
LCP — Largest Contentful Paint
LCP measures how long it takes for the largest visible element on the page — typically a hero image or headline — to render. It's a proxy for "how fast does the page feel like it has loaded."
- Good: under 2.5 seconds
- Needs improvement: 2.5–4.0 seconds
- Poor: over 4.0 seconds
CLS — Cumulative Layout Shift
CLS measures visual stability — specifically, how much page content unexpectedly moves around while loading. A score of 0.1 or lower is good. Anything above 0.25 is poor. CLS is the metric most often caused by images without declared dimensions or ads that load after the page content.
INP — Interaction to Next Paint
INP measures how quickly the page responds to user interactions — clicks, taps, keyboard input. It replaced FID (First Input Delay) in March 2024 because INP measures all interactions throughout the page lifecycle, not just the first one.
- Good: under 200ms
- Needs improvement: 200–500ms
- Poor: over 500ms
How to Measure Your WordPress Site's Scores
Use different tools depending on what you need to know:
- Google PageSpeed Insights (pagespeed.web.dev) — combines lab data (simulated) with real-world field data from the Chrome User Experience Report (CrUX). Best starting point. Tests both mobile and desktop.
- Google Search Console — the Core Web Vitals report shows real-world data aggregated across your actual visitors, segmented by URL group. This is the data Google uses for ranking. Check it monthly.
- Chrome DevTools — Lighthouse tab runs a detailed local audit. Performance tab shows a timeline of what loaded when. Use this for debugging specific bottlenecks, not for tracking overall scores.
Field data (real user measurements) always takes precedence over lab data when it's available. A page might score well in a lab test but fail in the field due to third-party scripts or behavior under actual load.
Fixing LCP — Largest Contentful Paint
Common Causes
- Render-blocking JavaScript and CSS in the
<head>that delays when the browser can start painting - Slow server response time (Time to First Byte above 600ms)
- Unoptimized hero image — large file size or not preloaded
Solutions
- Preload the LCP image — add a
<link rel="preload">tag for the hero image so the browser fetches it immediately. WP Rocket and LiteSpeed Cache can do this automatically. - Improve server response time — enable server-side caching, upgrade hosting if TTFB consistently exceeds 600ms.
- Use a CDN — reduces latency for visitors far from your origin server.
- Convert hero images to WebP and compress them. A 1MB hero image is almost always avoidable.
Fixing CLS — Cumulative Layout Shift
Common Causes
- Images loaded without explicit
widthandheightattributes — the browser doesn't know how much space to reserve - Web fonts causing a flash of unstyled or invisible text (FOUT/FOIT) that shifts surrounding elements
- Ad slots or embeds that expand after initial render
Solutions
- Always declare image dimensions — set explicit width and height on every
<img>tag. Modern WordPress does this for images inserted through the media library; verify your theme and page builder do not strip these attributes. - Use font-display: swap in your CSS — this tells the browser to show a fallback font immediately and swap in the web font once loaded, preventing invisible text from collapsing layout.
- Reserve space for ads and embeds — define fixed-height containers before the content loads.
Fixing INP — Interaction to Next Paint
Common Causes
INP failures are almost always caused by heavy JavaScript on the main thread. Every click or tap triggers a chain of event handlers — if any of them block the main thread for more than 200ms, INP fails. WordPress sites with many active plugins are particularly susceptible because each plugin can register its own event listeners and load its own JS files.
Solutions
- Defer non-critical JavaScript — analytics scripts, chat widgets, social share buttons, and newsletter pop-ups do not need to block the main thread. Use the
deferorasyncattribute, or load them after user interaction. - Reduce plugin count — audit your active plugins. Every plugin that loads JS site-wide is a potential INP contributor. Deactivate anything not actively being used.
- Use a lightweight theme — multipurpose themes that load their full feature set on every page add significant JS overhead. Themes like GeneratePress or Kadence are built with performance as a priority.
Maintaining Good Scores Over Time
Achieving good Core Web Vitals scores once is the easy part. The harder part is keeping them. Scores regress predictably: you install a new plugin, a theme update adds a new slider, a marketing team embeds a third-party script — and suddenly LCP jumps above 3 seconds and INP crosses the "poor" threshold.
Set up a monthly review cadence using Search Console's Core Web Vitals report. When you see a URL group move from "good" to "needs improvement," investigate immediately before it spreads. Google's CrUX data has a 28-day rolling window, so regressions can cost you ranking position before you notice them.
Good Core Web Vitals scores are not a one-time achievement. Every plugin you add, every script a marketing tool requires, every new page template is a potential regression. Treat performance as an ongoing maintenance discipline — not a box to check once and forget.