How to Pass Core Web Vitals: A Step-by-Step Guide to a Faster Website

A slow website costs you visitors before they read a word. It can also hold back your search rankings, and it quietly lowers the audit scores that tools show you. Google measures part of this through three numbers called Core Web Vitals. The names sound technical, but each one maps to something visitors feel: how fast a page appears, how quickly it responds, and whether it jumps around while loading. Here's what each means and exactly how to fix it. Quick Answer To pass Core Web Vitals, aim for these three targets on at least 75 percent of real visits: 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 For most sites, the fastest wins are compressing the biggest image on the page, loading scripts only when needed, and reserving space for images and embeds so nothing shifts. What Core Web Vitals Actually Measure Metric What the visitor feels Good Needs work Poor LCP "When did the main content appear?" up to 2.5s 2.5s to 4s over 4s INP "When I tap or click, how fast does the page respond?" up to 200ms 200ms to 500ms over 500ms CLS "Did things jump around while I was reading?" up to 0.1 0.1 to 0.25 over 0.25 INP replaced an older metric called First Input Delay in 2024, so if you're reading older guides, they may mention the old name. Lab Data vs Field Data: Why Your Scores Disagree This explains the confusing moment when two tools show different results. Field data comes from real visitors using Chrome over the previous 28 days. Google uses this for its page experience signals, and it appears in PageSpeed Insights and Search Console. A new or low-traffic site may not have enough visits to show any. Lab data comes from a simulated test run once, on a standardized device and connection. Lighthouse produces this. It's useful for debugging, but it's one snapshot, and results vary between runs. So a lab score of 55 and a "passed" field result can both be true at once. Use lab tests to find and fix problems, and use field data to confirm real-world improvement. Step 1: Measure Before You Change Anything Open PageSpeed Insights and test your homepage and two key pages on mobile. Mobile is stricter, and it's where most of your visitors are. Save the scores and take screenshots. In Google Search Console, open the Core Web Vitals report to see which groups of pages are poor or need improvement. Run each test three times and use the middle result, since lab scores fluctuate. Write down your starting LCP, INP, and CLS. You'll need them to prove the fixes worked. Speed is one part of a wider health check, so if your overall audit score is also low, our technical SEO audit guide shows how to prioritize everything else. Step 2: Fix Largest Contentful Paint (LCP) LCP is the time until the largest visible element, usually a hero image, a large heading, or a banner, finishes rendering. It's the metric most sites fail first, and images are the most common cause. Identify the LCP Element PageSpeed Insights tells you exactly which element is your LCP. Fix that element first, because optimizing anything else won't move the number. Fix the Image Compress it. A hero image of 2 MB should usually be a few hundred kilobytes or less. Use modern formats like WebP or AVIF. Size it correctly. Don't load a 4000-pixel-wide image into a 800-pixel space. Use responsive images with srcset. Don't lazy-load it. Lazy loading is great for images below the fold, but it delays your main image if applied there. Add fetchpriority="high" to the LCP image instead. Preload it if it's referenced from CSS, so the browser finds it earlier. Speed Up the Server Response Use reliable hosting that can handle your traffic. Turn on caching, so repeat requests don't rebuild the page each time. Put a CDN in front of your site, so files load from a location near each visitor. This matters for audiences spread across countries. Enable Gzip or Brotli compression. Remove Render Blockers Inline the small amount of CSS needed for the top of the page, and load the rest later. Add defer to scripts that aren't needed for the first view. Load fonts efficiently, as covered in the CLS section below. Step 3: Fix Interaction to Next Paint (INP) INP measures how quickly the page reacts when someone taps a button, opens a menu, or types in a field. Poor INP almost always comes from too much JavaScript keeping the browser busy. Remove scripts you don't need. Review every plugin, widget, and tracker. If it doesn't earn its place, delete it. Delay third-party scripts. Chat widgets, social feeds, heatmaps, and ad tags can load after the page is interactive, or after the first user interaction. Break up long tasks. If a script runs for more than 50 milliseconds without pausing, split the work into smaller chunks so the page can respond in between. Keep the page lean. Very large pages with thousands of elements slow every interaction. Avoid heavy work on click. Move complex calculations out of the click handler, or run them in a web worker. Watch animations. Smooth motion is valuable, as we explain in adding life to static websites with Framer Motion, but animate transform and opacity properties rather than layout properties, and use them where they matter most. Test INP on a real mid-range phone if you can. Fast laptops hide problems that most visitors will feel. Step 4: Fix Cumulative Layout Shift (CLS) CLS measures unexpected movement. You start reading, an image loads above the text, and everything jumps. It's frustrating, and it causes misclicks. Always set width and height on images and video, or use the CSS aspect-ratio property, so the browser reserves the right amount of space. Reserve space for embeds, ads, and banners. Give them a fixed container height. Don't insert content above existing content. Cookie banners and notification bars should overlay the page or occupy space that was already reserved, not push everything down after load. Handle fonts carefully. Use font-display: swap or optional, and preload your most important font file. Pick a fallback font with similar proportions. Animate with transforms. Animations that change top, height, or margin trigger shifts. Use transform instead. Step 5: Apply the Quick Wins That Help Everywhere These changes improve all three metrics at once. Optimize every image. Compress, resize, and convert to WebP. Our piece on speed as a design feature explains how to weigh visuals against their load cost. Lazy-load below-the-fold images and videos using the native loading="lazy" attribute. Embed videos lightly. Use a thumbnail that loads the player only when clicked, instead of loading a heavy embed immediately. Minify CSS and JavaScript, and remove unused code. Cache static files for a long period, with versioned file names. Limit the number of fonts and font weights. Two families are plenty. Audit your plugins and widgets. Each one adds weight. Step 6: Adapt the Fixes to Your Platform WordPress Use a lightweight theme and a caching plugin. Add an image optimization plugin to compress and convert uploads automatically. Deactivate and delete plugins you don't use, not just deactivate them. Avoid heavy page builders for simple pages when possible. React and Single-Page Apps Use code splitting, so each page loads only the JavaScript it needs. Consider server-side rendering or static generation for content pages, so visitors and crawlers receive real HTML straight away. Load heavy libraries only on the pages that use them. If you're weighing platforms, WordPress vs React compares the trade-offs. Custom-Built Sites Check your build output for large bundles. Serve compressed assets, and cache them at the CDN. Step 7: Re-Test and Confirm the Results Re-run PageSpeed Insights on the same pages, on mobile. Compare each metric with your starting numbers. Check the Core Web Vitals report in Search Console. Field data updates over about 28 days, so be patient. Repeat for your most important page templates, not only the homepage. If the lab score improves but field data doesn't change yet, that's normal. The field window needs time to reflect your fixes. A One-Week Plan Day 1: Measure and record baseline numbers. Day 2: Fix the LCP image and enable caching and compression. Day 3: Remove or delay unneeded scripts and widgets. Day 4: Add image dimensions, reserve space for embeds, and fix fonts. Day 5: Optimize the remaining images and lazy-load below-the-fold media. Day 6: Re-test and fix anything left in the top three recommendations. Day 7: Check Search Console and set a monthly reminder to re-test. Common Mistakes to Avoid Chasing a perfect 100. Passing the three thresholds matters more than a perfect lab score. Testing only the homepage. Article and product pages often perform differently. Testing only on desktop. Mobile results are the ones that count most. Lazy-loading everything. That delays your most important image. Adding a plugin to fix a plugin problem. Fewer moving parts is usually faster. Expecting instant ranking changes. Speed is one signal among many, and relevant, helpful content still matters most. Frequently Asked Questions What is a good PageSpeed score? Scores of 90 and above are rated good. But pass or fail for Core Web Vitals depends on your three metrics in real-user data, not on the overall score alone. Do Core Web Vitals really affect rankings? They are part of Google's page experience signals, but they're one factor among many. A fast page with weak content won't outrank a strong, relevant page. Speed mainly removes a disadvantage and improves how visitors behave on your site. Why is my mobile score lower than my desktop score? Mobile tests simulate a slower device and network, so they're stricter. Since most visitors use phones, optimize for mobile first. Why do I see "no data" for field metrics? Your site may not have enough Chrome visits yet. Rely on lab data to guide fixes, and check back as traffic grows. How often should I test? Test after every major change, and check Search Console monthly. Where to Go From Here Start with your single biggest image and your heaviest scripts, since those usually deliver most of the improvement. Then work through layout stability and responsiveness. Measure each change, so you know what truly helped.