Core Web Vitals Explained: What They Measure and Why Page Speed Matters

What "Core Web Vitals" Actually Means

If you've spent any time reading about SEO, you've probably run into the phrase "Core Web Vitals" and quietly hoped nobody would ask you to explain it. It sounds technical, but the idea behind it is simple: Google wants to know whether visiting your website is a good experience, not just whether your content is relevant to a search.

Core Web Vitals are a small set of measurements Google uses to judge that experience. They don't look at your writing, your design taste, or your branding. They look at three very specific, very human things: how long someone waits before the page is usable, how quickly the page responds when they click or tap something, and whether things jump around on the screen while they're trying to read or interact. That's it. Three ideas, dressed up in technical names.

Understanding these three measurements matters even if you never touch code yourself, because they give you a plain-English way to ask your developer or agency pointed questions — instead of just saying "the site feels slow" and hoping someone knows what to fix.

The Three Things Core Web Vitals Measure

Loading speed (Largest Contentful Paint, or LCP). This measures how long it takes for the biggest, most visually significant piece of content on a page to actually appear — usually a hero image, a banner, or a large block of text. It's not about when the page technically "starts" loading; it's about when a visitor sees something substantial enough to know the page has arrived. If someone lands on your homepage and stares at a blank screen or a spinning icon for several seconds before anything meaningful shows up, that's a poor LCP score, and it's exactly the kind of thing that makes people click the back button.

Interactivity (Interaction to Next Paint, or INP). This measures how quickly your site responds after someone actually does something — taps a menu, clicks "Add to Cart," fills in a contact form. A site can look fully loaded and still feel broken if buttons take a beat to respond or a menu sticks before it opens. INP is Google's way of measuring that lag between "I clicked" and "something happened." A site that responds instantly to input feels fast and reliable, even if a few images are still loading in the background. A site that hesitates, even briefly, feels janky and unreliable, even if it technically "loaded" fast.

Visual stability (Cumulative Layout Shift, or CLS). This one is about content jumping around while the page is loading. You've almost certainly experienced this: you go to tap a button, and at the exact moment you tap, an ad or image loads in above it and shifts everything down, so you end up clicking the wrong thing entirely. That frustrating, slightly embarrassing moment is a layout shift, and CLS measures how often and how severely it happens on a page. Sites with a lot of unstable ads, embeds, or images without reserved space tend to score poorly here.

Put together, these three measurements are Google's attempt to quantify something that used to be purely a "gut feeling" — does this website feel fast, responsive, and stable, or does it feel sluggish and unpredictable?

Why Google Cares About Page Speed At All

It's fair to ask why a search engine would care about something as seemingly unrelated to content as how fast your page loads. The answer comes down to what Google is actually trying to do: keep people using Google search. If Google keeps sending people to slow, frustrating websites, people start trusting search results less and using search less. So Google has a direct incentive to favor pages that won't frustrate the person clicking on them.

Google has said publicly, through its own developer documentation and Search Central blog, that page experience signals — including Core Web Vitals — are one of many factors used in ranking, particularly when comparing pages that are otherwise similarly relevant to a search query. It is not the single biggest ranking factor, and strong Core Web Vitals scores will not rescue a page with weak or irrelevant content. But when two pages are competing for the same spot and one loads fast and feels stable while the other lags and jumps around, page experience can be the tiebreaker.

There's also a business reason to care that has nothing to do with rankings at all: slow, glitchy websites lose customers regardless of what Google thinks. A visitor who taps a "Book Now" button and waits, and waits, and eventually gives up isn't thinking about your SEO — they're just leaving. Page speed is one of those rare topics where what's good for search rankings and what's good for your actual customers point in exactly the same direction. This overlap is a core part of what technical SEO work is really about — making sure the technical foundation of a site doesn't get in the way of the content and offers sitting on top of it.

Why Small Business Websites Tend to Be Slow

Most small business owners didn't set out to build a slow website — it usually happens gradually, through a series of individually reasonable decisions that add up. A few patterns show up again and again.

Unoptimized images. This is the single most common culprit. A business owner takes a beautiful, high-resolution photo on their phone or gets a professional shoot done, then uploads the original file straight to the website. That file might be several megabytes in size and far larger than it needs to be for a screen. Multiply that across a homepage with ten photos and you've got a page that has to transfer tens of megabytes of image data before a visitor sees anything.

Too many plugins and add-ons. This applies mainly to sites built on platforms like WordPress. Every plugin — a popup builder, a chat widget, a slider, a booking calendar, an SEO tool, a page builder — adds its own code to every page, whether or not that particular page actually needs it. It's easy to end up with a dozen plugins layered on top of each other, each one loading its own scripts and stylesheets, competing for the browser's attention before the page can even render.

