Here’s a number: 53%.
That’s the percentage of mobile users who abandon a website if it takes longer than three seconds to load. Not ten seconds. Not thirty. Three.
And here’s another number: the average mobile website takes over five seconds to become interactive.
So more than half of your potential visitors are gone before your website has even finished introducing itself. They’ve bounced. They’ve gone to your competitor. They’ve found what they needed somewhere faster. And they have absolutely no idea your website exists.
Meanwhile, your analytics shows a high bounce rate and you’re wondering what’s wrong with your content.
Your content is fine. Your website is slow.
This is what Core Web Vitals were designed to measure — and why they became ranking factors.
Table of Contents
What Are Core Web Vitals?
Core Web Vitals are three specific metrics Google uses to measure the real-world experience of loading and interacting with a page.
Not theoretical performance. Not what your developer sees on a high-speed office connection. Real-world performance, measured from real users loading your pages on real devices across real network conditions. Google collects this data from Chrome users (with permission) and aggregates it into the Chrome User Experience Report (CrUX). When Google says your page is slow, it’s not running a test from an ideal environment. It’s looking at what your actual visitors actually experienced.
The three metrics:
- LCP — how fast does the main content load?
- INP — how quickly does the page respond to interaction?
- CLS — does the page jump around while loading?
Each has a “Good,” “Needs Improvement,” and “Poor” threshold. Google’s Page Experience ranking signal rewards pages consistently scoring “Good” across all three.
LCP: Largest Contentful Paint
What it measures: the time from when a user starts loading the page to when the largest visible element — usually a hero image, a large heading, or a video thumbnail — has fully rendered.
Target: under 2.5 seconds is “Good.” 2.5–4 seconds needs improvement. Over 4 seconds is “Poor.”
Why it matters: LCP is the closest approximation to “when did this page feel loaded?” Your users don’t think in terms of DOM load times or time-to-first-byte. They think “this is taking forever” when the main thing they came to see isn’t there yet. LCP captures exactly that moment.
Common LCP culprits:
- Unoptimised hero images — a 4MB PNG served as your above-the-fold hero image is the single most common LCP killer. Convert to WebP or AVIF. Compress. Resize to actual display dimensions. Add
fetchpriority="high"to tell the browser this is the most important image on the page. - Render-blocking resources — CSS or JavaScript files loaded in the
<head>withoutdeferorasyncthat block the browser from rendering anything until they finish downloading - Slow server response times — if your TTFB (Time to First Byte) is high, every metric that follows is penalised before it even starts. This is a hosting and server configuration issue.
- Client-side rendered content as the LCP element — if your largest element is rendered by JavaScript after page load, the browser has to execute the JS before it can paint the element. Use server-side rendering for above-the-fold content.
INP: Interaction to Next Paint
What it measures: the time from when a user interacts with the page — clicking a button, tapping a link, selecting a dropdown — to when the browser visually responds to that interaction. INP looks at all interactions throughout a user’s session and reports the worst-performing one (with some outlier tolerance applied).
Target: under 200ms is “Good.” 200–500ms needs improvement. Over 500ms is “Poor.”
Why it matters: INP replaced FID (First Input Delay) in March 2024 because FID only measured the delay before the browser began processing the first interaction — not the full response time, and not subsequent interactions. INP is far more representative of how interactive a page genuinely feels throughout a user’s entire visit.
A page with poor INP feels laggy. Unresponsive. Like clicking into a void and waiting. Users absolutely notice this even if they can’t name what’s wrong.
Common INP culprits:
- Heavy JavaScript on the main thread — large JS bundles executing during interactions block the browser from responding quickly. Code splitting and deferred loading help.
- Long Tasks — any main thread task taking over 50ms can delay interaction responses. Use Chrome DevTools’ Performance panel to identify them.
- Third-party scripts — analytics tools, ad networks, chat widgets, marketing tag managers — all running on the main thread, all competing to execute during user interactions. Audit your third-party scripts aggressively.
- Poorly optimised event handlers — complex DOM manipulation triggered by user clicks that hasn’t been optimised for speed
CLS: Cumulative Layout Shift
What it measures: the total amount of unexpected visual movement that happens while a page is loading. Every time an element shifts position without user input — an image that loads and pushes text down, an ad that appears and moves the button you were trying to click, a font that swaps and reflows the entire paragraph — that’s a layout shift.
Target: under 0.1 is “Good.” 0.1–0.25 needs improvement. Over 0.25 is “Poor.”
Why it matters: CLS is the one Core Web Vital that every user understands viscerally without knowing it has a name. You’re reading an article and the page jumps — because an image above loaded late. You’re about to click “Add to Cart” and the page shifts — because an ad appeared above the button. You clicked something you didn’t mean to click. You lost your place in the article.
It’s maddening. Google agrees it’s maddening. It measures it.
Common CLS culprits:
- Images without defined dimensions — if your
<img>tags don’t have explicitwidthandheightattributes, the browser doesn’t know how much space to reserve. When the image loads, it pushes everything below it down. Fix: always setwidthandheighton images. - Ads, embeds, and iframes without reserved space — a dynamically inserted ad that appears in the middle of content causes massive layout shifts. Reserve the space with a fixed-height container before the ad loads.
- Web fonts causing FOUT — if your body text reflows when a web font loads and replaces the system font fallback (because the fonts have different character widths), that’s a CLS event. Fix with
font-display: optionalorsize-adjustto match fallback dimensions. - Dynamically injected content above existing content — banners, notification bars, cookie consent popups that appear above the fold after load push everything down
Why Google Made These Ranking Factors
Google’s business model depends entirely on sending users to pages they have a good experience on. If Google consistently sends people to slow, janky, unresponsive pages — users stop trusting Google.
So Google started measuring page experience directly. If your pages consistently give users a bad experience — and the data shows this is happening at scale — Google has a strong incentive to rank alternatives.
This isn’t punitive. It’s not a manual action or an algorithm penalty in the traditional sense. It’s simply that pages delivering excellent experiences have a competitive advantage over pages delivering poor ones — all else being equal.
The “all else being equal” qualifier matters. Core Web Vitals are one ranking factor among hundreds. A mediocre page with perfect Core Web Vitals doesn’t beat a brilliant page with decent Core Web Vitals. But in competitive SERPs where content quality is similar across the top results, page experience becomes a meaningful tiebreaker.
More importantly: slow pages lose revenue independent of rankings. Every additional second of load time costs conversions. This isn’t a Google problem — it’s a business problem.
How to Check Your Core Web Vitals
Method 1: Subu’s SEO Audit Tool
Built this one specifically because I wanted a single place to check both technical and on-page health without jumping between five different tools.
Run your URL through Subu’s SEO Audit Tool and you’ll get a consolidated report covering Core Web Vitals alongside the other technical signals that affect your rankings — crawlability, indexing issues, on-page factors, and more. It’s where I’d start before going deeper into any individual metric.
Method 2: Google Search Console → Core Web Vitals Report
The most important report for ranking purposes. Shows field data — meaning real user data collected from actual Chrome users visiting your pages — segmented by Mobile and Desktop. Tells you which pages are Poor, Need Improvement, or Good, and groups them by issue type so you know what to fix first.
Field data is what Google uses for ranking decisions. This is the number that matters.
Method 3: PageSpeed Insights
Enter any URL and get both field data (real user, from CrUX) and lab data (simulated test run). Lab data is useful for diagnosing specific issues in isolation. Field data is what counts for Google. Understand the difference — a lot of people optimise their lab score and wonder why their Search Console report hasn’t improved.
Method 4: Chrome DevTools → Lighthouse
Right-click → Inspect → Lighthouse tab → Generate report. Detailed breakdown with specific recommendations. Excellent for developers debugging individual issues. Not representative of real-world performance — treat it as a diagnostic tool, not a scoring tool.
Method 5: CrUX Dashboard (Looker Studio)
For tracking Core Web Vitals trends across your entire site over time. Particularly useful after rolling out performance improvements — you want to see the field data move in the right direction over the following 28-day window.
How to Fix Common Core Web Vitals Issues
Fixing LCP:
- Convert images to WebP or AVIF and compress aggressively (tools: Squoosh, Cloudflare Images, Imgix)
- Add
fetchpriority="high"to your LCP image element - Remove
loading="lazy"from above-the-fold images — lazy loading is for off-screen images only - Use a CDN to reduce server response times
- Enable browser caching for static assets
- Defer non-critical JavaScript and CSS
Fixing INP:
- Audit and remove unnecessary third-party scripts (does your marketing team actually need seven different analytics tools?)
- Break up Long Tasks using
setTimeoutto yield main thread control - Use
requestAnimationFramefor visual updates - Consider moving heavy computations to Web Workers
Fixing CLS:
- Add explicit
widthandheightattributes to all<img>tags - Reserve space for ads and dynamic content with min-height containers
- Use
font-display: optionalor implement font fallback matching - Avoid inserting content above existing on-screen content after load
Page Speed Beyond Core Web Vitals
Core Web Vitals get the headlines but total page performance covers more ground:
- TTFB (Time to First Byte) — how fast your server responds. The foundation everything else builds on. If TTFB is 3 seconds before anything even loads, no amount of image optimisation saves you.
- Total page weight — the combined size of all assets. A 12MB page is a slow page on mobile regardless of how well everything else is optimised.
- Number of HTTP requests — every asset is a request. Combine files where possible. Use sprite sheets for icons. Lazy load anything below the fold.
- Render-blocking resources — scripts and stylesheets in
<head>that halt rendering until they load. Defer scripts. Inline critical CSS.
The TL;DR
- Core Web Vitals are three metrics measuring real user experience: LCP (load speed), INP (interactivity), and CLS (visual stability)
- LCP target: under 2.5s — fix by compressing images, removing render-blocking resources, and improving server response time
- INP target: under 200ms — fix by reducing JavaScript on the main thread, auditing third-party scripts, and optimising event handlers
- CLS target: under 0.1 — fix by setting image dimensions, reserving space for ads, and managing web font loading
- Check your scores in Google Search Console’s Core Web Vitals report — field data is what Google uses for ranking decisions, not lab data
- Speed is an SEO problem and a revenue problem simultaneously — slow pages lose rankings and conversions at the same time
Half your visitors are making a decision about your website before it finishes loading. Make it fast enough that they stick around to read it.
Got a terrible PageSpeed score and no idea where to start? Drop your URL in the comments. Subu will tell you exactly what to look at first.
— Subu, SEO by Subu
