What Makes a Website Actually Fast? Core Web Vitals Explained Simply

"Make my website faster" is one of the most common requests we get. Most business owners who ask have never heard of the three numbers Google actually uses to measure speed. That is fine.

You do not need to become technical to understand them, and you do not need to write code to check them.

This is Core Web Vitals explained in plain language: what each number means, what usually drags it down, how to check your own site for free, and why it matters to your bottom line as much as to your Google ranking.

I have been building websites since the 1990s, long before BuzFind opened in 2004. Back then, "fast" meant a page that did not take a full minute over a dial-up modem.

Today your visitors are on phones, often on a weak signal, and they expect a page to show up almost at once. Website speed is now something you can measure, so nobody has to guess.

The three things Google actually measures

Google calls these three measurements Core Web Vitals. They are published, public standards, and you can check your own site's real score for free in Google Search Console.

Each one covers a different part of how a page feels to a real person: how quickly it shows up, how quickly it reacts, and whether it holds still. Here are the Core Web Vitals explained one at a time.

Largest Contentful Paint (LCP): how fast the page appears

This measures how long it takes for the biggest visible thing on your page, usually a hero image or headline, to actually show up on screen. Google's own guidance says a good score is under 2.5 seconds.

If your homepage's main photo takes 5 or 6 seconds to appear, visitors are staring at a blank or half-loaded page that whole time.

Google sorts LCP into three bands. 2.5 seconds or less is good. Anything over 4 seconds is poor. The space between those two is marked "needs improvement."

Say a florist in Marion, Indiana puts a big photo of a wedding bouquet at the top of the homepage.

That photo is almost always the "largest contentful paint." So the speed of that one image decides most of the LCP score.

If it is a full-size file straight from a camera, the whole page feels slow, even if everything else on it is light.

Interaction to Next Paint (INP): how fast the page responds

This measures what happens after someone taps a button or a menu. A good score is under 200 milliseconds, fast enough that it feels instant.

A slow INP feels like a laggy app: you tap, and nothing happens for a beat. That delay is often caused by too much JavaScript running in the background, doing work the visitor never asked for.

Google calls anything over 500 milliseconds poor. INP is also the newest of the three. It became a Core Web Vital in March 2024, replacing an older measure called First Input Delay (FID).

If you read an older article or report that talks about FID, that part is out of date.

Back to the florist. A customer picks a bouquet, taps "Add to cart," and nothing seems to happen. So they tap again.

Now there are two bouquets in the cart, or the customer gives up and calls another shop. That pause after the tap is what INP measures.

Cumulative Layout Shift (CLS): whether the page jumps around

This measures whether things move on the page while it is loading, like a button shifting down right as you go to tap it because an image above it just finished loading.

A good score is under 0.1, meaning almost no unexpected movement.

This one is a common, avoidable mistake: it happens when images do not have their width and height set ahead of time, so the browser does not know how much space to leave for them.

Google calls a CLS over 0.25 poor. Unlike the other two, CLS is a score with no unit. It is not seconds or milliseconds. It is a measure of how much of the screen moved and how far it moved.

How Google decides if you pass

Many people miss this detail. Google does not judge your site by its best visit or its average visit. It looks at the 75th percentile of real page loads, checked separately for phones and for desktop computers.

In plain words, at least 3 out of 4 visits need to hit the "good" mark. And a page only passes when all three numbers are good at the same time.

This is why a site can feel fast on your office WiFi and still fail. Your own visits are a tiny slice. The 75th percentile includes the customer on an older phone, in a parking lot, with one bar of signal.

Why this is not just a "Google ranking thing"

Core Web Vitals are a real, if modest, Google ranking factor.

Google's own page experience guide says it "always seeks to show the most relevant content, even if the page experience is sub-par." So a fast page with thin content will not beat a slower page that answers the searcher's question better.

But Google also says that when there is lots of helpful content to choose from, a great page experience "can contribute to success in Search." For a small business competing with other local shops that all offer the same service, that is often exactly the situation you are in.

The bigger reason to care is simpler: these three numbers are just a way of measuring what a frustrated visitor already feels. A slow LCP feels like waiting. A slow INP feels like a broken button.

A bad CLS feels like the page is fighting you. Fixing the score and fixing the experience are the same task.

Think about the florist's busiest weeks, like the days before Valentine's Day or Mother's Day. That is when the most people land on the site, often from a phone, often in a hurry.

