Your visitors won’t write to tell you your site is slow. They’ll simply hit back and open the next result. Speed is the quietest form of lost revenue a business can suffer: it doesn’t show up in error logs, no one complains about it — your conversion rate is just lower than it could be.

What does Google actually measure?

Core Web Vitals looks at three things — and all three are about what the user perceives, not what the server measures.

LCP — when does the important part appear

The time until the largest content element (usually the hero image or main heading) appears. The target is under 2.5 seconds. This is the moment the visitor feels: “it’s loaded.”

INP — how responsive is the interface

When you click on something, how long until the page reacts. The target is under 200 milliseconds. This is the metric that captures the “I clicked, but nothing happened, let me click it two more times” experience.

CLS — does the content jump around

If text shifts during loading because an image or an ad arrives late, the user misclicks. The target is under 0.1.

Why are most Hungarian SME sites slow?

In our experience, in most cases there’s nothing exotic behind it — the same four or five mistakes repeat themselves.

• Unoptimized images. A 4 MB JPEG straight from the camera, uploaded without resizing. A single image like this can weigh more than every other element on the page combined.
• Plugin pile-up. Fifteen plugins, three of which you actually use, but all fifteen load their own JavaScript and stylesheet on every subpage.
• Third-party scripts. Chat widget, three analytics tools, heatmaps, ad pixels. Each one small on its own, together they add up to seconds.
• Web fonts. Four typefaces in eight weights, all from external sources, all with flashing text on load.
• Cheap, overloaded hosting. A shared server where your neighbor’s traffic slows down your response time.

How much money is this?

The numbers differ for every webshop, but the direction is always the same: every extra second of load time measurably reduces conversion and increases bounce rate. It's even sharper on mobile, because the network is slower there too — and the majority of traffic to Hungarian SME sites today typically comes from mobile.

If you have a thousand visitors a month and one in twenty leaves because of slowness, that's six hundred lost inquiries a year. Calculate what one inquiry is worth to you.

Measure before you fix

You need two tools, and both are free:

1. PageSpeed Insights. A lab test of a specific URL, with concrete recommendations. Important: alongside the homepage, also test a product or service subpage, since those tend to score worse.
2. Search Console → Core Web Vitals report. This works from real visitor data and shows which page groups are falling short. This is the authoritative one — the lab value is just a reference point.

Write down your baseline numbers before you touch anything. Without that, you won't know if the fix actually helped, or if it just feels better.

Quick wins, in order

The list below is roughly in order of return on effort. On most sites, the first three points alone already bring a noticeable improvement.

1. Fix your images. Modern format (WebP or AVIF), sized to fit the display, lazy loading for below-the-fold images — and a fixed aspect ratio so content doesn't jump.
2. Weed out scripts. Go through what's running on your site. Anything that doesn't drive a decision or revenue, remove it. Load the rest with a delay.
3. Fonts. Maximum two families, only the weights you actually use, self-hosted, with font-display: swap.
4. Caching and CDN. Serve static content from close to the visitor, with a long cache duration.
5. Hosting. If the server's response time alone is over half a second, there's nothing left to optimize on the frontend.

When is it not worth patching?

There's a point where optimizing is a worse deal than rebuilding. Signs of this: the site is built on years of accumulated plugin layers, every update breaks something, editing only works with a developer's help, or the mobile experience is fundamentally different from the desktop one. In these cases, patching wastes both money and time — the next plugin will break it again.

A modern site built with server-side rendering starts out where you'd spend months optimizing the old site to reach — and stays there afterward too, because there's nothing left to accumulate onto.

Curious where your site stands right now? Send us the link, we'll check the Core Web Vitals numbers, and tell you honestly whether optimizing or rebuilding is the better move.