Core Web Vitals are the three metrics Google uses to measure real user experience: LCP (loading), INP (interactivity) and CLS (visual stability). In this guide, we explain step by step how to measure each metric with field data, how to find the source of a problem and how to fix it at the code level.
Important: for ranking, Google uses field data (CrUX — the Chrome User Experience Report), not the lab score. A score of 100 in PageSpeed Insights is a tool, not the goal; the goal is for 75% of your real users to stay within the “good” threshold.
The metrics and their “good” thresholds
| Metric | What does it measure? | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | How long it takes for the largest content element to appear on screen | ≤ 2.5 s | > 4 s |
| INP — Interaction to Next Paint | The delay before the page visually responds to a user interaction | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | The sum of unexpected layout shifts | ≤ 0.1 | > 0.25 |
1. Measure correctly: start with field data
The data sources that matter for ranking, in order:
- Search Console → Core Web Vitals report: real-user status by URL group. After a fix, track the process with “Start validation”.
- PageSpeed Insights (top section): CrUX data at the URL and origin level.
- Lighthouse / lab tests: a diagnostic tool — it shows where the problem is, but doesn't affect rankings.
The most common mistake we see in audits is teams chasing the lab score while overlooking the mobile segment in field data. Mobile is the majority of traffic on most sites (in Türkiye, often more than 80%), so look at mobile CrUX data first. You can see your page's field and lab data side by side with our Core Web Vitals Test.
2. LCP: speed up the largest element
Almost every LCP problem comes from one of four causes: a slow server response (TTFB), render-blocking resources, an LCP image that's discovered late, and client-side rendering.
- Never give the LCP image
loading="lazy". Lazy loading images above the fold delays LCP directly; lazy loading is only for content below the fold. - Help the browser discover the LCP image early:
<link rel="preload" as="image" fetchpriority="high">, orfetchpriority="high"on the img. - Inline critical CSS and minify the rest; remove unused CSS/JS.
- Serve images in modern formats (AVIF/WebP) and at the size they're actually displayed.
- For TTFB: a CDN, caching and server response time optimization (target ≤ 800 ms).
<img src="/images/cover.avif" alt="Cover image"
width="1200" height="675"
fetchpriority="high" decoding="async">3. INP: free up the main thread
INP replaced FID in 2024 and is a much tougher metric: it doesn't measure only the first interaction but the slowest of all interactions over the page's lifetime.
- Break up tasks longer than 50 ms (long tasks); move heavy work to
requestIdleCallbackor a web worker. - Audit third-party scripts: every tag manager add-on, chat bubble and analytics snippet eats into your INP budget.
- Load JS with
defer; for frameworks with expensive hydration, consider an islands architecture. - Give visual feedback immediately after an interaction; leave the heavy processing for later.
4. CLS: reserve space for every element in advance
In our audits, the number one cause of CLS is media without dimensions, and the second is blocks injected late (ads, banners, embeds). The rule is simple: reserve space in advance for everything that arrives later.
- Give every
<img>and<video>element a realwidth/height(or CSSaspect-ratio). - Define a fixed
min-heightfor ad and embed slots; if the content doesn't arrive, the space stays empty and the layout doesn't shift. - For web fonts, use
font-display: swapplus a metric-compatible fallback (size-adjust). - Avoid elements that appear while the page loads and then disappear; this pattern causes CLS and misleads users.
5. Don't restrict the mobile experience
Page experience isn't only about speed. Using maximum-scale or user-scalable=0 in the viewport meta tag takes away the user's ability to zoom and fails accessibility audits:
<!-- Correct -->
<meta name="viewport" content="width=device-width, initial-scale=1">Likewise, intrusive interstitials and a heavy density of banners covering the top of the screen are clearly negative signals in Google's page experience assessment.
Frequently asked questions
Do I need a PageSpeed score of 100?
No. What you need is for all three metrics to be in the “good” range in CrUX field data. A score of 100 is a great engineering indicator, but the difference between 95 and 100 has no measurable effect on rankings; moving from “poor” to “good” in field data does.
Do Core Web Vitals alone determine rankings?
No; content quality always comes first. But between competitors of similar quality, page experience is a differentiator, and poor CWV in particular limits visibility in Discover and Top Stories.
When will I see the effect after a fix?
CrUX uses a 28-day rolling window; it usually takes 4–6 weeks to see a lasting improvement in Search Console.