Core Web Vitals are Google's set of real-user performance metrics that directly influence where your pages rank in search results. Since Google incorporated them into its ranking algorithm in 2021, keeping LCP, CLS, and INP within acceptable thresholds has become a standard part of production web maintenance, not a one-time optimization project.
This guide walks through how to run a proper audit, interpret what you find, and apply targeted fixes on a live site without introducing regressions elsewhere.
Why Core Web Vitals Are Worth Taking Seriously
The three metrics measure things real users actually feel: how fast the main content appears, whether the page shifts around while loading, and how quickly it responds to a tap or click. Poor scores don't just lower rankings. They increase bounce rates and reduce the chance that a visitor stays long enough to convert.
Google updates the thresholds and the metrics themselves over time. The shift from First Input Delay (FID) to Interaction to Next Paint (INP) in March 2024 is a recent example. FID measured only the first interaction's delay. INP measures the worst-case responsiveness across an entire session. Sites that passed on FID often fail on INP, because INP surfaces long event handlers that FID never caught.
Understanding the Three Metrics
Largest Contentful Paint
LCP measures how long it takes for the largest visible element in the viewport to render fully. That element is usually a hero image, a large heading block, or a video thumbnail. Google's threshold is under 2.5 seconds for a "good" rating. Over 4 seconds is considered poor.
LCP failures are usually caused by slow server response times, render-blocking JavaScript or CSS that delays image loading, images that are not preloaded, or large uncompressed image files. Identifying which of these is the bottleneck requires field data, not just a lab score.
Cumulative Layout Shift
CLS measures how much the visible content shifts unexpectedly during page load. A score of 0.1 or below is good; above 0.25 is poor. Common culprits include images or iframes without explicit dimensions, ads or embeds inserted above existing content, and web fonts that cause text to reflow as they load.
The metric is session-windowed, meaning repeated small shifts within a short period accumulate. A page that shifts slightly a dozen times can score worse than one that shifts dramatically once.
Interaction to Next Paint
INP captures the 98th-percentile response latency for all user interactions during a page visit, clicks, taps, and keyboard events included. A good score is under 200ms; over 500ms is poor. INP problems typically trace back to long JavaScript tasks running on the main thread, expensive event handlers, or third-party scripts that block interaction processing.
Running the Audit
Before fixing anything, you need accurate data. There are two kinds: lab data, which is simulated from tools running against your page, and field data, which is collected by Chrome from real visits to your site.
Photo by panumas nikhomkhai on Pexels
Lab data from tools like WebPageTest and GTmetrix gives you a reproducible baseline and highlights specific resources causing delays. But lab data uses simulated network conditions and device hardware, so it doesn't always match what real users experience on a range of devices.
Field data comes from the Chrome User Experience Report and shows the actual 75th-percentile scores for real visitors to your site. Google Search Console's Core Web Vitals report groups your pages into poor, needs improvement, and good buckets based on field data. That's where to start.
Open Search Console's Core Web Vitals report, find the highest-traffic URLs flagged as poor or needs improvement, and then run those specific URLs through a lab tool to diagnose them. Trying to improve every page at once using only lab data is a reliable way to spend time on the wrong problems.
Chrome DevTools (the Performance panel and Web Vitals tab) lets you reproduce issues locally with throttling, see which resources block rendering, and profile long tasks. The MDN Web Docs is useful when you need to understand what the tooling is actually measuring at the spec level.
Fixing LCP Issues
LCP fixes almost always come down to reducing resource fetch time or eliminating render-blocking work that delays the critical path.
Preload the LCP image. If your LCP element is an image, add a <link rel="preload"> tag in the <head> pointing to it. Without preloading, the browser only discovers the image after parsing the HTML and CSS. Preloading moves it to the front of the fetch queue. For responsive images, include the imagesrcset attribute on the preload link to match the srcset on the <img> element.
Do not lazy-load above-the-fold images. The loading="lazy" attribute delays image fetching intentionally. Applied to images in the initial viewport, it delays LCP. Only apply lazy loading to images that are definitively below the fold on typical device sizes.
Fix server response time. A slow Time to First Byte cascades into a slow LCP. If your origin server is consistently slow, a CDN or caching layer typically has more impact than any client-side tweak. web.dev has detailed guidance on TTFB reduction strategies that are worth reading before going straight to frontend optimizations.
Compress and correctly size images. Serving a 3MB JPEG when the displayed size is 600px wide wastes bandwidth on every page load. Use WebP or AVIF where browser support allows, and serve appropriately sized variants using srcset.
Fixing CLS Issues
The fix for most CLS problems is adding explicit dimensions so the browser reserves layout space before resources load.
Set width and height on all images and iframes. When you include dimensions in HTML, the browser holds that space before the resource arrives, eliminating the shift on load. For responsive images styled with CSS, the CSS aspect-ratio property achieves the same result without locking in a fixed pixel size.
Use font-display carefully. font-display: swap prevents invisible text during font loading, which is good. But it causes text to reflow when the web font arrives, which increases CLS. If your web font is metrically close to the fallback, font-display: optional may eliminate the shift entirely by only using the web font if it loads within the first render frame.
Reserve space for ads and injected content. If you inject banners, consent bars, or notifications above the page's main content, wrap them in a container with a minimum height. A dynamic element that pushes content down after the initial render is one of the most common CLS triggers on content-heavy sites.
Photo by ThisIsEngineering on Pexels
Fixing INP Issues
INP is usually the hardest metric to improve because the causes are embedded in JavaScript architecture rather than resource loading.
Break up long tasks. Any JavaScript task over 50ms on the main thread delays the browser's ability to respond to input. Use scheduler.yield() or a setTimeout with a 0ms delay as a fallback to split long synchronous work into smaller chunks, yielding to the event loop between them. Initialization code that runs synchronously on page load is a frequent offender.
Defer non-critical work in event handlers. If a click handler triggers a chain of DOM updates, data fetches, and recalculations, the total time adds up. Identify which work is required before the browser can paint a visible response, and defer the rest to a microtask or the next frame.
Audit third-party scripts. Analytics, tag managers, chat widgets, and ad scripts run on the same main thread as your own code. A third-party script with a long task that coincides with a user interaction registers as a poor INP event. Use the Performance panel in Chrome DevTools with third-party activity visible to find these.
Setting Up Ongoing Monitoring
Fixing Core Web Vitals once is not a maintenance plan. New deployments introduce regressions. Third-party scripts update themselves without notice. Image handling changes in a CMS can silently break LCP overnight.
Set up automated monitoring using a real-user monitoring tool or by running Lighthouse in CI as a quality gate. Search Console sends email alerts when a URL group drops from good to needs improvement, but it takes weeks of field data to confirm changes, so it works better as a trailing indicator than a live warning.
"The sites that struggle with Core Web Vitals over the long run aren't the ones that skipped the initial fixes. They're the ones that made the fixes and then stopped treating performance as a deployment concern. Every content update, image swap, and third-party addition is a chance to introduce a regression." - Dennis Traina, founder of 137Foundry
At 137Foundry, Core Web Vitals data is part of every technical review we do on client sites, whether or not the original engagement was performance-focused. The majority of fixable issues tend to be concentrated on a small number of high-traffic templates, so a focused audit returns more value than a full-site pass.
Where to Start
Open Search Console and find the highest-traffic pages flagged as poor. Run those URLs through a lab tool to get the diagnostic detail. Fix the top two or three issues on those templates before moving to lower-traffic pages.
Our web development services include Core Web Vitals audits as part of site performance engagements. If you're working with a complex architecture or want a second opinion on a persistent problem, our technical SEO and performance practice is a good starting point for a scoped review.
For straightforward sites, most of the tooling is free. Start with what Google gives you and work down the list of flagged issues in priority order. Most sites see measurable improvement from a week of focused effort, and the fixes tend to stay fixed once you build measurement into the release process.
