A visitor clicks your link, your page thinks for a second, then another, and they are already back in Google, at the competitor listed just below you. They read nothing about you. They only felt the wait. This is not an abstract technical issue. It is a sale you paid for, through ads, SEO and time, and lost in silence.
Google gave that loss a name: Core Web Vitals. These are three measurements the search engine uses to judge how pleasant your site feels in the hands of a real person. And yes, it uses them as a ranking signal.
The three numbers that tell the truth
Forget the jargon. These three values measure three concrete frustrations your customer feels.
LCP, how fast the main content shows up. In plain terms: how long before someone sees the big image, the headline or the offer instead of a blank screen. Good target: under 2.5 seconds. Past 4 seconds, many leave before it even loads.
INP, how fast the site reacts when someone clicks. They tap "Add to cart" and nothing visible happens for half a second. Good target: under 200 milliseconds. A site that "thinks" on every click feels broken, even when it technically works.
CLS, how much the content jumps under their finger. They aim for a button, but at the last moment an image loads, everything shifts, and they tap the wrong thing. Good target: under 0.1. This is the kind of irritation that makes people close the tab without knowing why.
Google does not look at your lab test. It looks at 75% of your real visitors. If most of them have a bad experience, you lose across the board.
Why speed turns straight into money
The logic is blunt and simple. Every second of waiting is an open door to leaving. On a store, a sluggish product page does not "annoy a little" — it cuts your conversion rate. On a services site, a contact form that loads in fits and starts costs you leads.
Then there is Google. When two sites are nearly tied on relevance, speed becomes the tiebreaker. The faster competitor climbs, you slide. You pay twice: once in lost visitors, again in lost rankings.
And do not forget mobile. In Moldova, as everywhere, most people open you on a phone, often on patchy mobile data. A heavy site tuned only for the developer's laptop is a site that works for nobody.
What actually makes a site slow
In almost every case we see, the culprits are the same three.
Huge, unoptimized images. Someone drops a 6 MB photo straight off their phone as a banner. The visitor's browser has to download the whole thing, on mobile data. That same image, resized and saved in a modern format, can weigh under 200 KB — dozens of times lighter, with no visible difference.
Too much JavaScript. Every plugin, chat widget, cookie banner and tracking script is code the visitor's phone has to process. On a new laptop it feels instant. On a 150-euro phone, every click stalls. That hits INP directly.
A slow server with no delivery network. If your site lives on a single cheap server in one corner of the world, every visitor waits for the page to be built from scratch and shipped halfway across the globe. Without server-side rendering and without a CDN (servers close to the user, in many cities), you start every race with a handicap.
The fixes with the biggest payoff
The good news: you do not have to rebuild everything. A handful of moves cover 80% of the gain.
- Optimize your images. Resize them to the size actually shown, compress them, use modern formats. It is the cheapest win and usually the largest.
- Cut the dead scripts. Every widget you do not truly use is code to delete. Less tracking, fewer plugins, more speed.
- Put a CDN in front. Your content reaches the visitor from a nearby server, not from across the ocean. An instant LCP improvement.
- Use server-side rendering. The page arrives already built instead of being assembled in the visitor's browser. Content shows up fast, and Google reads it better.
- Reserve space for images and ads. Declare up front how much room each element takes, so nothing jumps under the finger anymore. CLS solved.
How we build, so you never end up here
At KERNEX IT we build sites on Next.js on Cloudflare Workers — meaning server-side rendering and a global delivery network are there from day one, not patched on later. Image optimization and JavaScript discipline are part of the process, not an emergency repair six months in. This very site runs on exactly that stack.
If your site feels heavy and you suspect it is eating your sales and rankings, write to us at hello@kernex.md. We will look at your real numbers and tell you where you are losing the most and what to fix first.