Core Web Vitals for WordPress
Core Web Vitals are three measurements of real-world page experience: loading, responsiveness and visual stability. Google recommends good scores, but it does not present them as a ranking guarantee. This guide gives the official thresholds, how to measure them properly, and the fixes I start with on WordPress sites.
- Thresholds from Google and web.dev
- Field data first, lab data second
- WordPress fixes labelled as my experience
| Metric | Measures | Good |
|---|---|---|
| LCP | Loading | 2.5 seconds or less |
| INP | Responsiveness | under 200 ms |
| CLS | Visual stability | below 0.1 |
Measured at the 75th percentile of page loads, mobile and desktop separately.
What Google actually says about them
Google’s page on Core Web Vitals says site owners should aim for good scores, and that the metrics are part of broader page experience signals that align with what its core ranking systems try to reward. It does not say they guarantee a ranking, and it does not claim they outweigh content quality.
My practical reading: poor scores can cost you visitors who leave before the page works, so they are worth fixing. A slow site with the best content in its niche may still rank, and a fast site with weak content will not. Fix them as part of technical SEO, not instead of it.
What each one means
- LCP: how soon the largest visible element renders.
- INP: how quickly the page responds to clicks, taps and key presses.
- CLS: how much content jumps around while loading.
Field data before lab data
What real visitors experienced
web.dev defines field data as measurements from real visits, for example through the Chrome User Experience Report. It reflects real devices and networks. Google points site owners to the Core Web Vitals report in Search Console and to PageSpeed Insights.
Controlled tests for debugging
Lighthouse and Chrome DevTools give repeatable tests that catch regressions before launch. web.dev notes lab testing does not replace field measurement. Lighthouse cannot measure INP because it has no user input, so Total Blocking Time acts as a proxy.
Compare audit tools in site audit tools and extensions in best SEO Chrome extensions.
Fixing slow loading (LCP)
web.dev splits LCP into four parts: server response, load delay, load duration and render delay. All four need attention, because trimming one can shift time to another.
Never lazy-load the LCP image
Lazy loading delays the fetch until after layout. Keep the hero image in the initial HTML and mark the likely LCP image with fetchpriority high, used sparingly.
Speed up the server
Cut redirects, serve cached pages from a CDN and avoid cache-busting query strings. Slow first byte caps everything after it.
WordPress: cache and host
A page cache plugin or server-level cache usually gives the biggest first-byte win. If a site is slow even when cached, the hosting may be the limit; see LiteSpeed hosting and VPS options.
Fixing slow responses (INP)
Three phases
An interaction has input delay, processing time and presentation delay. Busy main-thread work, such as script loading, causes input delay.
Break up long tasks
Shrink or defer script work, split heavy event handlers into smaller tasks, and keep the DOM small. Large DOMs slow rendering on load and during interactions.
WordPress: audit plugins and scripts
Sliders, popups, chat widgets and page-builder effects are common sources of main-thread work. Remove what you do not need before tuning anything else.
Fixing layout shift (CLS)
Reserve space
- Give images, video and embeds width and height attributes, or use CSS aspect-ratio.
- Reserve room for ads and embeds; do not collapse the space if nothing loads.
- Avoid inserting content above what the visitor is reading.
Stabilise fonts and animation
- Preload critical fonts and choose a close fallback font.
- Use font-display optional to avoid a late swap.
- Animate with transform, not properties that trigger layout.
The order I work in on WordPress
This sequence is my own practice, not a Google rule.
Read the field report
Open Search Console’s Core Web Vitals report and PageSpeed Insights for your key templates. Note which metric fails, on mobile or desktop.
Fix the template, not the page
Failures usually come from a shared template: header, hero, theme or plugin script. One fix then lifts many URLs.
Remove before you optimise
Delete unused plugins and widgets first. Then cache, then images, then script deferral.
Re-test and wait
Field data is based on real visits over time, so improvements show gradually. Re-check in Search Console after a few weeks rather than hours.
I do this work in my WordPress SEO services.
Questions people ask
What are good Core Web Vitals scores?
Google and web.dev give LCP of 2.5 seconds or less, INP under 200 milliseconds and CLS below 0.1, measured at the 75th percentile.
Do Core Web Vitals affect rankings?
Google says they are part of page experience signals aligned with what its ranking systems reward. It does not say they guarantee rankings.
Why does PageSpeed Insights show different numbers from Search Console?
One may show lab data from a single test and the other field data from real visits. Trust field data for pass or fail.
Why can Lighthouse not measure INP?
web.dev explains that Lighthouse has no user input, so Total Blocking Time is used as a stand-in.
Is a caching plugin enough?
It helps server response and loading, but INP and CLS often need script and layout fixes as well.
How long until improvements show up?
Field data builds from real visits, so allow a few weeks before judging.
Sources
- Google Search Central, Understanding Core Web Vitals and Google Search
- web.dev, Web Vitals
- web.dev, Optimize Largest Contentful Paint
- web.dev, Optimize Interaction to Next Paint
- web.dev, Optimize Cumulative Layout Shift