A page that jumps around or freezes on "Add to cart" costs the most on exactly the days that matter most.

If you want to see how speed fits with the other problems that quietly turn visitors away, read signs your website is costing you customers.

What actually causes bad scores (and how real fixes work)

• Oversized, unoptimized images. A single uncompressed photo can be several megabytes. Properly compressed and correctly sized images, served in modern formats like WebP, are one of the single biggest speed wins available. Our image optimizer, included with paid plans, is built for exactly this.
• Too much JavaScript. Flashy animations and page builders often load a large bundle of code the visitor's browser has to process before the page becomes interactive. A site built with only the code it actually needs loads and responds faster than one built on a heavy, do-everything platform.
• No reserved space for images or ads. This is the direct cause of most layout shift. Setting explicit dimensions on every image fixes it outright.
• Render-blocking resources. Fonts, stylesheets, and scripts that have to fully load before anything appears on screen slow down that first paint. Server-rendered pages, where the HTML is ready before the browser has to do extra work, tend to score far better here than pages that build themselves entirely in JavaScript after the fact.

Each of these is worth a closer look, because the fix is different for each one.

Fixing images the right way

Images are usually the easiest win, so start here. Google's own numbers show why the WebP format matters: WebP images are 26% smaller than PNGs in lossless mode, and 25 to 34% smaller than similar JPEG images in lossy mode.

Google measured the JPEG comparison at equivalent image quality, so you get a lighter file that looks about the same.

A good image fix has four steps:

1. Resize. If the photo shows up 1,200 pixels wide on the page, do not upload a 6,000 pixel wide original. The visitor's phone still has to download the whole thing.
2. Compress and convert. Save it as WebP (or AVIF) at a sensible quality setting. Our image optimizer tool above does this in a few clicks.
3. Set the width and height. This is what stops the layout shift. Google's own advice is to "always include width and height size attributes on your images and video elements."
4. Load the right images first. Photos further down the page can wait until the visitor scrolls near them. This is called lazy loading. The main photo at the top should never be lazy loaded. Google's guidance says not to lazy load images that are likely to be on screen when the page loads, "especially LCP images." Instead, that top image can be marked as high priority (a setting called fetchpriority="high") so the browser grabs it first.

For the florist, that means the big bouquet photo at the top loads first and fast, while the gallery of past weddings further down loads only when someone scrolls to it.

If you would rather have someone handle this across the whole site, that is what our image optimization service covers.

Why JavaScript slows down every tap

A browser does most of its work on one "main thread," and that thread can only do one thing at a time.

Google counts any task that runs longer than 50 milliseconds as a "long task." While a long task is running, the page cannot respond to a tap.

So when a site loads a chat widget, a pop-up tool, three tracking scripts, and a slider, the visitor's tap has to wait in line behind all of that work.

The fix is not always to remove things. Start by asking which scripts earn their place. Is anyone using the chat widget? Is the slider bringing in sales, or just moving? Every add-on you keep should do a real job for your customers.

Slow servers and cheap hosting

Before the browser can show anything, your web server has to answer. Google calls that wait "Time to First Byte" (TTFB), and suggests most sites aim for 0.8 seconds or less.

TTFB is not one of the three Core Web Vitals. Still, a slow server pushes back everything else, especially LCP. You cannot compress your way out of a slow server.

If your TTFB is poor on every page, the hosting or the way the site is built is usually the cause.

How to check your own site right now

Search Console's Core Web Vitals report will show you real data from actual visitors to your site, which is more useful than a single lab test.

If you do not have that set up, our free SEO audit checks it for you and explains, in plain language, what is actually slowing your site down.

You can also read the free tools yourself.

Step by step with PageSpeed Insights

1. Go to Google's free PageSpeed Insights tool and paste in your homepage address.
2. Look at the Mobile tab first. Most local customers find you on a phone.
3. Near the top, look for the real user data section. It shows LCP, INP, and CLS from real Chrome visitors over the previous 28 days, each marked good, needs improvement, or poor.
4. Scroll down to the lab test and its "Diagnostics" list. This is where the tool names the actual problems, like large images or images without a set width and height.
5. Repeat for your main service page and your contact or order page. Those are the pages that bring in money.

Lab data vs. field data: why your two scores disagree

PageSpeed Insights shows two different kinds of results, and people often mix them up. Field data comes from real visitors using Chrome, collected through the Chrome User Experience Report (CrUX).

