# Core Web Vitals Core Web Vitals are Google’s three page experience metrics from real users: Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. They affect how users feel speed and stability, and they inform Google’s page experience signals. This entry shows the thresholds, where to read them, how to fix what slows a small site, and the traps. Updated 2026-09-13 · Source: https://porteur.ai/glossary/core-web-vitals ## What Core Web Vitals measure and the thresholds Core Web Vitals are the three field metrics Google reads for page experience: Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. - Largest Contentful Paint, LCP: how long until the main content paints. Good up to 2.5 s. Poor above 4 s. - Cumulative Layout Shift, CLS: how much content jumps while loading. Good up to 0.1. Poor above 0.25. - Interaction to Next Paint, INP: delay from your tap or click to the next paint. Good up to 200 ms. Poor above 500 ms. INP replaced First Input Delay as a Core Web Vital in March 2024. Aim for good on all three for key templates like your homepage, /pricing and /guides/getting-started. ## Field versus lab: how to read your numbers Field data is from the Chrome User Experience Report. It uses the 75th percentile of real Chrome users over 28 days, per URL or per origin. This is the assessment Google cites. PageSpeed Insights shows field data when there is enough traffic, plus a Lighthouse lab run. The lab run is one simulation, by default a mid‑range phone on throttled 4G. Lighthouse scores vary between runs. Its Performance score weights, as of version 10 and later: Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10%, Speed Index 10%. Each category score is 0 to 100. > Use field data to judge if a template passes. Use lab to spot why it is slow, then rerun after each change. ## What to do on a small site 1. **Cut LCP time** Serve a smaller hero image. Set width and height in HTML. Use modern formats like AVIF or WebP. Preload the hero image and the main web font. Host static assets on a CDN. Example: /pricing hero drops from 3.4 s to 1.9 s after compressing a 1.2 MB JPG to a 180 KB AVIF and adding . 2. **Prevent layout shift** Reserve space for images, embeds and ads with fixed dimensions or aspect-ratio. Avoid inserting banners above content after load. Use font-display: swap to avoid FOIT, and match fallback and web font metrics where you can. Example: CLS drops into the good range after adding sizes to three images in the features grid. This is typical, not a measured result. 3. **Reduce main‑thread blocking** Ship less JavaScript. Remove unused libraries. Defer non‑critical scripts with defer or async. Split code and lazy‑init widgets. Keep third‑party embeds off critical paths. Example: INP drops into the good range after removing an unused carousel and deferring analytics. This is typical, not a measured result. 4. **Stabilise third parties** Give iframes fixed containers. Lazy‑load below‑the‑fold embeds. Use a placeholder with dimensions. Replace heavy widgets with server-rendered or static alternatives where possible. 5. **Verify on templates** Test one URL per template in PageSpeed Insights. If field data is missing, test lab now and check Search Console’s Core Web Vitals report later for the template group. A fixed page feels steady, shows the hero fast, and reacts to clicks within 200 ms on a mid‑range phone. ## Common traps and how to avoid them - Chasing a perfect Lighthouse score. Field users decide. Fix what lifts LCP, CLS and INP for real users, not the dial alone. - Testing only on desktop. The default lab run simulates a phone. Most field sessions include mobile, so optimise for mobile first. - Deploying new fonts without metrics. Mismatched metrics cause layout shift. Use font-size-adjust or match ascent/descent if your stack allows it. - Loading above‑the‑fold carousels and videos by default. Replace with a static poster image and a click‑to‑play. - Letting a single slow route skew your origin. One heavy landing page can fail the origin. Fix that first. - Assuming improvements show instantly. Field data uses a 28‑day window. Expect a lag before the assessment updates. ## Questions ### What are the Core Web Vitals? They are Google’s three user‑centred page experience metrics: Largest Contentful Paint for loading, Cumulative Layout Shift for visual stability, and Interaction to Next Paint for responsiveness. As of 2026 the good thresholds are 2.5 s for LCP, 0.1 for CLS, and 200 ms for INP. ### How do I pass the Core Web Vitals assessment? Get the 75th percentile of field data for a URL, or origin, into the good range on all three metrics. Use PageSpeed Insights to see field data if available, and Search Console’s Core Web Vitals report to track template groups. Expect about 28 days for changes to reflect in field data. ### What is CLS and LCP? CLS measures unexpected layout movement while a page loads. Keep it at or below 0.1 by reserving space for images, fonts and embeds. LCP is how long the main content takes to render. Keep it at or below 2.5 seconds by optimising images, fonts and server response. ### What does Google’s Core Web Vitals assessment measure? It uses the Chrome User Experience Report, real Chrome user data. The score is based on the 75th percentile over a rolling 28 days, per URL or per origin. It does not use a single synthetic test. ### Why is my Lighthouse score different from PageSpeed Insights field data? Lighthouse is lab data from one simulated run, so it can vary and may not match your users’ devices or networks. PageSpeed Insights shows both lab and field, and field reflects real users over 28 days. Use lab to diagnose, and field to judge pass or fail. ### Does INP replace FID? Yes. INP replaced First Input Delay as a Core Web Vital in March 2024. INP reflects the full interaction delay to the next paint and is a stronger signal of responsiveness than FID. ## Read next - [Largest Contentful Paint (LCP)](https://porteur.ai/glossary/largest-contentful-paint): Largest Contentful Paint is when the biggest element appears. Aim under 2.5 s. See how to measure it, usual causes on small sites, and quick fixes. - [Cumulative Layout Shift (CLS)](https://porteur.ai/glossary/cumulative-layout-shift): Cumulative Layout Shift is how much a page moves while loading. Keep CLS at or below 0.1. Here is how to measure, find causes, and fix them. - [Interaction to Next Paint (INP)](https://porteur.ai/glossary/interaction-to-next-paint): INP is the delay from tap to next paint, good up to 200 ms; learn how to measure it, read field versus lab data, and fix script delays. - [Reading a Lighthouse score on a phone](https://porteur.ai/guides/lighthouse-score): Use the mobile Lighthouse run to judge speed and UX. See what each score means, how lab and field data differ, and what to fix first. - [Core Web Vitals for a product site: the three numbers](https://porteur.ai/guides/core-web-vitals): The product founder’s guide to LCP, CLS and INP: what Google measures, why phones decide the pass, common causes, and how to test and fix. - [GTmetrix alternatives for page speed](https://porteur.ai/alternatives/gtmetrix-alternatives): Free ways to test your page on a phone with real user data, when to use each tool, and when paying for monitored tests is worth it. Get a free Core Web Vitals read on your templates in about thirty seconds, from a URL, with three findings you can act on next. Free check: https://porteur.ai/