Core Web Vitals are Google’s three metrics for real user experience: Largest Contentful Paint (LCP) measures how fast the main content appears, Interaction to Next Paint (INP) measures how quickly the page responds to taps and clicks, and Cumulative Layout Shift (CLS) measures how much the layout jumps. Good scores are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1.
This is the pillar of my speed series. The supporting guides go deeper into improving LCP, image formats, fonts and Total Blocking Time.
What are Core Web Vitals metrics?
They are three metrics, each with a threshold for “good,” “needs improvement” and “poor,” measured at the 75th percentile of real page loads. That means at least three out of four visits should meet the “good” threshold for the page to pass.
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP | Loading of main content | ≤ 2.5 s | > 4.0 s |
| INP | Responsiveness to interactions | ≤ 200 ms | > 500 ms |
| CLS | Unexpected layout movement | ≤ 0.1 | > 0.25 |
Field data vs lab data
This is the most misunderstood part.
- Field data comes from real Chrome users (the Chrome UX Report). PageSpeed Insights shows it at the top when your site has enough traffic, and Search Console groups URLs by status. This is what Google’s systems use.
- Lab data comes from a single simulated test, such as Lighthouse. It is reproducible and great for debugging, but it is not your users’ experience.
A Lighthouse score of 100 with failing field data is still failing. A Lighthouse score in the 70s with passing field data is fine for users.
How to test Core Web Vitals
- PageSpeed Insights for a URL: field data (if available) plus a Lighthouse run.
- Search Console → Core Web Vitals for site-wide groups of URLs.
- Chrome DevTools Performance panel to record a load or an interaction and see exactly what the main thread is doing.
- The web-vitals JavaScript library if you want to collect your own field data into analytics.
Test the templates that matter: home, a category, a product, a blog post, checkout. Test on mobile first.
LCP: loading
LCP is the render time of the largest image or text block in the viewport. On most sites it is the hero image, a product image, or the main heading.
Typical causes of poor LCP:
- Slow server response (high Time to First Byte).
- The LCP image is lazy-loaded, discovered late, or too heavy.
- Render-blocking CSS and fonts.
- Client-side rendering that delays content.
Quick wins: page caching, serving the hero image in a modern format at the right size, fetchpriority="high" on that image, and never lazy-loading it. Full steps in how to improve LCP in WordPress.
INP: responsiveness
INP observes the latency of interactions (clicks, taps, key presses) during the whole visit and reports one of the slowest. It replaced First Input Delay in March 2024 because FID only measured the first interaction’s input delay.
Typical causes of poor INP:
- Long JavaScript tasks blocking the main thread.
- Heavy third-party scripts: chat widgets, tag managers, ad and tracking scripts.
- Expensive event handlers that update large parts of the page.
- Huge DOM sizes from page builders.
Fixes: remove or delay non-essential scripts, break up long tasks, and keep handlers light. The lab proxy for this is Total Blocking Time; see reducing TBT.
CLS: visual stability
CLS sums unexpected layout shifts. The classic example: you are about to tap a link, an image loads above it, and you tap an ad instead.
Typical causes:
- Images and iframes without width and height (or
aspect-ratio). - Banners, cookie bars or notices injected above content.
- Web fonts swapping with very different metrics.
- Late-loading widgets (reviews, embeds) without reserved space.
Fixes:
<img src="hero.avif" width="1600" height="900" alt="..." />
.embed { aspect-ratio: 16 / 9; }
.notice { position: fixed; bottom: 0; } /* overlay instead of pushing content */
For fonts, use fallback font metric overrides (size-adjust, ascent-override) or a similar fallback to reduce the swap jump.
A prioritised fix plan
- Server and caching. Page cache, object cache if the host supports it, a CDN. Without a reasonable TTFB, nothing else helps much.
- The LCP element. Right size, right format, high priority, not lazy.
- CSS and fonts. Remove unused CSS where safe, inline critical CSS, preload the one or two fonts used above the fold.
- JavaScript. Remove, delay or defer. Audit third-party tags.
- Layout stability. Dimensions on media, reserved space for dynamic elements.
- Re-measure in the field after 28 days, since field data is a rolling window.
Do Core Web Vitals matter for SEO?
They are part of Google’s page experience signals, but Google has been clear that great content with weaker vitals can still rank. Treat speed as a user-experience and conversion investment first; the SEO benefit follows. It fits into a wider technical SEO audit.
WordPress-specific notes
- A good caching and optimisation plugin covers much of the list, but configure it carefully. Aggressive “delay all JavaScript” settings can break menus and sliders; test thoroughly.
- Page builders add DOM and CSS weight; reuse templates and avoid nesting.
- Each plugin can add scripts site-wide; a plugin audit is often the biggest win.
- Hosting matters: an overloaded shared server shows up in TTFB on every page.
Common mistakes
- Chasing a Lighthouse 100 instead of fixing field data.
- Testing only the home page on desktop.
- Lazy-loading every image, including the hero.
- Stacking two optimisation plugins that both minify and combine files.
If your site is failing Core Web Vitals and you want a clear plan, look at my services or contact me.
Frequently asked questions
What are the three Core Web Vitals?
Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability.
Do Core Web Vitals affect SEO?
Google uses page experience signals, including Core Web Vitals, in its ranking systems, but relevance and content quality matter more. Good vitals help most when competing pages are otherwise similar.
Why is my Lighthouse score different from PageSpeed Insights field data?
Lighthouse runs one simulated test on one device profile. Field data comes from real Chrome users over 28 days on their own devices and networks, so they often differ.
When did INP replace FID?
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024.
