Your website might look great, but if it loads slowly, responds sluggishly, or shifts around while people try to use it, Google notices, and so do your visitors. Core Web Vitals are the three specific metrics Google uses to measure real-world user experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Knowing how to improve Core Web Vitals isn’t just a developer concern anymore. It directly affects your search rankings and whether potential customers stick around or bounce.
For small business owners, this can feel overwhelming. You built a website to attract customers, not to dig through performance audits and optimize render paths. But here’s the thing, most Core Web Vitals problems have straightforward fixes that don’t require rebuilding your site from scratch. A few targeted changes can make a measurable difference in both your Google scores and how your site actually feels to use.
At Avatar Website Design, we build and maintain websites for small businesses with performance baked in from the start. This guide breaks down exactly what each Core Web Vital measures, why yours might be failing, and the specific steps you can take to fix each one. Whether you handle your own site or want to understand what your developer should be doing, you’ll walk away with a clear action plan to get your scores into the green.
Step 1. Learn the metrics and the pass thresholds
Before you can fix anything, you need to know exactly what you’re measuring. Core Web Vitals consist of three separate metrics, each targeting a different aspect of how users experience your page. Google evaluates each metric independently, and your page needs a "Good" rating on all three to pass the overall assessment. Getting clear on what each one measures and the exact numbers you need to hit is the real starting point for knowing how to improve Core Web Vitals on your site.
Google sets thresholds for each metric across three performance bands: "Good," "Needs Improvement," and "Poor." Here’s how those break down:
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
Your scores are based on the 75th percentile of real user data collected from Chrome users over a 28-day window. That means 75% of visits to your page need to register "Good" scores, not just the average session.
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element in the viewport to finish rendering. That element is usually a hero image, a large heading, or a video thumbnail above the fold. A passing score is 2.5 seconds or under, and anything above 4 seconds earns a "Poor" rating. Slow LCP tells Google, and your visitors, that your page is not loading fast enough to be useful.
One thing to understand: LCP is not your overall page load time. It specifically targets one dominant element, the one users see first. Your page could be 90% loaded but still fail LCP if that key element takes too long to appear.
Interaction to Next Paint (INP)
INP replaced First Input Delay as an official Core Web Vital in March 2024. FID only measured the delay before the browser started processing your first interaction. INP goes further: it measures the total latency of every interaction a user has during their full session, from click or keypress through to the next visual update. Your passing threshold is 200 milliseconds or under, and scores above 500ms are "Poor."
INP is a stricter signal than FID because it captures every interaction across the full session, not just the first one.
Heavy JavaScript execution and third-party scripts are the most common reasons your INP score runs high. Long tasks blocking the main thread prevent the browser from responding quickly to input, which pushes your score up.
Cumulative Layout Shift (CLS)
CLS tracks visual stability, specifically how much your page content shifts unexpectedly as it loads. A passing score is 0.1 or below, and scores above 0.25 are "Poor." Images without defined dimensions, fonts that load late and push text, and ads or embeds that inject into the layout after the first render are the most common causes.
Unlike LCP and INP, CLS does not measure time. It uses a unitless score calculated by multiplying the fraction of the viewport that shifted by the distance those elements moved. Small, repeated shifts stack up fast, so even minor layout instability can push your score into failing range.
Step 2. Measure the right way and find the bottleneck
You can’t fix what you can’t see, and the biggest mistake people make when figuring out how to improve Core Web Vitals is relying only on lab tools. Lab data shows what your site does in a controlled environment, but Google scores you on field data: real user experience collected from actual Chrome browsers over 28 days. You need both types, but in the right order, starting with field data to understand the real problem, then using lab tools to pinpoint the cause.
Always identify which specific metric is failing and on which URLs before you open a diagnostic tool. Guessing wastes time.
Check field data in Google Search Console
Google Search Console is your first stop. Open the Core Web Vitals report under the "Experience" section in the left sidebar. It groups your pages into "Good," "Needs Improvement," and "Poor" buckets for both mobile and desktop separately. Mobile scores are almost always lower, so prioritize those. Click into any failing group to see exactly which metric is pulling the URL below threshold.
The Chrome User Experience Report gives you the same field data Google’s ranking systems use, queryable at the URL level. This tells you what real visitors experienced, not what a simulated test produced.
Reproduce the problem with PageSpeed Insights
Once you know which metric is failing and on which pages, run those URLs through PageSpeed Insights. The tool combines CrUX field data with a live Lighthouse lab audit in a single report, so you see real scores alongside the specific technical causes.
Scroll to the "Opportunities" and "Diagnostics" sections to find what to fix. Look for these specific entries based on your failing metric:
- LCP: "Largest Contentful Paint element" shows exactly which element Google flagged
- CLS: "Avoid large layout shifts" lists which elements moved and by how much
- INP: "Avoid long main-thread tasks" identifies JavaScript blocking your browser’s response time
Each item includes a direct explanation of the issue, so you know what to hand off to a developer or tackle yourself.
Step 3. Improve LCP by speeding up above-the-fold load
LCP fails for one core reason: the browser has to wait too long before it can render the most important element above the fold. That wait time comes from a chain of delays, including slow server response, render-blocking resources, and unoptimized images. Fixing LCP means cutting that chain at every link. This is one of the highest-impact areas when working out how to improve Core Web Vitals, because a faster LCP directly signals to Google that your page delivers usable content quickly.
Preload your LCP image
If your LCP element is an image, the browser often discovers it too late in the loading process. Adding a <link rel="preload"> tag in your <head> tells the browser to fetch that image immediately, before it parses the rest of the page. This single change can shave half a second or more off your LCP score on image-heavy pages.
Add this tag inside your <head> section:
<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">
Also add fetchpriority="high" directly on the <img> tag so the browser treats it as a top-priority resource from the start:
<img src="/images/hero.webp" alt="Hero image" fetchpriority="high" width="1200" height="600">
Compress and convert images to modern formats
Large image files are the most common LCP problem for small business websites. Convert your hero and above-the-fold images to WebP or AVIF format, both of which reduce file size significantly compared to JPEG or PNG without visible quality loss. Always serve images at the actual display size rather than oversize originals the browser shrinks with CSS.
Cutting an unoptimized hero image from 800KB to 120KB will move your LCP score more than almost any other single fix.
Eliminate render-blocking CSS and fonts
Render-blocking resources force the browser to pause HTML parsing before it can paint anything on screen. Inline your critical CSS directly in the <head> so the browser renders above-the-fold content without waiting for an external stylesheet to download. For web fonts, add font-display: swap to your font-face declarations so text appears immediately using a fallback font while the custom font loads in the background.
Step 4. Improve INP by cutting long tasks and JS work
INP fails when your browser’s main thread is too busy to respond to user input quickly. Every time a visitor clicks a button, submits a form, or taps a navigation link, the browser needs a clear path to process that interaction and paint the result. When long JavaScript tasks block that path, the response visibly lags, and your INP score climbs. Understanding how to improve Core Web Vitals for INP means targeting the JavaScript work that holds up your main thread, not just trimming file sizes.
Any JavaScript task that runs longer than 50 milliseconds on the main thread is considered a "long task" and directly threatens your INP score.
Break long tasks into smaller chunks
Your browser processes JavaScript on a single main thread, and it cannot respond to user input while a long task is running. The fix is to break large tasks into smaller pieces and yield control back to the browser between them. The modern way to do this is with scheduler.yield(), which pauses your task and lets the browser handle pending interactions before resuming.
Here is a practical pattern you can apply to any long-running function:
async function processItems(items) {
for (const item of items) {
processItem(item);
// Yield to the browser after each item
await scheduler.yield();
}
}
For broader browser support, use a setTimeout fallback while scheduler.yield() adoption grows. Either approach gives the browser room to respond between chunks of work.
Defer and audit third-party scripts
Third-party scripts, including chat widgets, analytics tags, and social embeds, are one of the most common INP killers on small business websites. They inject JavaScript that runs on your main thread whether you want it to or not. Add defer or async attributes to any non-critical script tags so they load after the page is interactive:
<script src="https://example.com/widget.js" defer></script>
Then audit every third-party script on your page and remove any you are not actively using. One unused chat plugin loading 200KB of JavaScript can push your INP from "Good" into "Poor" on its own.
Step 5. Improve CLS by reserving space and stabilizing UI
CLS fails when the browser does not know how much space an element needs before it loads, so it shifts surrounding content out of the way at the last moment. Knowing how to improve Core Web Vitals for CLS is mostly about telling the browser exactly how large every element will be before it appears, so nothing moves unexpectedly when images, fonts, or ads finish loading.
A CLS score above 0.1 means your users are watching buttons and text jump around while they try to interact with the page, which directly damages both trust and conversions.
Set explicit dimensions on images and media
The most common CLS fix is also the simplest: add width and height attributes to every image, video, and iframe on your page. When these attributes are present, the browser reserves the correct amount of space in the layout before the resource downloads, so nothing shifts when it finally appears. Apply this pattern to all your media elements:
<img src="/images/team-photo.webp" alt="Team photo" width="800" height="500">
<iframe src="https://www.youtube.com/embed/abc123" width="560" height="315" title="Demo video"></iframe>
For responsive images that scale with CSS, pair those attributes with an aspect-ratio rule so the browser maintains the correct proportions at any viewport width without forcing a fixed pixel height:
img {
width: 100%;
height: auto;
aspect-ratio: 16 / 9;
}
Control font loading and late-injected content
Custom web fonts cause CLS when the browser swaps a fallback font for the final font mid-render, pushing text and surrounding elements out of position. Add font-display: swap to your @font-face declarations and use <link rel="preload"> to load your primary font file early, which reduces the visual impact of the swap and keeps the layout stable during load.
Ads, banners, and dynamically injected content are the other major CLS source on small business sites. Reserve fixed-height placeholder containers for any content that loads after the initial render, so the layout does not need to reflow when that content appears:
.ad-container {
min-height: 250px;
width: 100%;
}
Removing any content that injects into the DOM after the page is interactive, unless you have reserved space for it, is the most reliable way to keep your CLS score in the green over time.
Step 6. Re-test, ship safely, and keep CWV passing
Making fixes is only half the work when you are learning how to improve Core Web Vitals. The other half is confirming those fixes actually moved the needle before you assume the job is done, and then building a process so your scores stay in the green after you ship. Skipping re-testing is the most common reason people fix their metrics in a lab environment and still see failing field data in Google Search Console weeks later.
Field data takes up to 28 days to refresh in Google Search Console, so you need a lab-based check right after shipping to confirm your changes are working as expected.
Re-test with field and lab tools
Run your changed URLs through PageSpeed Insights immediately after deploying a fix. This gives you fresh Lighthouse lab data alongside any available CrUX field data. Compare the "Opportunities" and "Diagnostics" sections against your pre-fix baseline to confirm the specific issue you targeted is gone. If you fixed your LCP image preload, verify the LCP element and timing both improved in the lab report before checking field data weeks later.
Use Chrome DevTools Performance panel to run a local trace and confirm long tasks are shorter and layout shifts are no longer firing. Filter the timeline by "Layout" events for CLS and "Tasks" for INP so you can spot any remaining problems at the code level rather than waiting on aggregate field scores.
Deploy changes incrementally and monitor
Ship one fix at a time when possible rather than bundling multiple changes into a single release. Incremental deployments let you tie any score change, positive or negative, to a specific fix. If a change breaks something, rolling back one small update is far easier than untangling a batch release.
Set up a recurring reminder to check your Core Web Vitals report in Google Search Console at least once per month. Track your scores in a simple log using this format:
| Date | URL | LCP | INP | CLS | Status |
|---|---|---|---|---|---|
| 2026-04-10 | /homepage | 2.1s | 180ms | 0.07 | Good |
| 2026-04-10 | /services | 3.8s | 240ms | 0.12 | Needs work |
Catching regressions early, before they accumulate 28 days of bad field data, keeps your rankings protected and reduces the effort needed to get back into the green.
Wrap up and keep it fixed
Core Web Vitals are not a one-time project. You now have a complete process for how to improve Core Web Vitals: learn the thresholds, measure with real field data first, fix LCP by preloading and compressing your largest above-the-fold element, cut INP by breaking up long JavaScript tasks and removing unused third-party scripts, and stabilize CLS by reserving space for every image and dynamic element before it loads.
Every fix you make compounds over time. Faster LCP keeps visitors on the page, lower INP makes your site feel responsive to every tap and click, and a stable CLS builds the trust that turns browsers into buyers. Run your URLs through PageSpeed Insights after each change and check Google Search Console monthly to catch regressions before they chip away at your rankings.
If you want a website built with performance and SEO integrated from day one, Avatar Website Design handles the technical heavy lifting so you can stay focused on running your business.