EN
Ihor NikolenkoYou open your website and it flies. A customer opens it on their phone on a crowded bus — and closes it, because the "Order" button showed up on the fourth second, and the page jumped right under their thumb on top of that. You don't see this, because you have fast internet, a powerful computer, and the site has long been cached for you. Google sees it, because it measures real visitors, not you.
Core Web Vitals are three numbers Google uses to describe how a person experiences a page: how fast the main content shows up, how fast the site responds to a tap, and whether the layout jumps around. They affect search rankings, but something else matters more: they directly affect whether a person ever reaches the form. A slow site means part of your ad budget paid for people who never stuck around long enough.
In this article I'll translate the three metrics into plain language, show you where to check your real numbers, and go through what usually slows down a small business site — and what you can fix yourself, without a developer.
Three Metrics, Three Things a Person Feels
Google deliberately didn't choose "page load time," because that number says nothing about experience. Instead, it picked three moments a person notices in their gut.
LCP, Largest Contentful Paint — when the biggest element on screen shows up: a banner, a headline, a product photo. It's the moment a person realizes "the page has opened." Google considers anything up to 2.5 seconds good.
INP, Interaction to Next Paint — how long it takes from a tap to a visible response. You tap the menu — does it open right away, or after a pause? This metric replaced the old FID and is stricter, because it looks at every interaction during the visit, not just the first one. Good means under 200 milliseconds.
CLS, Cumulative Layout Shift — how much the page "jumps" while loading. The classic case: you reach for a button, a banner finishes loading above it, everything shifts, and you tap the wrong thing. Good means under 0.1.
| Metric | What the person feels | "Good" threshold | Most common cause |
|---|---|---|---|
| LCP | "The page stays blank forever" | Under 2.5s | A heavy image above the fold, a slow server, fonts |
| INP | "I tap, and nothing happens" | Under 200ms | Too many scripts: chats, pixels, widgets, animations |
| CLS | "Everything jumps under my thumb" | Under 0.1 | Images and banners with no set dimensions, blocks that load in late |
These thresholds are Google's official benchmarks, and they're calculated from the experience of the majority of visitors, not the best or average result. So "it loads fast for me" isn't an argument.
Where to Check Your Real Numbers
There are two types of measurement, and it's important not to mix them up.
Field data is what real Chrome users have actually experienced over recent weeks. It's collected by the Chrome User Experience Report, and it's what actually affects search rankings. You can see it at the top of PageSpeed Insights, in the "What your real users experience" section, and in the "Core Web Vitals" report in Google Search Console. If you don't get much traffic, field data may not be available — in that case, rely on lab data.
Lab data is the result of a single run under controlled conditions — the bottom half of the PageSpeed Insights report, built on Lighthouse. It's useful for diagnosis: it shows exactly which files and scripts are eating time. But "100 points in the lab" doesn't equal a fast site in the field, and vice versa.
Practical rule: make decisions based on field data, look for causes in lab data. And check the mobile tab — that's what Google bases its judgment on, and that's where problems show up the most.
What Usually Slows Down a Small Business Site
In my experience, the causes repeat from project to project, and "bad code" is rarely among them. Most of the time, it's things that got added with good intentions.
Images. A multi-megabyte phone photo above the fold is the single most common cause of a bad LCP. Right alongside it — sliders with a dozen such photos that all load at once, even though the person only sees one slide.
Third-party scripts. A chat widget, several pixels, a reviews widget, a map, an autoplay video, a calculator — each one drags in its own code, and they all compete for the phone's processor. This is the number-one enemy of INP. Scripts installed "just to try" and then forgotten about do especially serious damage.
Fonts. Several typefaces in several weights, loaded from an external service, and the text either shows up late or jumps around once the font finally arrives.
Hosting and no caching. A server that rebuilds the page from scratch for every visitor, and responds with a delay, pushes back the entire loading chain. In the lab report, this shows up as a long time to first byte.
Layout with no set dimensions. An image or banner with no specified width and height means the browser doesn't know how much space to leave, and shifts the content once the element finally loads. That's basically the whole of CLS.
What You Can Fix Without a Developer
A significant part of this you can handle yourself in the admin panel, or with minimal outside help.
- Compress images and switch to modern formats. WebP or AVIF instead of JPEG and PNG deliver the same quality in a file several times smaller. Many platforms do this automatically on upload — check whether yours can, and whether the feature is turned on.
- Lazy-load everything below the fold. The loading="lazy" attribute on images and videos outside the first screen means the browser doesn't waste resources on things the person can't see yet. The main above-the-fold image, on the other hand, should be the first thing to load.
- Audit your scripts. List everything installed: chats, pixels, widgets. For each one, ask "does this bring in leads." Remove what doesn't. For what stays, move it to the server side where you can — server-side conversion tracking takes some pixels off the browser and gives your ads back their lost data at the same time.
- Limit your fonts. One or two typefaces, two or three weights, with a fallback that shows text in a system font while the main one loads.
- Turn on caching and a CDN. Page caching on your host, plus a content delivery network like Cloudflare for static files, makes the site fast for someone in a different city or country, with no code changes needed.
- Set dimensions for images and blocks. This is often a theme or platform setting; sometimes it's a single template fix worth asking someone to make once.
After every change, check PageSpeed Insights: the lab data right away, and the field data a few weeks later. The indicator should show fact: if the field data hasn't moved, the change hasn't reached real people yet, and you need to keep looking.
Speed as Part of the Funnel, Not a "Technical Issue"
The most common mistake is treating speed as a developer's job that can wait. In reality, it's the first step of the funnel: a person hasn't read a single word yet, and they're already deciding whether to stay. Every fraction of a percent of your budget spent on people who didn't wait around is a lead you'll never get.
That's why I look at speed alongside everything else — how the pages are built, whether leads are being counted, whether they're getting lost in the form. It's one of the sections of a site and funnel audit: showing you exactly which step you're losing people at, including before they've even seen anything. And when a site is built from scratch, it's simpler to build speed into the foundation — modern image formats, caching, minimal browser scripts, server-side conversions — the way it's done in NEO, which is exactly why a site in a week doesn't mean a slow site.
The Short Version
- Core Web Vitals are three things a person feels: when the main content shows up (LCP), whether the site responds to a tap (INP), whether the layout jumps around (CLS).
- Google's official benchmarks: LCP under 2.5s, INP under 200ms, CLS under 0.1, based on the experience of the majority of visitors.
- Make decisions from field data, diagnose from lab data; check the mobile tab.
- Most common causes: heavy images, third-party scripts, fonts, slow hosting with no caching, elements with no set dimensions.
- Without a developer: compress images, lazy-load, remove unnecessary scripts, limit fonts, turn on caching and a CDN.
- Server-side conversion tracking lightens the browser's load and gives your ads back their lost data at the same time.
- Speed is the first step of the funnel, not a separate technical issue.
Frequently Asked Questions
Does speed really affect Google rankings?
Yes, Core Web Vitals is one of the ranking signals, though not the main one. The bigger effect is behavioral: people are more likely to stay on a fast site and more likely to actually submit a lead.
Why do the numbers in PageSpeed Insights change every time?
A lab run depends on server and network load at the moment of the test. Rely on field data instead — it's averaged across weeks.
Can you actually hit "100 points"?
You can, but that's not the goal. The goal is "good" on all three metrics in mobile field data. Beyond that, every extra point costs more than it delivers.
My builder-based site is slow because of the builder itself. What do I do?
First, do what's in your hands: images, scripts, fonts. If the field data is still bad after that, the limitation is in the platform, and that's a reason to consider switching.
