Core Web Vitals sound like something only your developer should worry about. Three acronyms, a Google dashboard nobody asked for, a report card full of red and yellow bars. Easy to ignore. But these three numbers quietly decide whether a stranger who lands on your site sticks around long enough to become a customer, and whether Google shows your business to that stranger in the first place.
Here is the good news. You do not need to understand the engineering. You need to understand what each Core Web Vitals metric measures in plain terms, why it costs you money when it goes wrong, and exactly what to ask the person who builds or maintains your site. That is the whole job.
Think of these vitals as three questions a visitor's body asks before their brain decides to trust you. Did it load fast? Did it respond when I touched it? Did it sit still while I read it? Let us take them one at a time.
LCP: Did the page actually load?
LCP stands for Largest Contentful Paint, which is a technical way of asking a simple question: how long until the main thing on the screen shows up? Not the spinner, not the menu bar. The actual hero image or headline the visitor came to see.
Picture someone in Queretaro searching for a dentist on their phone during a lunch break. They tap your clinic's link. If your big "Schedule a Cleaning" banner takes four seconds to appear, they have already hit back and tapped the next result. Google considers anything under 2.5 seconds good. Past four seconds, you are losing visitors before they read a single word.
What usually causes a slow LCP:
- Huge, uncompressed images. A photo straight off a phone camera can be 6 MB when it only needs to be 200 KB.
- Cheap or overloaded hosting that responds slowly to the very first request.
- Heavy page builders and stacks of plugins that load before the important content does.
What to ask your developer: "What is our LCP on mobile, and what is the single biggest thing slowing it down?" A good answer is specific, like "your homepage hero image is 4 MB and unoptimized, and we can cut that to under a second." A vague "the site is fast enough" is a red flag.
INP: Does the page respond when I touch it?
INP stands for Interaction to Next Paint. It replaced an older metric in 2024, so if your developer still talks about FID, they are a couple of years behind. INP measures responsiveness: when a visitor taps a button, opens a menu, or adds an item to a cart, how long before the page actually reacts?
We have all felt bad INP without knowing its name. You tap "Add to Cart," nothing happens, so you tap again, and now you have two of everything. Or you open a restaurant's menu and it freezes for half a second before expanding. That tiny lag reads as "this thing is broken," even when it is just slow.
For a business, this hits hardest exactly where it hurts: the booking form, the checkout, the contact button. The visitor was ready to act, and the page made them wait. Google wants INP under 200 milliseconds, roughly a fifth of a second, fast enough to feel instant.
What usually causes a poor INP:
- Too much code running at once, often from tracking scripts, chat widgets, and marketing pixels piled on top of each other.
- Bloated themes that do heavy work every time someone clicks.
- Third-party embeds, like a reservation tool or a social feed, that hog the browser.
What to ask your developer: "When someone clicks our main button, the menu, or the booking form, is there any delay, and what is causing it?" Then test it yourself on a mid-range phone, not the newest one in the office. Your customers are not all carrying flagship devices.
CLS: Does the page sit still while I read it?
CLS stands for Cumulative Layout Shift, and it measures the most physically annoying problem on the web: things that jump around while the page loads.
You know the feeling. You are reading a paragraph, an image loads above it, and the text leaps down. Or you go to tap "Confirm," and at the last instant a banner pushes the button down so your thumb lands on "Cancel." That is layout shift, and on a checkout page it is the difference between a sale and a frustrated customer who walks away.
A florist taking online orders for Mother's Day cannot afford a checkout button that hops half a centimeter the moment someone reaches for it. Google wants a CLS score under 0.1, where lower means steadier.
What usually causes layout shift:
- Images and videos without set dimensions, so the browser does not reserve space and content jumps when they arrive.
- Fonts that load late and reflow the text.
- Ads, banners, or cookie notices injected after the page has already drawn itself.
What to ask your developer: "Does anything on our key pages jump or shift while loading, especially on the booking and checkout screens?" This one is easy to spot yourself. Just load your own pages slowly on a phone and watch whether things settle calmly or pop around.
Why Google turned these into a ranking signal
Google's entire business depends on sending people to pages they will be happy with. A page that loads slowly, ignores taps, and shifts under your thumb makes Google look bad by association. So in recent years Google folded Core Web Vitals into how it ranks pages.
It is not the single biggest factor. Genuinely useful content still wins. But when two businesses offer similar services and similar content, the faster, steadier site gets the edge. Think of it as a tiebreaker that runs on every search, every day. For a local business competing with five others for the same searchers, tiebreakers add up.
There is a second, quieter payoff. The same fixes that please Google please humans. Faster loading and steadier pages mean more people finish your booking form, read your menu, and reach your contact button. You are not optimizing for a robot. You are optimizing for the customer, and Google happens to be watching.
How to check your own scores in five minutes
You do not need special software. Open Google's free PageSpeed Insights tool, paste in your homepage and one or two key pages like your booking or contact page, and read the mobile results. It will hand you the three numbers we just covered, color-coded, with a plain list of what to fix.
A word of caution. The score at the top is a lab estimate. The section labeled real-world or field data is what actual visitors experienced, and that is the one that feeds your ranking. If you only get a handful of monthly visitors, that field data may be blank, which is normal.
Run the test, screenshot the results, and bring them to whoever maintains your site. You will have moved from "the site feels slow" to "our mobile LCP is 4.1 seconds and here is why," which is the difference between a vague complaint and a fixable task. If you want a deeper look at where your whole site stands, our services include performance audits that go well past these three numbers. You can also see how steady, fast sites look in practice over on our portfolio.
The Bottom Line
Core Web Vitals are not a technical vanity exercise. They are three honest questions every visitor's instinct asks: Did it load, did it respond, did it stay put? Get them right and you keep more visitors, convert more of them, and earn a small but steady edge in search. Get them wrong and you are paying for traffic that bounces before it ever sees what you offer.
You do not have to fix any of this yourself. You just have to know the three numbers, ask the right questions, and refuse to accept "it is fast enough" as an answer.
Want your site to load fast, respond instantly, and sit perfectly still? Let us take a look.