Core Web Vitals explained: how to speed up your website
Core Web Vitals in plain English: what LCP, INP, and CLS measure, how to check your site for free, and what to fix first so it loads fast on mobile.
Your website can look beautiful and still lose customers in the first three seconds. Google measures that experience with three numbers called Core Web Vitals. In this guide you'll learn what each one means, how to check them for free, and what to fix first, no coding required.
You know the scene: someone finds you on Google Maps and taps the link to your site from their phone, with two bars of signal, while waiting at a red light on Avenida Tulum. The screen stays blank, then the menu appears, then the text jumps because a huge photo just arrived, and when they finally try to tap the WhatsApp button, the page takes its time to react. That person is gone. They didn't complain or leave a review. They just went back to the results and tapped the next one.
Core Web Vitals give that moment a name and a number. They translate a very business-minded question into data: does your site treat people well when they arrive in a hurry?
Before you start: what you'll need
- Your site's address and, if you can, the addresses of your three most visited pages (usually the home page, your services or menu page, and your contact page).
- Access to Google Search Console if you already have it set up. If not, no problem; you can start without it.
- A mid-range phone. Checking your site only on the office laptop, plugged into fiber, is the fastest way to fool yourself.
What Core Web Vitals measure
Google groups three metrics, and each one captures a different feeling your visitor has. According to the official Web Vitals guide on web.dev, they're measured at the 75th percentile of real visits, with mobile and desktop scored separately. In other words: your site has to behave well for people with a modest phone and a weak signal, too.
1. LCP: how long the important part takes to appear
LCP stands for Largest Contentful Paint. It measures how long the largest element on the first screen takes to show up: almost always the main photo, a hero video, or a big block of text. It answers the question “Has it loaded yet?”
According to the LCP documentation on web.dev, a good LCP is 2.5 seconds or less; between 2.5 and 4 seconds needs improvement, and anything over 4 seconds is considered poor.
Picture a swimwear boutique in Playa del Carmen whose home page opens with a huge, uncompressed photo straight from a professional camera. The logo, menu, and buttons arrive in an instant, but until that photo appears, the visitor feels like the page hasn't loaded.
The common mistake is blaming everything on the hosting, when the problem is often a single image or a background video.
2. INP: how fast the page responds when you tap it
INP stands for Interaction to Next Paint, and it replaced an earlier metric called FID. It measures the time between someone tapping, clicking, or typing and the moment the page shows a visible reaction. It answers the question “Did it actually listen to me?”
According to the INP documentation on web.dev, an INP of 200 milliseconds or less is good; between 200 and 500 milliseconds needs improvement, and anything above 500 milliseconds is poor.
Think of a restaurant with a digital menu where each category opens with a tap. If the screen freezes when a guest taps “Seafood” before the dishes unfold, they tap again, and the experience feels clumsy even though the page loaded fast. That lag usually comes from too much code running at once, often from third-party tools: pop-up chats, cookie banners, ad pixels, review widgets.
The common mistake here is installing “just one more plugin.” Each one seems harmless; together they take away the browser's ability to respond in time.
3. CLS: how much the page moves while it loads
CLS stands for Cumulative Layout Shift, and it measures unexpected jumps in the content. It answers the question “Why did everything move right when I was about to tap?”
The CLS documentation on web.dev rates a value of 0.1 or less as good and anything above 0.25 as poor; everything in between needs improvement. The same page lists the most frequent causes: images or videos without set dimensions, ads or widgets that resize on their own, content inserted above what was already there, and fonts that, once they finish loading, render larger or smaller than the placeholder text.
For example, imagine a dental clinic whose home page first shows the words “Book your appointment,” and half a second later a promo banner appears on top and pushes everything down. The patient who meant to tap “Book” ends up tapping the phone number of another location.
The common mistake is checking only on a powerful computer, where the jumps go unnoticed. On a phone with a slow signal, the same site dances.
Nobody notices a fast site. Everybody notices a slow one.
How to check your site, step by step
1. Measure with PageSpeed Insights
Go to PageSpeed Insights, paste your home page address, and wait for the analysis. You'll see two sections that are easy to mix up:
- Real user data. At the top, if your site gets enough traffic, you'll see the Core Web Vitals assessment based on people who actually visited your page recently. This is the result that matters.
- Lab diagnostics. Below that is a simulation with a score from 0 to 100 and a list of opportunities. It's useful for finding causes, but it's a snapshot of a single moment and can vary from one run to the next.
If your site is new or gets little traffic, you may not see real user data. In that case, work with the lab diagnostics and run the test several times so you don't react to a one-off result.
Always check the mobile tab first. That's where most people land when they find you on Maps or through an Instagram ad, and it's where problems show the most.
2. Check the Search Console report
If you have Search Console, open the Core Web Vitals report. There, Google groups the pages on your site that share similar issues and labels them good, needs improvement, or poor. It's useful because it tells you whether the problem is a single page or a template that repeats, for example, every product page or every blog post.
3. Write down the culprit behind each metric
Three lines in your notebook: for LCP, which element is the largest (the diagnostics point it out); for INP, which third-party code the page loads; for CLS, which elements move. It feels like paperwork, but it saves you from the most expensive mistake: fixing things that were never the problem.
4. See it with your own eyes on a phone
Open your site on your phone using mobile data, not the office Wi-Fi. Pay attention to three moments: when it feels loaded, whether anything shifted, and whether the buttons respond the instant you tap them. Ask someone who has never seen your site to try to contact you from it, and watch without helping.
What to fix first, in order of impact
Not everything weighs the same. This order usually gets you the biggest change for the least effort.
1. Slim down your images
This is the highest-return fix, and you can do it yourself. Export photos at the size they're actually displayed (a photo shown across a phone screen doesn't need to be billboard-sized) and save them in modern formats like WebP or AVIF. Free tools like Squoosh let you compare quality and file size side by side before you download.
Two more rules your developer should apply: the main image on each page should load with priority, not lazily, and every other image (the ones further down) can wait until the visitor scrolls.
2. Reserve space for every element
To stop the jumps, every image, video, map, or banner needs its space reserved before it loads. In practice, that means setting width and height in the code, or a fixed aspect ratio, so the browser knows how much room to leave. If you use promo or cookie notices, have them appear on a layer over the content, not pushing it down.
3. Clean out third-party tools
List everything that's been installed on your site over the years: chat, Meta pixel, Google tags, heatmaps, review widgets, social buttons, surveys. For each one, ask yourself: does anyone look at the data it collects? Does it bring me customers? Can it load after the page is ready? Whatever nobody uses goes. Whatever earns its place loads when it won't get in the way.
4. Handle your hero video with care
A full-screen video on your home page can be gorgeous and also become the heaviest thing on the page. If you keep it, make it short, muted, and compressed, with a lightweight still image that shows up right away. On mobile, the best call is often to show just that image.
5. Review fonts, server, and platform
This is where help from whoever built your site pays off: limit the font variants that get downloaded, serve fonts from your own domain, use hosting with caching and a content delivery network, and check whether your platform or theme loads code you don't need. If the template drags along features nobody asked for, sometimes it makes more sense to rebuild on a lightweight foundation than to keep patching.
Common mistakes when working on speed
- Obsessing over a 100 lab score. The real goal is green results in the real user data.
- Measuring only the home page. Services, product, and menu pages tend to be the heaviest, and they're the ones that sell the most.
- Checking on desktop and forgetting mobile.
- Installing an “optimization” plugin on top of ten others. Adding code to fix too much code rarely works.
- Changing many things at once and not knowing what worked. Make one change, measure, write it down.
- Forgetting that real user data takes time to update. After an improvement, give it a few weeks before you judge the Search Console report.
A site designed to be light from day one
Speed is much easier to protect when you decide on it during planning, not at the end. If you're about to build or rebuild your site, it's worth reading first how to plan a website with a clear structure and content, because every section you don't need is weight you save. And if your business depends on being found on the map, speed adds to everything we covered in the guide to local SEO and Google Business Profile.
At BDB, our team in Cancún builds custom-coded websites, without templates weighed down by extra features, precisely so they load fast on the phone of whoever is looking for you. If you'd like us to review yours, get in touch.
Frequently asked questions
What are Core Web Vitals, in simple terms?
They're three measurements Google uses to describe what visiting your site actually feels like: how fast the main content shows up (LCP), how fast the page responds to a tap or click (INP), and how still the page stays while it loads (CLS). They're calculated from real visitor data, not from a single test on your computer.
What are good scores for LCP, INP, and CLS?
According to Google's official documentation on web.dev, a good LCP is 2.5 seconds or less, a good INP is 200 milliseconds or less, and a good CLS is 0.1 or less. They're measured at the 75th percentile of visits, with mobile and desktop scored separately.
Do Core Web Vitals affect my Google rankings?
Google recommends achieving good Core Web Vitals and says that, along with other page experience factors, they align with what its ranking systems aim to reward. It also makes clear that it always tries to show the most relevant content, even when the page experience could be better. A fast site won't make up for weak content, but it does keep you from losing visitors and helps you stand out from similar options.
Can I improve Core Web Vitals without being a developer?
Yes, a good part of it. Compressing images, removing plugins you don't use, trimming background videos, and reviewing the third-party chats or ads your site loads are all within reach of any business owner. Code, server, and font adjustments are best left to whoever built your site.
Sources
- Web Vitals, web.dev
- Largest Contentful Paint (LCP), web.dev
- Interaction to Next Paint (INP), web.dev
- Cumulative Layout Shift (CLS), web.dev
- Core Web Vitals and Google Search results, Google Search Central
- Page experience in Google Search results, Google Search Central
- Core Web Vitals report in Search Console, Google Help
- PageSpeed Insights
