Definition
Core Web Vitals are Google's three user-experience metrics — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — used as ranking signals in Google Search since 2021.
LCP measures loading: when does the largest visible element render? Target: under 2.5s. INP (which replaced FID in March 2024) measures responsiveness: how long does the page take to respond to user interaction? Target: under 200ms. CLS measures visual stability: how much does the page shift unexpectedly? Target: under 0.1.
Core Web Vitals are evaluated on real-user data via the Chrome User Experience Report (CrUX). Lab tools (Lighthouse, WebPageTest) approximate but don't replace field data. A page can score 100 in Lighthouse and fail Core Web Vitals if real users experience it differently — slower devices, slower networks, third-party scripts that don't show up in lab tests.
Origin
Announced by Google in May 2020, became a ranking signal in June 2021. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
How it works
- Pull field data from Search Console > Core Web Vitals or PageSpeed Insights.
- Identify failing pages — typically the templates, not individual URLs.
- Diagnose: LCP fails usually point to slow images or render-blocking resources; INP fails to heavy JS; CLS to layout-shifting content (images without dimensions, late-loading ads).
- Fix in the design system or template, not page-by-page.
- Re-measure after 28 days — CrUX data is a 28-day rolling window.
When to use it
Use when
- On every public page — Core Web Vitals affect SEO directly.
- Before any major template change.
- When mobile rankings drop without an explainable cause.
Skip when
- As the only performance metric. Real performance work goes deeper.
- Through Lighthouse alone. Lab data misses real-user issues.
Key metrics
- LCP — target under 2.5s (75th percentile).
- INP — target under 200ms.
- CLS — target under 0.1.
- % of URLs passing all three on mobile.
Examples
- We fixed LCP by lazy-loading hero images and the page jumped from 4.2s to 1.8s.
- INP failed because of a third-party tag that ran 320ms of JS on click. Removed it; INP dropped to 90ms.
- Core Web Vitals isn't a separate optimisation; it's what good performance looks like.
In practice at Makreate
Makreate's website-development engagements ship pass-Core-Web-Vitals as a default. We bake performance into the build pipeline — image dimensioning to prevent CLS, route-level code splitting for INP, prefetching for LCP — so the result holds up after launch. A recent ecommerce client had 23% of their URLs failing on mobile. We rebuilt the product-list template, optimised image delivery, and removed two render-blocking analytics tags. After the 28-day CrUX window, 96% of URLs passed and organic mobile traffic climbed 18% over three months.
Website Design & Development →Common mistakes
- Optimising for Lighthouse instead of CrUX. Lab and field disagree all the time.
- Treating Core Web Vitals as a one-off project. They drift back without monitoring.
- Forgetting mobile. Most pages fail on mobile, pass on desktop, and Google ranks on mobile.
- Chasing 100/100 scores. Pass thresholds matter; the absolute number doesn't.
Frequently asked
How heavily does Google weight Core Web Vitals?
Officially a ranking signal; in practice, modest weight. Pages that fail won't tank — but on competitive queries, all else equal, pass beats fail.
Why did INP replace FID?
FID measured first input only; INP measures all interactions over a session. INP catches issues FID missed (especially on JS-heavy SPAs).
How fresh is CrUX data?
28-day rolling window. Changes take ~4 weeks to show up. Plan accordingly.