Core Web Vitals Explained for Developers 2026
Photo by Christopher Gower on Unsplash
Table of Contents
The Audit That Made Me Take This Seriously
Then I ran PageSpeed Insights on a project I'd shipped and got a 38/100 on mobile performance. Thirty-eight. The kind of score that makes you question your life choices.
What surprised me wasn't the score itself — it was how actionable the breakdown was. The report told me exactly which elements were causing the LCP delay, which layout shifts were hurting the CLS score, and where interaction delays were coming from. It wasn't vague. It was surgical.
I spent a week applying the fixes. The score went from 38 to 79. More importantly, the page started ranking for queries it had been hovering on position 12-15 for months. I don't have a perfect A/B test here, but the timing was tight enough that I started paying attention.
So here's what Core Web Vitals actually are, what they measure, and what I've learned actually moves the numbers.
LCP — Largest Contentful Paint (The Loading Metric)
Good: Under 2.5 seconds. Needs improvement: 2.5–4 seconds. Poor: Over 4 seconds.
The LCP element is whatever is largest at load time — it changes based on the user's viewport. On mobile, your hero image might be a different size than on desktop, which means your LCP element might be different too. PageSpeed Insights reports both.
The most common LCP killers I've run into:
Render-blocking resources — A `<link rel="stylesheet">` or `<script>` in the `<head>` that doesn't have `defer` or `async` delays everything. The browser won't paint anything until it's parsed the blocking resources. Going through a project's `<head>` and adding `defer` to non-critical scripts is often the single biggest LCP win.
Slow server response time — If the HTML itself takes 1.5 seconds to arrive, you're already in the hole. Use CDNs for static assets, consider edge rendering for dynamic pages, and check your Time to First Byte (TTFB) in the performance report.
Unoptimized hero images — A 3MB PNG as a hero image is a common culprit. Convert to WebP, add proper `width` and `height` attributes (so the browser can reserve space), and use `loading="eager"` with `fetchpriority="high"` on the hero image. This tells the browser "prioritize this above everything else."
No preloading of critical resources — Adding `<link rel="preload" href="/hero.webp" as="image">` in the `<head>` tells the browser to start fetching the hero image as soon as the HTML is parsed, before it's discovered in the body.
INP — Interaction to Next Paint (The Responsiveness Metric)
Photo by Fotis Fotopoulos on Unsplash
Good: Under 200ms. Needs improvement: 200–500ms. Poor: Over 500ms.
Where FID only measured the first interaction, INP measures all interactions throughout the page's lifetime and reports the worst one (with some outlier removal). This is a stricter standard. A page that has one slow button click will fail INP even if everything else is fast.
The most common INP problems:
Heavy event handlers — If clicking a button triggers 80ms of JavaScript to run before the browser can paint an update, your INP takes a hit. Break heavy event handlers into smaller chunks. Run non-critical work after the visual update using `setTimeout(fn, 0)` or `requestIdleCallback()`. I covered the mechanics of why this works in the post on JavaScript's event loop — the callback gets pushed to the task queue so it runs after the browser has had a chance to paint.
Main thread contention — If you've got large JavaScript parsing or execution happening when users are trying to interact, interactions queue up behind that work. Use Chrome DevTools' Performance panel to identify long tasks (anything over 50ms is a "long task" by Google's definition). Break them up.
Third-party scripts — Analytics, chat widgets, and ad scripts often run on the main thread and contribute to interaction delays. Audit which third-party scripts you're loading and whether they're `defer`red. Some can be moved to Web Workers.
The web.dev INP optimization guide is genuinely good — one of the cleaner technical write-ups Google's team has produced. Worth bookmarking.
CLS — Cumulative Layout Shift (The Stability Metric)
Good: Under 0.1. Needs improvement: 0.1–0.25. Poor: Over 0.25.
The score is calculated from all unexpected layout shifts — movements that happen outside of 500ms after a user interaction. If you click something and the layout shifts in response, that's expected and doesn't count. If it shifts while you're reading, that counts.
The most common CLS causes:
Images without explicit width/height — If you don't specify `width` and `height` on an `<img>` tag, the browser doesn't know how much space to reserve before the image loads. When the image arrives, the browser inserts it and everything below shifts down. Fix: always include `width` and `height` attributes matching the image's aspect ratio. The browser uses these to reserve space even before the image downloads.
```html <!-- Bad: browser doesn't reserve space --> <img src="hero.webp" alt="Hero image">
<!-- Good: browser reserves the right space from the start --> <img src="hero.webp" alt="Hero image" width="1200" height="630"> ```
Fonts causing FOUT (Flash of Unstyled Text) — When a web font loads, it replaces the fallback font. If the fonts have different metrics, text reflows and content moves. Use `font-display: optional` or `font-display: swap` in your `@font-face` declarations. `optional` avoids layout shift entirely by not swapping if the font hasn't loaded within a timeout. `swap` shows the fallback immediately but swaps it in when the font loads (may cause a brief shift).
Dynamically injected content above existing content — Ads, cookie banners, or notification bars that appear at the top of the page after load push everything else down. If you need these, reserve space for them in the initial layout (a fixed-height container), even if it's temporarily empty.
Measuring and Tracking Your Scores
PageSpeed Insights (pagespeed.web.dev) — The most complete picture. Combines lab data (simulated tests) with real-world CrUX data from Chrome users if your site has enough traffic. The "Opportunities" and "Diagnostics" sections give you specific actionable fixes, not just scores.
Chrome DevTools Lighthouse — Open DevTools (F12), go to the Lighthouse tab, and run an audit. Lab data only, but you get it for any page including localhost — useful for testing changes before deploying.
Chrome DevTools Performance panel — The most detailed. Records a timeline of everything happening during load and interaction. Shows main thread activity, long tasks, paint events, and layout shifts. Steeper learning curve but gives you the exact data you need to find specific bottlenecks.
Google Search Console Core Web Vitals report — Shows field data (real user measurements) for your site's URLs. Slower to update (data is 28-day rolling) but reflects what actual users experience on real devices and connections, not the simulated conditions in lab tests.
One thing I wish someone had told me early: lab scores and field scores can differ significantly. A page might score 92 in PageSpeed Insights lab conditions but have a poor LCP in the field because real users are on slower mobile connections with more browser extensions. Field data wins in the end — it's what Google uses for ranking.
The ToolsFuel developer tools won't directly improve your CWV scores, but when I'm debugging performance issues in API responses (checking payload size, validating JSON structure), having a fast client-side JSON formatter means I'm not adding page weight to my debugging workflow. Small things.
What Actually Moves the Needle (From My Tests)
1. Fix image dimensions first. Adding `width` and `height` to every `<img>` tag is a 30-minute fix on most sites and reliably improves CLS. It's the easiest win on this list.
2. Convert images to WebP and compress them. LCP improvements from this can be dramatic. A 2.1MB hero JPEG at 87/100 quality converted to WebP comes in around 800KB — and you can often go further. Aim for hero images under 200KB.
3. Add `defer` to non-critical scripts. Go through your `<head>` and add `defer` to anything that doesn't need to run before the page paints. This unblocks the main thread for the initial render.
4. Preload the hero image. `<link rel="preload" href="/hero.webp" as="image">` in the `<head>` starts the download earlier in the resource loading waterfall.
5. Audit third-party scripts. Every third-party script is a potential INP liability. Ask whether each one is actually necessary. If it is, check that it's `defer`red.
6. Reserve space for ads and dynamic content. If you're running AdSense or other dynamic content, pre-allocate space in your layout with a minimum height so it doesn't cause layout shifts when it loads.
These six fixes addressed 80% of the CWV issues I've seen across a dozen projects. The remaining 20% tends to be site-specific — server response times, custom JavaScript, font loading strategies — and requires the Performance panel to diagnose properly.
Frequently Asked Questions
Do Core Web Vitals directly affect Google rankings?
Yes, but they're a tiebreaker, not the primary ranking factor. Google has stated that Core Web Vitals are a ranking signal within the Page Experience system. Sites with good content but poor CWV can still rank well, but when content quality is similar between competing pages, CWV scores can tip the balance. Improving CWV is worth doing for user experience regardless of ranking impact.
What happened to FID (First Input Delay)?
FID was officially retired and replaced by INP (Interaction to Next Paint) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was processed. INP is stricter — it tracks all interactions throughout the page session and reports the worst one, giving a more accurate picture of overall page responsiveness. Most INP issues trace back to main-thread work, which is easier to debug once you understand [how the JavaScript event loop schedules tasks](/blog/javascript-event-loop-explained-for-developers).
Why does my PageSpeed score change every time I run it?
PageSpeed Insights lab tests simulate page load under controlled conditions, but network timing, CPU simulation, and third-party resource load times vary between runs. Your score can vary by 5-10 points between tests on the same page. Look at the trend over multiple runs rather than a single measurement, and pay more attention to the field data section (real user metrics) if your site has enough traffic.
How do I check Core Web Vitals for mobile vs desktop?
PageSpeed Insights runs separate audits for mobile and desktop — use the toggle at the top of the results. Scores almost always differ because mobile simulates a slower CPU and network. Google's ranking signals use mobile performance as the primary signal (mobile-first indexing), so prioritize the mobile score even if your traffic is mostly desktop.
What is a good LCP target for e-commerce pages with large product images?
Under 2.5 seconds is the 'good' threshold. For e-commerce pages, focus on the hero/featured product image: convert to WebP, add width and height attributes, use fetchpriority='high' on the main product image, and preload it in the HTML head. Server-side rendering or static generation helps compared to client-rendered pages, since the LCP element needs to be discoverable early in the HTML.
Can I improve Core Web Vitals without a developer?
Some improvements are possible without code changes — compressing images before uploading them to your CMS, removing unnecessary plugins or widgets, and switching to a performance-optimized theme or template. But the biggest gains (render-blocking scripts, preloading, font optimization, INP improvements) typically require code-level changes. PageSpeed Insights' Opportunities section will tell you specifically what's needed.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools