Core Web Vitals explained: what they are, why they matter, and how to fix yours

By Licheo Research Team | | Technical SEO | 13 min read
Core Web Vitals explained: what they are, why they matter, and how to fix yours

Of all the SEO topics that intimidate small business owners, Core Web Vitals are perhaps the most unfairly intimidating. They sound technical, they are reported as cryptic acronyms, and the fixes — when you read about them online — seem to require a developer fluent in JavaScript and a willingness to rewrite half your website. The truth is rather different.

Core Web Vitals are simply Google's way of measuring whether your website feels fast and pleasant to use. Three measurements, three thresholds, three things to fix. That is all. And while some fixes do require a developer, many do not — they require nothing more than the right plugin, the right setting, or the right image format.

Let us take them one at a time, in plain English.

What Core Web Vitals are, and why Google cares

Google has always wanted to deliver users to websites that feel good to use. For many years, "feel good" was measured loosely — page load time, mobile-friendliness, that sort of thing. In 2020, Google made it precise. They picked three specific measurements, called them Core Web Vitals, and announced that they would become an official ranking factor.

Are they the most important ranking factor? No. Content quality and relevance still matter much more. But they are a tiebreaker — and in competitive niches, tiebreakers decide who appears on page 1 and who languishes on page 3. More importantly, they directly affect conversion rate. A site that takes 5 seconds to load loses roughly 40% of visitors before the page is even visible. So even setting Google aside, Core Web Vitals matter for the simple reason that slow, janky websites lose customers.

The three metrics are:

  • LCP — Largest Contentful Paint
  • INP — Interaction to Next Paint
  • CLS — Cumulative Layout Shift

Let us look at each.

LCP: Largest Contentful Paint (the "is anything on the screen yet?" metric)

LCP measures how long it takes for the largest visible element on your page to actually appear on the screen. Usually this is the hero image, a big headline, or the main banner. If your LCP is 4 seconds, that means your visitor waited 4 seconds staring at a mostly-blank page before the main content showed up. Naturally, by then, half of them have already left.

The thresholds:

  • Good: under 2.5 seconds
  • Needs improvement: 2.5 to 4 seconds
  • Poor: over 4 seconds

The most common causes of bad LCP:

  1. Massive images — particularly hero images uploaded at 4000 pixels wide and 3MB in size when the browser only needs 1200 pixels and 200KB
  2. Slow server response — cheap shared hosting, unoptimized databases
  3. Render-blocking JavaScript and CSS — your browser cannot draw the page until it has downloaded and parsed every script in the head
  4. Web fonts — large font files that block text rendering

How to fix LCP:

The single highest-impact fix is image optimization. If you do nothing else, do this:

  • Convert your hero images to WebP or AVIF format (they are 30-50% smaller than JPEG with the same quality)
  • Resize them to the maximum dimensions actually displayed (do not upload a 4000px image if it shows at 1200px)
  • Add loading="eager" to your hero image and loading="lazy" to images below the fold
  • Use an image CDN — Cloudflare, Imagekit, or your platform's built-in CDN

The second-highest-impact fix is upgrading hosting. If you are on the cheapest tier of a budget host, you may simply be out of compute. Moving to a managed WordPress host like Kinsta, WP Engine, or Cloudways often cuts LCP in half by itself.

INP: Interaction to Next Paint (the "does this thing respond when I tap it?" metric)

INP replaced an older metric called FID in 2024. It measures, across all interactions on your page, how long it takes for the page to visually respond after a user taps, clicks, or types. If you tap a menu button and it takes 800ms before the menu appears, your INP is bad — and the user assumes the site is broken.

The thresholds:

  • Good: under 200 milliseconds
  • Needs improvement: 200 to 500 milliseconds
  • Poor: over 500 milliseconds

The most common causes of bad INP:

  1. Heavy JavaScript — particularly third-party scripts (chat widgets, analytics, ad networks, A/B testing tools)
  2. Long-running tasks — code that blocks the main thread for hundreds of milliseconds at a time
  3. Bloated themes and page builders — Elementor, Divi, and similar tools can ship 3-5MB of JavaScript per page

How to fix INP:

Audit your third-party scripts ruthlessly. Open your homepage in Chrome DevTools (right-click → Inspect → Network tab → reload), and look at every domain that is loaded. Each unfamiliar one is a candidate for removal. Chat widgets you do not use, abandoned analytics tools, A/B testing platforms left over from a past consultant — kill them all.

