Core Web Vitals are Google's measurements of real-world page experience. Search Console and PageSpeed Insights tell you that a page is failing, but not why. Chrome DevTools answers the why. It lets you record a page load, replay an interaction and see exactly which resource, script or element caused the delay.
This guide shows technical SEOs and developers how to diagnose the three Core Web Vitals directly in the browser. The "good" thresholds are:
Largest Contentful Paint (LCP): 2.5 seconds or less
Interaction to Next Paint (INP): 200 milliseconds or less
Cumulative Layout Shift (CLS): 0.1 or less
Start with field data, then reproduce in the lab
Field data comes from real users, through the Chrome User Experience Report (CrUX). Lab data is what you collect yourself in DevTools. The two will rarely match exactly, so use field data to decide which pages and metrics to fix, and use DevTools to find the cause.
Open a page, press F12 (or Cmd+Option+I on Mac) and go to the Performance panel. The live metrics view shows LCP, CLS and INP for your current session, and can compare them with CrUX field data for the same URL. If the two disagree badly, your test conditions probably don't match your audience. Fix that before you start optimizing.
Set realistic test conditions
Your development machine is fast and your users' phones are not. Before recording, open the Performance panel settings and apply:
CPU throttling: 4x or 6x slowdown to approximate a mid-range mobile device
Network throttling: "Fast 4G" or "Slow 4G"
Disable cache: tick this in the Network panel to simulate a first visit
Record in an Incognito window so extensions don't distort the trace.
Diagnosing LCP
LCP measures when the largest visible element, usually a hero image or headline block, finishes rendering. To investigate:
Click Record and reload in the Performance panel.
Find the LCP marker in the Timings track and click it. DevTools highlights the element.
Review the LCP breakdown: time to first byte, resource load delay, resource load duration and element render delay.
Each phase points to a different fix:
High TTFB: slow server response, no caching, unoptimized database queries or a missing CDN.
Long resource load delay: the browser discovered the image late. This is common when the hero is a CSS background image or injected by JavaScript. Use a normal tag, add fetchpriority="high" and consider a preload hint.
Long load duration: the file is too heavy. Serve modern formats such as WebP or AVIF, and use responsive srcset sizes.
Long render delay: render-blocking CSS or JavaScript is holding the paint. Inline critical CSS and defer non-essential scripts.
A frequent technical SEO mistake is lazy-loading the LCP image. Check the Network panel: if your hero image carries loading="lazy", remove it.
Diagnosing INP
INP replaced First Input Delay as a Core Web Vital in March 2024. It looks at the latency of interactions across the whole visit, not just the first one, so it is harder to pass.
To test it:
Start a recording.
Perform the interaction you suspect: open a menu, click a filter, type in a search box.
Stop recording and look at the Interactions track.
Each interaction splits into three parts: input delay, processing time and presentation delay. Long tasks, marked with a red corner on the Main thread flame chart, are the usual culprits. Click one to see which function ran, and look for:
Heavy event handlers that run synchronously
Third-party tag manager scripts, chat widgets or A/B testing tools
Large DOM trees that make style recalculation slow
Common fixes are breaking long tasks into smaller chunks (setTimeout or scheduler.yield()), debouncing handlers, moving heavy work to a web worker and removing or delaying third-party scripts.
Diagnosing CLS
Layout shifts annoy users and cost you a Core Web Vitals pass. In DevTools:
Open the Rendering tab (Command Menu, then "Show Rendering") and tick Layout Shift Regions. Shifting areas flash blue as you load or scroll.
In the Performance recording, open the Layout Shifts track and click each shift to see which nodes moved and by how much.
The usual causes and fixes:
Images and video without dimensions: add width and height attributes or CSS aspect-ratio.
Late-loading ads or embeds: reserve space with a fixed-height container.
Web fonts causing text reflow: use font-display: swap with a size-matched fallback, or preload critical fonts.
Injected banners (cookie notices, promos): overlay them or reserve their space instead of pushing content down.
Validate and monitor
After fixing, re-record under the same throttling and confirm the metric moved. Then wait. CrUX field data is a rolling 28-day window, so Search Console's Core Web Vitals report will take weeks to reflect your work. Consider adding the web-vitals JavaScript library to collect real-user data from your own site and spot regressions earlier.
Conclusion
Chrome DevTools turns Core Web Vitals from abstract scores into specific, fixable causes. Set realistic throttling, break each metric into its phases and fix the largest phase first. Repeat the process on your highest-traffic templates, since one template fix often improves hundreds of URLs.
FAQ
Do Core Web Vitals directly affect rankings?
They are part of Google's page experience signals. Content relevance still matters most, but when pages are otherwise similar, better experience can be a tiebreaker.
Why do my DevTools scores differ from Search Console?
DevTools is lab data from one device and network. Search Console uses field data from real users across devices over 28 days.
Which metric is hardest to pass?
For many sites it is INP, because it evaluates every interaction and is heavily influenced by JavaScript weight.
Can I test pages behind a login?
Yes. DevTools runs in your authenticated browser session, so it works on logged-in pages that public tools can't reach.
How often should I re-test?
After each significant deployment, and at least monthly for key templates.
Top comments (0)