Core Web Vitals: What They Are and Why They Actually Matter

A Calgary restaurant owner called us last spring because her site traffic had dropped 30% over two months. The design hadn't changed. The content was the same. Google Search Console told the story: every single Core Web Vital was in the red. Her site took 6.2 seconds to show anything useful—her homepage wasn’t doing what a homepage needs to do—the layout jumped around while loading, and clicking the reservation button did nothing for nearly a full second. Google had quietly demoted her in search results, and she had no idea why.

This happens more often than you'd think. And it's almost always fixable.

What Core Web Vitals actually measure

Google tracks three specific things about how real people experience your website. Not server uptime. Not how pretty the design is. Three measurable moments that determine whether someone stays or leaves.

Largest Contentful Paint (LCP) is how long it takes for the biggest visible element on your page to finish loading. That's usually a hero image, a headline block, or a large chunk of text above the fold. Google considers under 2.5 seconds good. Between 2.5 and 4 seconds needs improvement. Over 4 seconds is poor.

Think about what 4 seconds feels like. Open a tab, stare at a blank or half-rendered screen, and count. One. Two. Three. Four. Most people have already hit the back button by three.

Interaction to Next Paint (INP) replaced First Input Delay in March 2024. It measures how quickly your site responds when someone actually does something: taps a button, opens a menu, types in a search box. Under 200 milliseconds is good. Over 500 milliseconds is poor. INP tracks every interaction during the entire visit, not just the first click, and reports the worst one. So if your checkout button locks up for 800ms while a payment script loads, that's your INP score.

Cumulative Layout Shift (CLS) measures visual stability. Ever tried to tap a link on your phone and the page shifted at the last second, so you hit an ad instead? That's layout shift. Google scores this on a scale where under 0.1 is good and over 0.25 is poor. The number itself is abstract, but what matters is whether your content stays put while the page loads, or jumps around like it can't make up its mind.

These three metrics aren't theoretical. Google collects them from real Chrome users visiting your site through the Chrome User Experience Report. Your score comes from the 75th percentile of all visits over 28 days. That means if 25% of your visitors have a bad experience, your score reflects it.

Why your business should care about three numbers

We get asked this a lot: does Google really penalise you for bad Core Web Vitals?

Yes. But not the way most people think.

Core Web Vitals became a ranking signal in 2021. They won't single-handedly tank your search position — content relevance and backlinks still matter more. But when two pages are roughly equal in quality and authority, the one with better vitals wins. And in competitive local markets like Calgary, where dozens of businesses target the same keywords, that tiebreaker comes up constantly.

The bigger impact is indirect. Slow sites lose visitors. A one-second delay in page load time can reduce conversions by 7%, according to data from Akamai and Google. Pages that shift around erode trust — if your site feels broken, people assume your business might be too. And if your site responds sluggishly to clicks, visitors won't bother filling out your contact form or finishing a purchase.

The sites that rank well and convert well aren't doing two separate things. Speed, stability, and responsiveness are where search performance and user experience are the same problem.

We've written about how AI-powered search engines evaluate your site differently than traditional Google. But Core Web Vitals are one area where the old rules and the new rules align: a fast, stable site performs better everywhere.

How to measure yours (in under five minutes)

You don't need to hire anyone to check your scores. Google gives you the tools for free.

PageSpeed Insights (pagespeed.web.dev) is the fastest option. Paste your URL, wait 30 seconds. You'll get two sets of data: lab data from a simulated test run right now, and field data from real users over the past 28 days. The field data is what Google actually uses for rankings. If you don't have enough traffic to generate field data, you'll only see lab results — which are still useful but tend to be harsher than real-world performance.

Google Search Console shows Core Web Vitals across your entire site under the Experience section. It groups your pages into Good, Needs Improvement, and Poor, and tells you which specific metric is failing on which pages. This is the best view if you have more than a handful of pages.

Chrome DevTools is more hands-on. Open your site in Chrome, press F12, go to the Performance tab, click Record, interact with the page, then stop recording. You'll see exactly what loaded when, what blocked rendering, and where the delays are. This is where you go after you know the score, to figure out why.

There's a common trap here. Don't test your site on your office computer with a gigabit fibre connection and assume that's what your customers see. PageSpeed Insights simulates a mid-tier phone on a 4G connection, because that's closer to what most people actually use. Your site might feel fast to you and still score terribly.

What causes bad scores (and the fixes ranked by impact)

We've audited hundreds of sites over the years. The causes are almost always the same handful of issues. Here's what to look for, ordered by how much improvement you'll typically see.

Fixing LCP: Make the big stuff load first

The number one cause of slow LCP is oversized images. We're talking 3MB hero photos uploaded straight from a camera or stock site with no compression. A 2400x1600 JPEG that should be a 200KB WebP file instead weighs 2.8MB. We see this on almost every WordPress site built with a page builder.

Highest impact fixes:

Compress and resize your images. Convert to WebP format. A hero image should be under 200KB in almost every case. If your CMS or site builder doesn't handle image compression automatically, that's a problem worth solving. Tools like Squoosh (squoosh.app) let you do this manually in seconds.

Add width and height attributes to your <img> tags so the browser can reserve space before the image loads. This also helps CLS.

