Google has been using Core Web Vitals as a ranking signal since 2021. If your site is slow, jumpy, or unresponsive, it's not just annoying your visitors---it's actively hurting your search rankings. The good news: most of the fixes are straightforward once you know what to look for.
What Are Core Web Vitals?
Core Web Vitals are three specific measurements Google uses to evaluate how real users experience your website. Forget the technical jargon---here's what each one actually means:
Largest Contentful Paint
How long it takes for the biggest visible element on your page (usually a hero image or main heading) to finish loading. Target: under 2.5 seconds.
Interaction to Next Paint
How quickly your page responds when someone clicks a button, taps a link, or types in a form. Target: under 200 milliseconds.
Cumulative Layout Shift
How much the page layout moves around while it's loading. You know when you try to click something and the page jumps? That's layout shift. Target: under 0.1.
Why They Matter for SEO
In June 2021, Google rolled Core Web Vitals into its ranking algorithm as part of the "page experience" update. This means that when two pages have similar content relevance and authority, the one with better vitals wins the higher position.
It's not the most powerful ranking factor---great content still beats fast load times---but it's a tiebreaker that matters more than most people realize. In competitive niches where dozens of pages target the same keywords, Core Web Vitals can be the difference between page one and page two.
Beyond rankings, poor vitals directly hurt your conversion rates. Research consistently shows that every additional second of load time increases bounce rates significantly. Visitors who experience layout shifts or unresponsive buttons are far less likely to complete a purchase, fill out a form, or engage with your content.
How to Check Your Scores
Before you fix anything, you need to know where you stand. Three tools give you the full picture:
PageSpeed Insights
Go to pagespeed.web.dev and enter your URL. You'll get both lab data (simulated tests) and field data (real user measurements). The field data is what Google actually uses for rankings.
Google Search Console
The "Core Web Vitals" report in Search Console shows you which pages pass, need improvement, or fail---across your entire site. This is the best way to identify site-wide patterns.
Chrome UX Report (CrUX)
This is Google's dataset of real user metrics from Chrome browsers. It's what powers the field data in PageSpeed Insights. You can access it directly through BigQuery or the CrUX API for site-wide analysis.
Start with PageSpeed Insights for individual pages, then use Search Console to find patterns across your site.
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible element to render. On most pages, that's a hero image, a heading block, or a large background image. If your LCP is above 2.5 seconds, here's what to check:
Common causes and fixes:
Oversized, unoptimized images
This is the number one LCP killer. Serve images in modern formats (WebP or AVIF), resize them to the actual display dimensions, and compress them. A 4000px-wide JPEG for a hero that displays at 1200px wastes massive bandwidth. Make sure your image alt text is optimized while you're at it.
Slow server response time (TTFB)
If your server takes more than 800ms to respond, everything else is delayed. Consider a CDN, upgrade your hosting, or implement server-side caching. Static site generators or edge hosting can drop this to under 100ms.
Render-blocking CSS and JavaScript
The browser can't paint anything until it finishes downloading and parsing your CSS and synchronous JavaScript. Inline your critical CSS, defer non-essential scripts, and remove unused CSS and JS.
Missing preload hints for the LCP element
If your LCP element is an image, tell the browser to fetch it early with a preload link. Without it, the browser discovers the image only after it parses the CSS or HTML that references it.
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high" />
INP: Interaction to Next Paint
INP replaced First Input Delay (FID) in March 2024 as the responsiveness metric. While FID only measured the first interaction, INP tracks the responsiveness of every interaction throughout the page's entire lifecycle and reports the worst one. If your INP is above 200ms, your page feels sluggish to users.
Common causes and fixes:
Heavy JavaScript execution on the main thread
When JavaScript runs for long stretches, the browser can't respond to clicks or taps. Break up long tasks using requestIdleCallback or setTimeout to yield back to the browser between chunks of work.
Too many third-party scripts
Analytics, chat widgets, ad scripts, social embeds---they all compete for main thread time. Audit your third-party scripts and remove anything you don't actively use. Load the rest with async or defer.
Large DOM size and expensive re-renders
Pages with thousands of DOM nodes take longer to update after interactions. Simplify your HTML structure, virtualize long lists, and avoid forcing layout recalculations on user input. Keep your DOM under 1,500 nodes when possible.
Event handlers doing too much work
If a click handler triggers a complex calculation, an API call, and a large DOM update all at once, the browser freezes until it's done. Move non-visual work to web workers, debounce inputs, and update the UI first before doing background processing.
function yieldToMain() return new Promise(resolve => setTimeout(resolve, 0) );
async function handleClick() // Update the UI immediately updateButton(); await yieldToMain(); // Then do the heavy work processData();
CLS: Cumulative Layout Shift
CLS measures unexpected layout movement. Every time an element on your page moves after it has already been rendered, that counts against your CLS score. A score above 0.1 means your page has a noticeable jumping problem.
Common causes and fixes:
Images and videos without dimensions
When you don't set width and height attributes (or use CSS aspect-ratio), the browser can't reserve space. When the image loads, everything below it jumps down. Always include explicit dimensions on media elements.
Ads, embeds, and iframes without reserved space
Ad slots that inject content after the page loads are one of the worst CLS offenders. Reserve fixed-height containers for ad slots so surrounding content doesn't shift when ads load. Use min-height on containers to prevent collapse.
Late-loading web fonts causing FOUT
When a custom font loads after the page renders, text can reflow as the font swaps in. Use font-display: swap with preloaded font files, or better yet, use font-display: optional to avoid the flash entirely if the font doesn't load in time.
Dynamically injected content above the fold
Banners, cookie notices, or notification bars that get inserted at the top of the page push everything down. If you need to inject content, use overlays (fixed/sticky positioning) instead of inserting into the document flow, or reserve space for it in advance.
<!-- Bad: no dimensions --> <img src="hero.webp" alt="..." />
<!-- Good: explicit width and height --> <img src="hero.webp" alt="..." width="1200" height="630" />
Priority Order: Biggest Impact, Least Effort
Not all fixes are equal. Here's the order we recommend tackling Core Web Vitals issues, ranked by impact relative to effort:
Add dimensions to all images and videos
Five minutes of work. Fixes CLS immediately. Add width and height attributes to every <img> and <video> tag.
Convert images to WebP and compress them
Often cuts image file sizes by 50--80%. Fixes LCP on most sites. Tools like Squoosh, Sharp, or your CMS's built-in optimization handle this automatically.
Preload the LCP image
One line of HTML in your <head>. Tells the browser to fetch your hero image immediately instead of waiting to discover it in the CSS or HTML.
Preload fonts and set font-display
Eliminates the text reflow that hurts CLS. Preload your key font files and add font-display: swap or font-display: optional to your font-face declarations.
Defer non-critical JavaScript
Add defer or async to script tags. Move third-party scripts below the fold. This improves both LCP (by unblocking rendering) and INP (by reducing main thread contention).
Audit and remove unused third-party scripts
Most sites accumulate scripts over time that nobody remembers adding. Review every external script. If you can't explain why it's there, remove it. This is the single biggest INP improvement for most sites.
Upgrade hosting or add a CDN
If your Time to First Byte (TTFB) is above 800ms, no amount of front-end optimization will save your LCP. Consider edge hosting, a CDN like Cloudflare, or static site generation to bring server response times down.
Quick Checklist
Run through this list on your highest-traffic pages first. Every item you check off moves your Core Web Vitals scores in the right direction.
Core Web Vitals Checklist
- ✓Run PageSpeed Insights on your top 5 landing pages and note the field data scores
- ✓All images and videos have explicit
widthandheightattributes - ✓Hero images are served in WebP/AVIF format and sized to display dimensions
- ✓LCP image has a
<link rel="preload">tag in the document head - ✓Web fonts are preloaded with
font-display: swaporfont-display: optional - ✓Non-critical JavaScript uses
deferorasync - ✓Unused third-party scripts have been removed
- ✓Ad slots and embeds have reserved space with
min-height - ✓Server response time (TTFB) is under 800ms
- ✓Dynamic content (banners, notices) uses overlay positioning instead of pushing content down
Core Web Vitals aren't a mystery. They measure three simple things: how fast your page loads, how quickly it responds, and how stable the layout is. Most sites fail because of a handful of known, fixable issues---oversized images, too much JavaScript, and missing dimension attributes. Fix those first, and you'll pass for most pages. Then make sure the rest of your on-page SEO---like internal linking---is working just as hard.