Lab data comes from Lighthouse, a test that loads your page once in a simulated setting. Google explains that lab data "is useful for debugging issues" but "may not capture real-world bottlenecks," while field data captures the true, real-world experience.

So if the two disagree, trust the field data to tell you where you stand, and use the lab data to find what to fix.

Also note that the big colored performance score (the 0 to 100 number) comes from the lab test. It is a helpful guide, but Search Console's Core Web Vitals report is built on the real visitor numbers.

What if it says "No data available"?

This is very common for small local businesses, so do not panic if you see it. Google only shows field data when a page or site has enough real visitors to give a reliable number.

It does not say what that minimum is. Search Console shows "No data available" when the property is new or when there is not enough data in the CrUX report.

When that happens, use the lab test in PageSpeed Insights instead, and test on your own phone on mobile data. The lab test is still a good guide to what needs fixing, even without real visitor numbers.

Common speed mistakes small business sites make

• Chasing a perfect 100 on the lab score while ignoring the real visitor numbers. The three field numbers are what Search Console reports on.
• Testing only the homepage. Your order page or contact page may be the slow one, and that is the page closest to a sale.
• Adding a plugin to fix speed on a site slowed down by plugins. Sometimes a caching tool helps. Often the real fix is fewer add-ons.
• Lazy loading everything, including the main photo at the top. That makes LCP worse, not better.
• Uploading photos straight from a phone, then letting them show up small on the page. The visitor still downloads the full file.
• Autoplay background videos at the top of the homepage. They look nice on a fast office connection and fall apart on a phone.
• Checking once and never again. A new pop-up, a new tracking script, or one big photo on a new page can undo good scores. Look at the Core Web Vitals report every month or two.

Questions to ask your web designer about speed

If you are hiring someone to build or fix your site, ask these before you pay:

• Will my pages pass all three Core Web Vitals on mobile? How will you show me?
• How do you handle images? Do you resize them, convert them to WebP, and set width and height?
• Is the site server-rendered, or does it build itself in the browser with JavaScript?
• Which plugins or scripts will load on every page, and why is each one needed?
• What happens to speed after launch, when I add new photos and pages?

A good designer will answer these in plain words. If you get vague answers or a sales pitch, that tells you something. Our article on WordPress vs. a custom-coded website explains how the way a site is built changes these answers.

How much speed work is worth doing yourself

Some fixes are easy to do on your own. Compressing and resizing photos, removing a pop-up nobody uses, and turning off an autoplay video can all be done in an afternoon on most website builders.

Start there, run your page speed test again, and see what changed.

Other fixes are harder. If your site is built on a heavy theme with dozens of plugins, or if the server is slow on every page, small tweaks may only get you part of the way.

At that point you are choosing between paying someone to untangle the old site or rebuilding it on a lighter setup. There is no single right answer.

It depends on how much the site brings in, how old it is, and how much it would cost to fix compared to replace.

A Core Web Vitals audit can show you which fixes would make the biggest difference before you spend anything. If speed is only one of several problems, our technical SEO checklist walks through the rest.

A one-hour speed checklist

1. Run PageSpeed Insights on your homepage, main service page, and contact or order page. Write down the mobile LCP, INP, and CLS.
2. Open your homepage on your phone with WiFi off. Watch the top photo. How long until it appears?
3. Tap your main buttons and menu. Does anything freeze or lag?
4. Watch the page as it loads. Does anything jump?
5. Find your three largest photos and check their file size. Anything over a few hundred KB is worth compressing.
6. List every pop-up, chat widget, slider, and video. Cross off any that are not doing a real job.
7. Check Search Console's Core Web Vitals report, if you have it, for pages marked poor.

How BuzFind builds for this

Every site we build is server-rendered with Next.js, with images optimized automatically and no unnecessary JavaScript weighing the page down. Speed is part of the build from the first line of code, instead of an add-on step at the end.

Building a fast website from the start means you are not paying later to fix a slow one.

That means the HTML is ready when it reaches the visitor's phone, every image has its size set so nothing jumps, and the top image loads first.

Our website packages start at $599 for a Web Presence site of 2 pages, one-time, plus $19 a month if we host the site.

If you already have a site and just want to know where it stands, start with the free SEO audit.

And if you are keeping your current site, our website maintenance services can keep an eye on speed as you add new pages and photos over time.