What a fast website actually means — and what a slow one costs you

Of all the promises in website proposals, "fast" is the most common — and the least measured. Everyone promises speed; almost nobody tells you what it means, in numbers, or how to verify it. This article gives you exactly that: what Google actually measures, how to test your own site in two minutes without understanding a line of code, and why a slow website costs you money without anyone telling you.

What "fast" means, in numbers

Google measures a website's speed through three simple questions with public thresholds — they're called Core Web Vitals, and they're the same standard for everyone, from your neighbor's blog to Amazon:

• How quickly does it appear? The main content of the page must be visible within 2.5 seconds. Not the logo, not a loading animation — the content the person came for.
• How quickly does it respond? When a visitor presses a button, the reaction must come within 200 milliseconds, otherwise the tap "doesn't feel real" and they press again, confused.
• How stable is it? The page isn't allowed to jump around while loading — the button you were about to tap must not dart away from under your finger exactly as you touch it.

That's it. It isn't magic and it isn't subjective: three measurements with clear thresholds, and your site either passes them or it doesn't.

Two of the numbers above aren't ours: the lost-visits percentage comes from a Google study that has become a classic, and the link between tenths of a second and conversions was measured by Deloitte, on real retail data. Both reach the same conclusion: visitors don't complain about a slow website. They leave.

Test your site in two minutes

You don't need anyone's help for this check:

1. Open pagespeed.web.dev — Google's free tool.
2. Type in your website's address and press "Analyze".
3. Look at the mobile result, not the desktop one. Mobile is where most of your clients find you, and it's where slow sites fall apart.
4. Find the Core Web Vitals verdict: green means you pass; orange and red mean you're losing visitors right now.

If the site has enough traffic, the report also shows data from real visitors, not just a simulation — those are the numbers that truly matter.

Why a slow website is slow

One clarification that genuinely matters in Romania: it's almost never the internet's fault. We have some of the fastest fixed connections in Europe — if your website crawls, it crawls by construction. The causes repeat with boring regularity:

• Layers upon layers of generic tooling. A page builder on top of a universal theme on top of dozens of plugins — every layer adds code that every visitor downloads, though nobody uses all of it.
• Unprepared images. The 8 MB photo uploaded straight from a phone looks identical to an optimized 80 KB one — it just loads a hundred times slower, on every visit, for every person.
• Scripts accumulated over time. Marketing pixels, chat widgets, banners, "just one more small script" — each innocent alone, all together an anchor.
• Hosting chosen on price alone. The cheapest server shares its resources with hundreds of other sites, and it shows exactly when it shouldn't: when you have traffic.

None of this is visible in the demo someone shows you during the sale. All of it shows up in your pocket, after launch.

What Google does with speed, without the scare tactics

Let's also retire the myth waved around in proposals: Google has confirmed that speed — through Core Web Vitals — is a ranking factor, but one among many. A slow site with excellent content still beats a fast site with nothing to say; nobody gets "erased from Google" over speed.

The real penalty is quieter and more expensive: it comes from people, not from the algorithm. The visitor who waits four seconds goes back to the search results and clicks the competitor below you. You paid — through ads or through the position you earned — for that person to reach you, and the website returned them to sender. That appears in no monthly report, but it happens on every visit.

Speed is a project decision, not an optimization

Here's the part proposals don't say: a website's speed is decided at the foundation, not at the end. How pages are generated, how images are prepared, how much code reaches the visitor — these are architecture decisions, made in the first week of work. A site built slow doesn't get "optimized" later with a plugin: a serious repair usually resembles a rebuild — and it shows in the price why things done right the first time cost what they cost.

The honest conclusion

A fast website isn't a technical indulgence — it's the minimum threshold of seriousness online, like a shop whose door opens when you push it. The good news: you now know exactly how it's measured, and the test is one click away. Take it. If it comes back green, congratulations — you have a partner who did their job. If it comes back red, you have two roads: ask whoever built your site to fix it with the numbers on the table, or — if the answer resembles a shrug — describe your project to us. We'll tell you honestly whether your site can be repaired or the foundation calls for a rebuild, and what each road would mean.