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. Almost nobody tells you what it means, in numbers, or how to check it yourself. This article gives you exactly that: what Google actually measures, how to test your site in two minutes without reading a line of code, and what is worth investigating when a page loads slowly.

What "fast" means, in numbers

Google uses three headline metrics for real loading, responsiveness and visual stability — they're called Core Web Vitals, they have published thresholds, and they're the same for everyone, from your neighbour's blog to Amazon. They don't describe a site's entire performance on their own, but they're the place to start:

• How quickly does it appear? The largest visible element in the initial viewport should be painted within 2.5 seconds (Largest Contentful Paint). Usually that's the big image at the top or the main block of text — not the logo, not a loading animation.
• How quickly does it respond? When a visitor taps a button, the response should arrive within 200 milliseconds (Interaction to Next Paint), otherwise the tap "doesn't register" and they press again, confused.
• How stable is it? Elements shouldn't move around while the page is loading. Zero movement isn't the requirement: the good threshold is a score of 0.1 or less (Cumulative Layout Shift) — enough that the button you were aiming for doesn't dart out from under your finger.

These thresholds aren't judged on your best visit, or on a single simulation. For real-user data, Google looks at the 75th percentile of experiences over the previous 28 days, separately for mobile and desktop. A page passes when every available metric sits in the good range.

Two of the numbers above aren't ours. The lost-visits figure comes from a Google study of global mobile data collected in 2016 (The Need for Mobile Speed), and the link between tenths of a second and conversions was measured by Deloitte in Milliseconds Make Millions, across mobile experiences in retail, travel, luxury and lead generation. They're serious indications, not guarantees: they don't mean every slow site loses exactly that much. What you lose only shows up in your own data — traffic, abandonment, conversions, revenue.

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 the address of the page you want to check and press "Analyze".
3. Look at both results, mobile and desktop. For a site aimed at the general public, start with mobile; for the final call, look at your own traffic data too.
4. Find the Core Web Vitals verdict: green is a good signal, while amber and red mean the experience needs investigating — not that you're losing a specific amount of traffic or revenue.

Bear in mind that PageSpeed Insights assesses the page you give it, not the whole site. Your homepage, a product page and the contact form can score very differently, so it's worth checking several types of page.

If the page or the domain has enough traffic, the report also shows data from real visitors alongside the simulation. The two are read together: field data shows what people are actually experiencing, while the lab test helps you find the cause.

Why a slow website is slow

One clarification that genuinely matters in Romania: the visitor's connection counts, but it rarely explains a heavy page on its own. We have some of the fastest fixed connections in Europe — but people also arrive on mobile, on a weak signal, roaming, or on older handsets. That's why a site should be built and tested for worse conditions than the connection in the office where it's made. The causes that come up most often:

• Layer upon layer of generic tooling. A page builder on top of a universal theme on top of dozens of plugins — each layer can add code that every visitor downloads, although nobody uses all of it. The issue isn't the label on the tool, it's what actually reaches the browser.
• Unprepared images. A photo uploaded straight from a phone can weigh several megabytes even though it's displayed at a fraction of its real size. Resized, compressed and served in a suitable format, it can arrive far lighter with no visual difference the visitor would notice.
• Scripts accumulated over time. Marketing pixels, chat widgets, banners, "just one more small script" — each with its own justification, but the combined effect has to be measured, not assumed.
• Hosting chosen on price alone. Undersized or badly configured hosting increases response times, and it shows exactly when it shouldn't: when you have traffic.
• Content and integrations added after launch. Performance doesn't stay constant by itself. New images, tracking codes and integrations added over time can change the results of a site that was fast on launch day.

None of this is visible in the demo someone shows you during the sale. All of it shows up afterwards, in how the site behaves with real visitors.

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 more important effect comes from people, not from the algorithm. A visitor who waits four seconds may well go back to the search results and click the competitor below you. You paid — through ads or through the position you earned — for that person to reach you. It won't appear in a rankings report, but it does show in your Analytics behaviour data, if you look there.

Speed is designed in, not added at the end

Here's the part proposals leave out: many of the decisions that settle a site's speed are made at the foundation. How pages are generated, how images are prepared, how much code reaches the visitor, which third-party services you accept, which pages and thresholds you check before launch — these are architecture decisions, taken in the first week of work.

That doesn't mean every slow site needs rebuilding. Plenty of problems are solved by optimising images, removing unnecessary assets, configuring caching or moving to more suitable hosting. Others are architectural, and there a serious repair often resembles a rebuild — which is where the price of a website done properly comes from. The order is the same either way: diagnosis first, recommendation after.

Conclusion

A fast website isn't defined by one score or one technology. What matters is the real experience of its visitors, how each page is built, and how the site is maintained after launch. The good news: you now know how it's measured, and the test is one click away.

Take it — on several pages, on mobile and on desktop. Read the field data separately from the lab simulation, and treat the recommendations as the starting point for a diagnosis.

A green result is a good signal, not a guarantee. A red one is a starting point, not a verdict on the whole project. If it does come back red, ask whoever built your site to explain it with the numbers on the table — or, if all you get in return is a shrug, describe your project to us. We'll tell you directly what can be fixed through optimisation, what's structural, and which intervention is proportionate to the problem.