Then, on WordPress, install a plugin like Perfmatters or WP Rocket and enable "delay JavaScript execution" — this defers non-critical scripts until after user interaction, which dramatically improves INP without breaking functionality.

CLS: Cumulative Layout Shift (the "why did the button move just as I tried to tap it?" metric)

CLS is the most viscerally annoying of the three. It measures how much the layout of your page jumps around as it loads. You know the experience: you are about to tap "Add to cart," and at the last moment an image loads, the page jumps down, and you accidentally tap an ad instead. That is CLS in action.

The thresholds:

  • Good: under 0.1
  • Needs improvement: 0.1 to 0.25
  • Poor: over 0.25

The most common causes of bad CLS:

  1. Images without dimensions — when an image has no width and height attributes, the browser does not know how much space to reserve, so when it loads it pushes everything else down
  2. Web fonts that swap — text appears in a fallback font, then "snaps" to the web font when it loads, causing layout shifts
  3. Dynamically injected content — banners, cookie notices, or ads that appear after the page renders
  4. Embedded iframes without fixed dimensions

How to fix CLS:

Start with images. Every <img> tag on your site should have explicit width and height attributes. Modern browsers use these to reserve space before the image loads. Most CMS platforms add these automatically — but if you have ever inserted an image via raw HTML or copy-paste, check it.

For fonts, use font-display: optional or preload your web fonts with <link rel="preload">. For cookie banners, make sure they appear in a fixed position (overlay) rather than pushing the page content down.

How to check your Core Web Vitals

Three free tools, in order of usefulness:

  1. PageSpeed Insights (pagespeed.web.dev) — paste your URL, get instant scores for both mobile and desktop, plus specific suggestions
  2. Google Search Console → Core Web Vitals report — shows real-world data from actual users visiting your site, broken down into "Good," "Needs improvement," and "Poor" buckets
  3. Chrome DevTools → Lighthouse tab — runs a full audit locally with detailed diagnostic information

Use PageSpeed Insights for spot checks. Use Search Console for the truth, because it reflects what real users experience, not laboratory simulations.

Platform-by-platform fixes

WordPress

The luckiest platform — there are excellent tools available:

  • WP Rocket ($59/year) — handles caching, lazy loading, JavaScript deferral, CSS minification, and database optimization in one plugin. The single highest-impact purchase you can make.
  • Perfmatters — companion to WP Rocket, lets you disable scripts on a per-page basis
  • ShortPixel or Imagify — automatic image optimization and WebP conversion
  • Move to a real host — if you are on Bluehost or HostGator at $4/month, no plugin will save you. Cloudways, Kinsta, or WP Engine are worth the upgrade.

Shopify

Shopify is fast by default, but themes vary wildly. To improve Core Web Vitals:

  • Choose a lightweight theme — Dawn (free, official) is one of the fastest
  • Limit apps — every Shopify app adds JavaScript. Audit them quarterly and remove anything not actively used
  • Use the built-in image transformation — {{ image | image_url: width: 1200 }} produces correctly sized images automatically
  • Enable lazy loading on all images below the fold

Wix

Wix has historically been slow, but modern Wix Editor X and Wix Studio sites are dramatically better. To improve:

  • Use Wix's built-in image optimization (it is on by default)
  • Avoid heavy third-party widgets
  • Use the SEO Wiz to identify performance issues
  • Limit animations and parallax effects, which hurt INP

Squarespace

Squarespace handles most performance optimization automatically, which is both a blessing and a curse — you have less control. To improve:

  • Compress images before uploading (Squarespace does some optimization but not enough for very large files)
  • Limit custom code injections
  • Avoid excessive font variations (each font weight is a separate file)
  • Use Version 7.1, which is significantly faster than 7.0

A realistic expectation

Fixing Core Web Vitals is rarely a one-day project. Expect to spend a weekend implementing the most impactful changes, then another weekend a month later cleaning up the rest. The improvements show up in Search Console roughly 28 days after you make them, because Google uses a rolling 28-day window of real-user data.

But the result, when it lands, is worth it: faster perceived performance, better conversion rates, fewer abandoned visits, and yes — a small but meaningful boost in rankings.

Want to know your Core Web Vitals scores in 60 seconds?

Run a free SEO check at licheo.com/seo-standings and we will analyze your Core Web Vitals along with everything else — content quality, technical SEO, mobile usability, and AI search readiness. You will know exactly which metrics are failing and which fixes will have the biggest impact.