Core Web Vitals: The Complete Guide (LCP, CLS, INP)

What are Core Web Vitals?

Three UX metrics created by Google that directly influence SEO rankings. A poor score equals lost visibility.

1. LCP – Largest Contentful Paint

What it measures: How long it takes for the largest element (usually a hero image or heading) to appear.

Goal: < 2.5 seconds

Common reasons for a poor score: - Large unoptimised hero images - Slow server response (TTFB > 600ms) - Render-blocking CSS/JS files - Web fonts loading late

Solutions: - Preload the critical hero image: <link rel="preload" as="image"> - Use WebP/AVIF formats - Implement a CDN - Use font-display: swap

2. CLS – Cumulative Layout Shift

What it measures: How much the page "jumps" during loading. It is frustrating when a button moves just as you try to click it.

Goal: < 0.1

Common causes: - Images without width/height attributes - Ads that load later - Web fonts (FOUT) - Dynamic content

Solutions: - Add width and height to all images - Reserve space for advertisements - Use font-display: optional or swap with size-adjust - Implement CSS aspect-ratio

3. INP – Interaction to Next Paint

Replaced FID in 2024. Measures how quickly the page responds to a user's click, tap, or keypress.

Goal: < 200ms

Common causes: - Heavy JavaScript tools - Excessive event listeners - Third-party scripts (chat, analytics) - Unoptimised React/Vue pages

Solutions: - Code splitting - Debounce and throttle techniques - Use requestIdleCallback() for heavy tasks - Remove unused third-party scripts

How to measure?

1. PageSpeed Insights – pagespeed.web.dev
2. Google Search Console → Core Web Vitals report
3. Chrome DevTools → Performance tab
4. CrUX (Chrome User Experience Report) – real user data

Lab data vs field data – why the scores disagree

PageSpeed Insights shows two different things and they get confused constantly. The top block ("Discover what your real users are experiencing") is field data from CrUX: measurements from real visitors over the last 28 days. The bottom block is lab data – a single simulated load in the Lighthouse engine, on a fixed throttled 4G connection and a slowed-down CPU.

Google only uses field data for ranking. That has three practical consequences:

• A Lighthouse score of 100 does not mean Core Web Vitals are "passing". It is a prediction, not a verdict.
• After a fix, it can take up to 28 days for the Search Console report to turn green. Do not conclude after three days that the fix did not work.
• If a page has too little traffic, no page-level field data is shown and Google falls back to origin-level data. On a small site the home page then influences how subpages are judged.

A metric passes when 75% of loads are under the threshold, measured separately for mobile and desktop. Mobile is almost always the one that fails.

Finding the actual bottleneck

Looking at the score does not tell you what to fix. A practical order:

1. Chrome DevTools -> Performance -> record a load with mobile emulation and 4x CPU throttling. Find the LCP marker on the timeline and see which element it points at.
2. DevTools -> Network -> sort by Time. If TTFB is above 600 ms, the problem is not in the front end at all – it is the server or the cache layer.
3. For CLS, enable DevTools -> Rendering -> Layout Shift Regions. The exact areas that jump flash on screen.
4. For INP, use the Interactions track in the Performance panel. It shows which event handler creates the long task.
5. The web-vitals JS library on the site itself reports real user measurements into your analytics, so you are not dependent on month-old CrUX snapshots.

The usual culprits on a WordPress site

Most small-business sites fail for the same handful of reasons, and none of them require a rebuild:

• A slider on the home page. Revolution Slider and friends load several large images plus their own JavaScript before first render. The slider is almost always the most expensive element on the page and rarely the one visitors use.
• Three caching plugins at once. Conflicting caches produce the situation where "optimising" CSS actually delays it.
• Google Fonts from a third-party domain. Fetching the font adds a separate DNS and TLS round trip. Self-hosting a WOFF2 file with font-display: swap and a size-adjust value fixes both LCP and CLS.
• A chat widget and four tracking pixels. Every third-party script runs on the main thread and hits INP directly. Load them after the first user interaction, not on page load.
• Shared hosting without an object cache. If TTFB swings between 800 ms and 2 s, no front-end trick helps – you need better hosting or server-side page caching.

A realistic timeline

On a typical WordPress site the work usually splits like this: image formats, dimensions and hero preload about half a day; self-hosting fonts and reserving layout space a couple of hours; deferring third-party scripts half a day; server-side caching and TTFB anywhere from an hour to a full day depending on the host. After that you wait for the CrUX window to refill.

Do not optimise what you are not measuring. If LCP is 4.2 s and CLS is 0.02, touching CLS gains nothing – all of the effort belongs in the largest element.

Summary

Core Web Vitals are technical but essential. The good news: proper maintenance improves all three simultaneously. The bad news: without maintenance, they tend to degrade with every new plugin update.