1. What Are Core Web Vitals?
Core Web Vitals are a subset of Google's Web Vitals initiative — a set of metrics that measure real-world user experience on the web. They are directly incorporated into Google's search ranking algorithm as part of the Page Experience signal.
The three Core Web Vitals measure different dimensions of user experience:
- LCP (Largest Contentful Paint) — How fast does the page load its main content?
- INP (Interaction to Next Paint) — How quickly does the page respond to user interactions?
- CLS (Cumulative Layout Shift) — Does the page layout jump around unexpectedly?
Google measures Core Web Vitals using field data — real user data collected from Chrome browsers via the Chrome User Experience Report (CrUX). This means your scores are based on actual users visiting your site, not just lab tests. A site can pass lab tests but fail real-user Core Web Vitals if the lab environment doesn't match real-world conditions.
What changed in 2024: On March 12, 2024, Google officially replaced FID (First Input Delay) with INP (Interaction to Next Paint) as a Core Web Vital. FID only measured the delay before the first interaction could be processed. INP is more comprehensive, measuring the full interaction latency throughout the entire page lifecycle.
2. LCP — Largest Contentful Paint
LCP measures the time from when the user starts loading a page to when the browser renders the largest visible content element in the viewport. This is typically a hero image, a full-width banner, or the main headline text.
| LCP Value | Rating | Impact |
|---|---|---|
| 0 – 2.5s | Good | Eligible for ranking boost. Users experience fast loading. |
| 2.5s – 4.0s | Needs Improvement | Noticeable loading delay. Users may leave before page is ready. |
| > 4.0s | Poor | Significant ranking penalty risk. High bounce rate likely. |
What Causes Poor LCP?
-
⚠
Slow server response times (TTFB > 600ms) — Use a CDN, optimize database queries, enable HTTP/2, upgrade hosting.
-
⚠
Unoptimized LCP image — Image is not compressed, wrong format (use WebP/AVIF), not preloaded with
<link rel="preload">. -
⚠
Render-blocking resources — CSS or JS files in the
<head>that block page rendering. Adddeferto scripts, inline critical CSS. -
⚠
Client-side rendering — Pages built entirely with JavaScript take longer for the browser to show content. Use SSR or static generation to deliver HTML immediately.
How to Fix LCP
- 1. Identify the LCP element — Open Chrome DevTools → Performance tab → run a recording. The LCP element is highlighted with a dashed border.
- 2. Preload the LCP image — Add
<link rel="preload" as="image" href="/hero.webp">in the<head>. Fetch Priority API: addfetchpriority="high"to the image tag. - 3. Compress images — Use WebP or AVIF format. Serve appropriately sized images with srcset. Aim for LCP images under 50–100KB.
- 4. Use a CDN — Serve assets from edge nodes close to users. A CDN can cut TTFB by 40–70% for global users.
- 5. Remove render-blocking CSS/JS — Inline critical CSS. Use
deferorasyncon non-critical scripts.
3. INP — Interaction to Next Paint
New since March 12, 2024: INP replaced FID as an official Core Web Vital. If you have documentation or tools referencing FID, they need to be updated.
INP measures the latency of all user interactions throughout a page's lifecycle — clicks, taps, and keyboard presses. It reports the worst interaction latency (with some outlier mitigation for pages with many interactions). It measures from the moment of user input to the moment the next visual frame is painted.
Unlike FID, which only measured the first interaction on page load, INP captures every interaction — clicks on buttons, form inputs, accordion opens, menu toggles — throughout the entire user session.
| INP Value | Rating | User Experience |
|---|---|---|
| 0 – 200ms | Good | Interactions feel immediate and snappy. |
| 200ms – 500ms | Needs Improvement | Noticeable delay — users sense the lag on interactions. |
| > 500ms | Poor | Sluggish UI. Users may think the site is broken. |
What Causes Poor INP?
-
⚠
Long JavaScript tasks (>50ms) — Heavy JS execution blocks the main thread. Break long tasks with
setTimeout(0)orscheduler.yield(). -
⚠
Excessive DOM size — Large DOMs slow rendering. Pages with 1,500+ nodes see significant INP degradation.
-
⚠
Third-party scripts — Analytics, chat widgets, ad scripts running in the main thread. Use
async/deferand web workers where possible. -
⚠
Synchronous DOM updates — Forced reflows/repaints from reading layout properties (offsetWidth, getBoundingClientRect) before writing DOM updates.
How to Fix INP
- 1. Profile with Chrome DevTools — Performance panel → record interactions → look for long tasks (red blocks). INP is shown in the performance summary.
- 2. Break up long tasks — Use
setTimeout,requestIdleCallback, or the Scheduler API to yield to the main thread between tasks. - 3. Reduce JS bundle size — Tree-shake unused code, code-split by route, lazy-load components not visible on initial load.
- 4. Audit third-party scripts — Remove unnecessary trackers. Load marketing scripts
async. Consider Web Workers for heavy computation. - 5. Use
content-visibility: auto— This CSS property skips rendering of off-screen content, significantly reducing render work for long pages.
4. CLS — Cumulative Layout Shift
CLS measures how much the visible page content moves unexpectedly during loading. When elements shift — a button you were about to click moves down, text you were reading jumps up — it creates a jarring experience. CLS calculates a score based on the impact fraction (what portion of the viewport shifted) multiplied by the distance fraction (how far elements moved).
| CLS Score | Rating | User Experience |
|---|---|---|
| 0 – 0.1 | Good | Stable layout. Users can interact confidently. |
| 0.1 – 0.25 | Needs Improvement | Noticeable shifts. Potential misclicks on shifted buttons. |
| > 0.25 | Poor | Significant layout instability. Frustrating user experience. |
What Causes Poor CLS?
-
⚠
Images without dimensions — Browser reserves no space before image loads. Add explicit
widthandheightattributes or CSSaspect-ratio. -
⚠
Ads, embeds, iframes without reserved space — Ad slots that load content of unknown size push other elements down.
-
⚠
Dynamically injected content — Cookie banners, notification bars, or promotional banners injected above existing content after page load.
-
⚠
Web fonts causing FOUT/FOIT — Custom fonts loading after initial render can cause text to resize and shift surrounding elements.
How to Fix CLS
- 1. Always set image dimensions — Add
width="800" height="600"attributes to every image, or use CSSaspect-ratio: 4/3. This lets the browser reserve space before the image loads. - 2. Reserve space for ads/embeds — Use a container with
min-heightequal to the expected ad size. If the ad doesn't load, the space collapses gracefully. - 3. Pre-reserve space for banners — Use
min-heightplaceholders for cookie consent or notification banners before JavaScript renders them. - 4. Use
font-display: optionalorswap— Preload critical web fonts to reduce FOUT and the layout shifts it causes. - 5. Animate only
transformandopacity— CSS animations that change layout properties (width, margin, padding, top) trigger layout shifts. Usetransform: translateY()instead.
5. How Core Web Vitals Affect Google Rankings
Core Web Vitals are a confirmed Google ranking factor as part of the broader Page Experience signal, which Google began rolling out in June 2021. Google uses field data from real Chrome users (via CrUX) to assess your pages — not lab data from PageSpeed Insights.
Key things to understand about how Google uses Core Web Vitals for ranking:
- 75th percentile threshold — Google requires that at least 75% of real-user visits to a URL meet the "good" threshold for all three metrics to qualify as having "good" Core Web Vitals.
- URL-level, not site-level — Each URL is evaluated independently. High-traffic pages that fail can drag rankings for those URLs even if most of your site passes.
- Tiebreaker, not primary signal — Content relevance and authority (links, E-E-A-T) outweigh Core Web Vitals. Poor CWV can prevent ranking gains even with strong content, but excellent CWV alone won't overcome weak content.
- Mobile vs desktop — Google primarily indexes mobile versions (mobile-first indexing). Your mobile Core Web Vitals are the most important.
- CrUX lag — Field data in Google Search Console has a 28-day rolling window. Fixes you deploy today won't be fully reflected in CrUX data for 4+ weeks.
6. How to Measure Core Web Vitals
Core Web Vitals can be measured with field data (real users) or lab data (simulated). For Google rankings, only field data matters.
Field Data (Real Users)
- ✓Google Search Console — Core Web Vitals report, 28-day field data from CrUX, URL-level breakdown
- ✓PageSpeed Insights — Field data section (top) shows real-user CrUX data for your URL
- ✓PageGuard — Continuous monitoring, real-time alerts when scores degrade
- ✓Chrome UX Report API — Programmatic access to CrUX data via BigQuery or REST API
Lab Data (Simulated)
- ⓘPageSpeed Insights — Lab section (bottom) runs Lighthouse in controlled environment
- ⓘChrome DevTools — Performance panel + Lighthouse tab for detailed debugging
- ⓘWebPageTest — Advanced waterfall, filmstrip view, multi-location testing
Lab data is useful for debugging but does not reflect Google's ranking signal.