Knowing your Core Web Vitals scores is the easy part. Once you've run PageSpeed Insights or pulled up your Google Search Console report and you're staring at amber and red metrics, the harder question is: what do you actually do about it?
This guide is the practical follow-up. It covers specific, actionable techniques for improving each of the three Core Web Vitals — LCP, INP, and CLS — along with a framework for deciding which pages to tackle first and how to verify that your changes are working.
Improving LCP (Largest Contentful Paint)
LCP measures when the largest visible element in the viewport loads. For most sites, that's a hero image, a large heading, or a featured video thumbnail. The goal is to get this element in front of users in under 2.5 seconds.
Use a CDN for images and assets. The single highest-leverage change for most sites is serving images and static assets through a content delivery network. A CDN serves files from servers geographically close to each user, dramatically cutting the distance data has to travel. For a site with a global audience, this alone can cut LCP by a second or more for users far from your origin server.
Preload the hero image with <link rel="preload">. By default, the browser doesn't discover your hero image until it parses the CSS or HTML that references it, which can happen late in the load sequence. Adding <link rel="preload" as="image" href="/hero.webp"> to your <head> tells the browser to fetch it immediately, before it would normally find it. This is one of the highest-impact, lowest-risk optimizations available.
Switch to modern image formats. WebP images are typically 25–35% smaller than equivalent JPEGs at the same visual quality. AVIF goes further — often 50% smaller than JPEG — though browser support, while now broad, is worth double-checking for your audience. Smaller image files load faster, directly reducing LCP. Most image optimization tools and CDNs can handle automatic format conversion.
Reduce server response time (TTFB). Time to First Byte measures how long the browser waits before receiving the first byte of the HTML response. A high TTFB — over 600ms — limits how fast any downstream content can load. Fixes include switching to faster hosting, implementing server-side caching (so dynamic pages are served from cache rather than regenerated on each request), using edge functions for server rendering, and optimizing database queries that slow down page generation.
Remove render-blocking CSS and JavaScript. Any CSS or JavaScript in the <head> that the browser must download and process before it can render anything is render-blocking. For CSS: inline the critical styles needed for above-the-fold content and load the rest asynchronously. For JavaScript: add defer or async to script tags, and push non-critical scripts to load after the main content.
Improving INP (Interaction to Next Paint)
INP replaced FID in March 2024 and measures the full responsiveness of your page to clicks, taps, and keyboard inputs throughout the entire session. Poor INP means users feel the page is sluggish or unresponsive — buttons lag, menus are slow to open, form fields feel sticky. Nearly every INP problem traces back to too much JavaScript work on the main thread.
Identify long tasks in Chrome DevTools. Open the Performance panel in Chrome DevTools, record a session where you interact with the page, and look for tasks in the main thread flame chart that run longer than 50ms. These "long tasks" are blocking the browser from responding to user input. The Performance panel will label them clearly, and clicking into them shows which JavaScript is responsible.
Break up long JavaScript tasks. Long synchronous JavaScript blocks the main thread for its entire duration. The fix is to break the work into smaller chunks and yield back to the browser between them. You can do this manually using setTimeout(fn, 0), use requestAnimationFrame for rendering-related work, or use the newer scheduler.postTask() API for more granular control over task priority. Yielding between chunks gives the browser windows to handle user input.
Use scheduler.postTask() for background work. This browser API lets you schedule tasks at different priority levels (user-blocking, user-visible, or background). Tasks that don't need to happen immediately — like analytics processing, prefetching, or lazy data loading — should be scheduled at background priority so they don't compete with user-initiated interactions.
Minimize main thread work overall. Audit your JavaScript bundles. Third-party scripts are a major culprit — tag managers, chat widgets, analytics suites, and ad scripts can add significant main thread pressure. Load them lazily (after the page is interactive), or evaluate whether you need all of them at all.
Defer non-critical JavaScript. Use defer on script tags and dynamic import() for features that aren't needed at page load. A common pattern is loading a heavyweight UI component (a modal, a rich text editor, a date picker) only when the user first interacts with the element that needs it, rather than loading it for every page visit.
Improving CLS (Cumulative Layout Shift)
CLS measures how much the page layout shifts unexpectedly while users are looking at it. A high CLS score means content is jumping around — text moves, buttons reposition, links shift to new locations. Beyond being frustrating, this causes misclicks and erodes user trust.
Always set width and height on images and videos. This is the single most common CLS fix. When images load without explicit dimensions, the browser doesn't know how much space to reserve. It renders the surrounding content at zero image height, then shifts everything down when the image arrives. Adding width and height attributes (or the equivalent CSS) allows the browser to hold the correct space from the start. Modern CSS aspect-ratio properties and the aspect-ratio box in browsers make this straightforward even for responsive images.
Reserve space for ads and embeds. Ad slots are a leading cause of high CLS because their content is loaded asynchronously and can vary in size. The fix is to give ad containers a minimum height that matches the tallest ad you expect to display. For third-party embeds (social media widgets, maps, video players), use a wrapper with explicit dimensions rather than letting the embed dictate its own space after loading.
Avoid inserting content above the fold dynamically. Cookie consent banners, promotional notification bars, and live chat widgets that slide in at the top of the viewport are CLS generators. When content pushes everything below it downward, that's a layout shift. Where possible, overlay these elements (using fixed or absolute positioning) rather than inserting them into the document flow. If they must affect layout, either reserve space for them upfront or trigger them only from user interaction.
Handle web fonts carefully. When a web font loads late, it can cause the fallback font (which renders first) to be replaced by the web font — often at a different size, causing text to reflow and shift surrounding layout elements. font-display: optional prevents the shift entirely by only using the web font if it loads fast enough (and sticking with the fallback otherwise). font-display: swap still allows a swap but should be paired with careful font metrics matching (using size-adjust, ascent-override, etc.) to minimize the visual reflow.
Prioritizing Which Pages to Fix First
Not all pages are equal. Before diving into a site-wide optimization sprint, spend time identifying which pages will deliver the most impact when fixed.
Start with your highest-traffic pages. A 10% improvement in organic traffic from fixing CWV on your homepage or top-five landing pages is worth more than fixing every page on the site. Pull your Google Search Console data to find the pages driving the most impressions and clicks, then check their CWV scores.
Next, look for pages where competitors are outperforming you on specific metrics. If your category page has a CLS of 0.18 and a competitor's equivalent page scores 0.05, that's a specific, measurable gap that Google can see.
AI SEO Scanner's Core Web Vitals monitoring shows per-page scores across your entire site in one view, making it straightforward to identify which pages are passing, which are borderline, and which are failing — so you can prioritize fixes by traffic and severity rather than guessing.
Testing Your Changes
This is where many teams get tripped up. You make a change, run PageSpeed Insights, see a better score, and call it done. But the score you see in PageSpeed Insights is lab data — a simulated result from a controlled environment. What Google actually uses for ranking is field data — real measurements from real users collected over 28 days in the Chrome UX Report.
Lab data is excellent for debugging and verifying that a change has the expected effect in isolation. Field data is what ultimately moves your CrUX scores and influences rankings. This means:
- Use lab tools (PageSpeed Insights, Lighthouse, WebPageTest) to test individual changes quickly.
- Monitor field data via Google Search Console and CrUX to confirm that improvements to real users' experiences follow.
- Allow 4–6 weeks after making improvements before expecting to see changes reflected in CrUX-based scores and rankings.
The gap between lab and field scores is also diagnostically useful. If your lab score is excellent but your field score is poor, that often indicates an issue with third-party scripts (which lab tools may not fully simulate), user device or connection variation, or JavaScript behavior that only manifests in real browsing sessions.
Core Web Vitals improvement is iterative work. Each fix reveals the next bottleneck. The teams that see the biggest gains approach it systematically: measure continuously, prioritize by impact, fix one metric at a time, and track field data to confirm changes are working.
Start with AI SEO Scanner's Core Web Vitals monitoring to get a clear view of where your site stands — and sign up free to begin tracking improvements across every page.