Core Web Vitals Explained

Core Web Vitals are three specific metrics Google uses to evaluate user experience and rank pages. Since May 2021, Core Web Vitals became an official ranking signal. Understanding these three metrics and how to measure them is essential.

What Are Core Web Vitals?

Core Web Vitals are three metrics measuring page experience from a user's perspective:

LCP (Largest Contentful Paint): How fast the main content loads.
INP (Interaction to Next Paint): How responsive the page is to user input.
CLS (Cumulative Layout Shift): How stable the layout is (how much things move around).

These are measured using field data from actual users, not lab scores. This is critical: Google ranks based on real-world performance, not test scores.

When CWV Became Ranking Signals

May 2021: Desktop and mobile CWV became a ranking factor. 2024: INP officially replaced FID (First Input Delay) as the responsiveness metric.

LCP: Largest Contentful Paint

LCP measures when the largest visible element on the page finishes loading. Usually, this is an image, headline, or video. LCP represents the user's perception of how fast the page loaded.

Good vs Poor LCP

Good: Under 2.5 seconds (75th percentile of real users)
Needs improvement: 2.5 to 4 seconds
Poor: Over 4 seconds

What Causes Slow LCP

Unoptimised hero images (too large, not compressed, wrong format)
Slow server response time (TTFB)
Render-blocking JavaScript or CSS
Fonts loading slowly and blocking text rendering

How to Fix LCP

Optimise your hero image: Compress it, use WebP format, resize for different devices, lazy-load if below fold.
Improve server response time: Upgrade hosting, use a CDN, optimise database queries.
Defer render-blocking resources: Move scripts to the end of the body or mark as async/defer. Inline critical CSS.
Preload critical resources: Use <link rel="preload"> for fonts and images.

INP: Interaction to Next Paint

INP measures the time from when a user interacts with the page (click, tap, keyboard input) until the browser paints the response to the screen. It reflects responsiveness — how snappy the page feels when you click buttons or interact with elements.

Good vs Poor INP

Good: Under 200 milliseconds (75th percentile)
Needs improvement: 200 to 500 ms
Poor: Over 500 ms

What Causes Slow INP

Heavy JavaScript execution blocking the main thread
Large DOM trees taking time to update
Unoptimised event handlers running expensive operations
Third-party scripts consuming resources

How to Fix INP

Reduce JavaScript bundle size: Ship less code; code-split; lazy-load non-critical JS.
Break up long tasks: Use techniques like requestIdleCallback or Web Workers to prevent the main thread from blocking.
Optimise event handlers: Avoid expensive operations in click handlers; debounce or throttle events.
Audit third-party scripts: Lazy-load ads, analytics, and chat widgets that aren't critical.

CLS: Cumulative Layout Shift

CLS measures how much the page layout shifts unexpectedly as it loads. Example: an ad loads below some text, pushing the text down. The user was about to click a button, but it moved, and they clicked the ad instead. This is a poor experience.

Good vs Poor CLS

Good: Under 0.1 (75th percentile)
Needs improvement: 0.1 to 0.25
Poor: Over 0.25

What Causes Layout Shifts

Images without explicit width/height attributes. The browser doesn't know the space to reserve, so it's surprised when the image loads.
Ads or embeds loading late and pushing content down.
Web fonts loading and changing text size.
Animations triggered late in the page load.

How to Fix CLS

Always set explicit dimensions on images: <img src="image.jpg" width="400" height="300" />
Reserve space for ads: Don't let ads surprise the layout. Use a container with a fixed height.
Use font-display: swap: Load web fonts without blocking text rendering and causing shifts.
Avoid inserting DOM elements above existing content: Don't add ads or widgets that shift the page after load.

Where to Check Your Core Web Vitals

Google Search Console (Field Data)

GSC shows your real Core Web Vitals performance from actual users. Go to Experience > Core Web Vitals to see which metrics are good, need improvement, or poor. This is your primary ranking metric.

PageSpeed Insights (Field and Lab Data)

PSI shows field data (if available) and lab data. Focus on the field data tab. Lab data is diagnostic — it shows what could be wrong, but doesn't determine your ranking. Field data determines your ranking.

Chrome DevTools (Lab Data)

Open DevTools > Lighthouse. Run an audit to see lab-based metrics. Again, this is for diagnosis, not ranking evaluation.

Field vs Lab Mindset

Don't obsess over lab scores if your field data is good. A page with a "poor" Lighthouse score but "good" Core Web Vitals in GSC will rank well. Field data is what matters for SEO.

Monitoring and Iteration

Core Web Vitals data takes time to accumulate. Don't expect results overnight. After making optimisations, wait a few days for fresh data to collect. Monitor trends in GSC. If you improve LCP but INP worsens, you've optimised the wrong metric.

Prioritise based on which metrics are worst. If LCP is poor but INP and CLS are good, focus on LCP. Make one improvement at a time so you can measure the impact.