Poor or mismatched hosting. Some small business sites are hosted on very cheap, shared hosting plans where the server itself is simply slow to respond, or is shared with hundreds of other websites competing for the same limited resources. No amount of front-end optimization fully compensates for a server that takes a long time to reply to the very first request.

Render-blocking scripts. Certain JavaScript and CSS files have to be downloaded and processed before the browser is allowed to draw anything on screen at all. If a page loads a long list of tracking scripts, font files, and animation libraries before showing any content, visitors are staring at a blank white screen the entire time those files are being fetched — even if the actual page content is small and simple.

Third-party embeds. Live chat widgets, review widgets, social media feeds, video embeds, and marketing pixels are all convenient, but each one is essentially inviting another website's code to run on yours, with its own loading time and its own risk of slowing things down or shifting layout.

None of these causes are exotic or rare. They're the ordinary result of a website growing over time, with new tools bolted on as the business's needs changed, and nobody stepping back periodically to clean house.

How to Actually See Your Own Scores

You don't need technical training to look at your own Core Web Vitals data. Google provides a free tool called PageSpeed Insights, which you can find by searching for it or going directly to pagespeed.web.dev. Enter your website's URL, and it will run an analysis of both your mobile and desktop experience, giving you scores and specific flagged issues for loading, interactivity, and visual stability, along with a list of suggested fixes.

It's worth knowing that PageSpeed Insights reports two different kinds of data. "Lab data" is generated by Google running a simulated test of your page right at that moment. "Field data" (sometimes shown as being from the Chrome User Experience Report, or CrUX) reflects how real visitors using Chrome have actually experienced your site over the past 28 days, if your site gets enough traffic to be included. Field data is generally more meaningful because it reflects real-world conditions — different devices, different connection speeds, different locations — rather than one simulated test run.

If your business has Google Search Console set up (a free tool every website owner should have connected), it also has a Core Web Vitals report under the "Experience" section, which groups your pages by whether they pass or fail each metric and flags the specific pages that need attention. That's often the fastest way to see whether a speed problem is site-wide or limited to a few pages.

What a Non-Technical Owner Can Ask a Developer to Check

You don't need to become technical to have a productive conversation with whoever manages your website. A few plain-language questions can get you a long way:

• "Are our images compressed and sized correctly before upload, or are we serving the original camera or phone files?" This is often the single highest-impact fix available, and it's usually quick for a developer to address across an entire site at once.
• "Can we audit our plugins and remove anything we're not actually using?" Ask specifically whether any plugins are loading their code on pages where they aren't even needed — that's a common and easily fixed waste.
• "Is our hosting plan appropriate for our traffic, or are we on the cheapest possible shared plan?" This isn't always the answer, but it's worth ruling out, especially if your site was set up years ago and hasn't been revisited since.
• "Are there scripts loading before the page content that don't need to be there right away?" Ask whether things like chat widgets, tracking pixels, or non-essential scripts can be delayed until after the main content has appeared.
• "Do our images and embedded content have their dimensions set, so the page doesn't jump around while it loads?" This is the plain-language version of asking about layout shift, and it's a specific, checkable thing for a developer to confirm.

You'll notice none of these questions require you to understand code. They just require knowing what to ask for. A developer or agency that's paying attention to this should be able to answer each one concretely, not just reassure you that "the site is fine."

This Is an Ongoing Job, Not a One-Time Fix

One thing worth setting expectations on: Core Web Vitals aren't a box you check once and forget. Every time a new image gets uploaded without resizing, a new plugin gets installed, or a new tracking script gets added by a marketing tool, there's a chance it quietly drags your scores back down. A site that scored well six months ago can slip simply from ordinary, well-intentioned additions nobody thought to test afterward.

That's why page speed and technical health work best as a periodic check-in rather than a one-off project — something reviewed alongside the rest of your site's technical foundation. If you're not sure what "technical foundation" even covers, our earlier post on what technical SEO is and why it matters walks through the broader picture that Core Web Vitals sits inside.

If your website was built a while ago, or has had a lot of plugins and tools added over the years, or if you've simply never had someone check these specific numbers, it's worth having a conversation about it. Good website design and development takes performance into account from the start, rather than trying to bolt it on afterward. If you'd like to talk through what your own site's Core Web Vitals actually look like and what a sensible next step would be, feel free to get in touch — it's a straightforward conversation, not a sales pitch.