If your hero image is the LCP element, preload it. A single line in your page's <head> section — <link rel="preload" as="image" href="hero.webp"> — tells the browser to fetch it immediately instead of waiting to discover it in the CSS or HTML.

Reduce render-blocking resources. If your site loads eight CSS files and twelve JavaScript files before it shows anything, the browser is queued up reading code when it should be painting pixels. Every external stylesheet and script in your <head> is a potential bottleneck. Combine files where possible. Defer JavaScript that isn't needed for the initial view.

Fonts can silently wreck LCP too. If your custom font file takes two seconds to download and your heading text won't display until it arrives, that's two seconds of invisible text. Adding font-display: swap to your font loading tells the browser to show a fallback font immediately and swap in the custom one when it's ready.

Fixing INP: Stop blocking the main thread

INP problems come from JavaScript. Specifically, from JavaScript that monopolises the browser's main thread so it can't respond to your clicks.

The worst offenders we see in the wild: analytics scripts that fire on every scroll event, cookie consent tools that inject massive overlays, chat widgets that load 400KB of JavaScript on page load, and carousel/slider plugins that recalculate layouts on every frame.

Highest impact fixes:

Audit your third-party scripts. Open Chrome DevTools, go to the Performance tab, record a session where you click around, and look for long yellow blocks (that's JavaScript execution). We regularly find sites where third-party scripts — analytics, tag managers, ad trackers, social widgets — account for over 60% of main thread work. Remove what you aren't actively using.

Break up long tasks. Any JavaScript task that runs longer than 50 milliseconds blocks user interaction. If you have a script that does heavy processing, it needs to be split into smaller chunks using requestAnimationFrame or setTimeout to yield back to the browser between steps.

Lazy-load what you don't need immediately. That live chat widget, the social proof popup, the Instagram feed embed? None of that needs to load before the page is interactive. Defer them until after the main content is ready, or load them only when the user scrolls near them.

Fixing CLS: Stop the layout from jumping

Layout shift is almost always caused by elements that load without the browser knowing how much space to save for them.

Highest impact fixes:

Set dimensions on images and videos. Every <img> and <iframe> tag needs explicit width and height attributes (or CSS aspect-ratio). Without them, the browser renders the page, then shifts everything down when the media finally loads. This single fix eliminates the majority of CLS issues we encounter.

Reserve space for ads and dynamic content. If you have banner ads, email signup forms, or cookie consent bars that inject themselves into the page flow, they push everything else down. Give those elements a fixed-height container so the space is already allocated.

Avoid inserting content above existing content. Notifications, promo banners, and dynamically loaded headers that appear at the top of the page after load are CLS nightmares. If you must show them, use overlays that don't affect page flow, or load them before the rest of the content.

Be careful with web fonts. If a custom font has different dimensions than the fallback system font, the text reflows when the swap happens. This is subtle but measurable. Use font-display: optional if you want zero layout shift from fonts — the custom font will only show if it's already cached.

The one thing that makes the biggest difference

After 25 years of building websites and diagnosing performance problems, we can tell you the single most common pattern: sites don't get slow. They get bloated.

A site launches fast. Then someone adds an analytics script. Then a heat-mapping tool. Then a chat widget. Then a cookie consent manager. Then a social proof notification popup. Then an A/B testing framework. Then a font from one CDN, icons from another, and a carousel plugin that loads jQuery even though nothing else on the site uses it. Each addition feels small. Together they're death by a thousand cuts.

Measuring your Core Web Vitals isn't a one-time project. It's a habit. Check PageSpeed Insights after every significant change to your site. Before you add a new tool or plugin, ask: what does this cost in performance? If you can't answer that question, you're making a blind trade.

The good news is that most of the high-impact fixes are straightforward. You don't need to rebuild your site from scratch. Compress your images, clean up your scripts, set your dimensions, and you'll be ahead of most of your competition. If you want a professional audit to find exactly what's holding your scores back, that's something we do regularly.

Your visitors have already decided whether your site is fast enough. The only question is whether you've checked.

Sources

• Web Vitals — Google's official overview of Core Web Vitals metrics, thresholds, and measurement tools
• Largest Contentful Paint (LCP) — Official LCP metric definition, 2.5s/4s thresholds, and what counts as the LCP element
• Interaction to Next Paint (INP) — Official INP metric definition, 200ms/500ms thresholds, and how it differs from FID
• Cumulative Layout Shift (CLS) — Official CLS metric definition, 0.1/0.25 thresholds, and session window calculation
• Interaction to Next Paint becomes a Core Web Vital on March 12 — Google's announcement that INP replaced FID as a Core Web Vital on March 12, 2024
• Understanding page experience in Google Search results — Google Search Central documentation on page experience as a ranking signal (rolled out mid-2021)
• Akamai Online Retail Performance Report: Milliseconds Are Critical — Source for the 7% conversion reduction per 100ms delay statistic (2017 SOASTA/Akamai study)
• CrUX methodology — Chrome User Experience Report data collection, 75th percentile aggregation, and 28-day rolling window
• About PageSpeed Insights — How PageSpeed Insights combines CrUX field data with Lighthouse lab data
• Core Web Vitals report — Search Console Help — How Google Search Console groups pages by Core Web Vitals status