Why the beautiful site is slow, and what to do about it

Your site looks lovely on your laptop. On a phone, on a weak mobile connection, it is seconds of white screen. A slow website is rarely slow because the code is bad. It is slow because every beautiful idea stayed on it: an animated background, big photos, four typefaces, a video in the header. On its own each one is harmless. Together they are the load time.

Why is a beautiful website slow?

A beautiful website is slow because the look is made of large files and constant redrawing. A big photo takes time to arrive, so does a typeface, and an animated background keeps the phone's graphics chip busy for as long as the page stays open. The browser queues all of that ahead of your text.

A browser works in order. It downloads the HTML first, learns from it which stylesheet, typeface, image and script it still needs, and until the important pieces arrive it has nothing to paint. Every extra layer is one more entry in that queue, and the queue runs longer on a slower connection.

The second cost is not the download but the painting. An animated background or a light effect that never stops recalculates itself frame by frame. On a fast machine you will never notice. On a three-year-old mid-range phone the scrolling stutters, the device warms up and the battery drains.

Four things eat most of a website's speed:

• Images: a photo exported straight out of a design tool is often several megabytes, and it looks exactly the same as the far smaller version exported for the web.
• Typefaces: every weight and italic is its own file, and until it arrives the text is either invisible or swaps to another face while you read.
• Scripts: a slider, a cookie bar, a chat window and three tracking snippets are each tiny, but together they occupy the phone's processor at the exact moment the visitor wants to tap.
• Motion: anything that runs constantly in the background costs something constantly, including when nobody is looking at it.

None of these is a mistake on its own. The mistake is that when a new layer goes on, nobody asks what it costs. The look is always visible, the price never is.

How slow is too slow?

There is no single number, but there is a shared yardstick: Core Web Vitals. The most important one is LCP, the time until the page's main content appears. It counts as good under 2.5 seconds. The other two measure responsiveness and how much the page jumps: there even tenths of a second and a few pixels of shift count.

Core Web Vitals means three numbers, and each measures something different. LCP is when the main content shows up, usually the big image or the headline. INP is how long a visitor waits after tapping something. CLS is how much the content jumps while the page loads: good is under 0.1, and the easiest way to ruin it is a banner that drops in late or an image with no reserved space.

Where you measure matters more than the numbers themselves. Your own laptop, on a fast connection with a full cache, always gives a flattering result, because you already have every file. Your visitor is there for the first time, on mobile data, on a tram, with an older phone. That second situation is the one telling the truth about your website speed.

There is a fourth question no metric asks: what is actually visible in those few seconds? If the page appears fast but the first screen holds nothing except a slogan, the visitor leaves anyway. Speed becomes valuable when it brings forward the sentence they came for.

What should you measure if you aren't a developer?

Pick up an ordinary phone, turn off the wifi, and open your own site the way a stranger would. What you see in those first moments is the truth. Then run a public speed test on your three most important pages, and ask your developer for the same three numbers every month.

Start with your own phone, because nobody can explain that measurement away. Open the site on mobile data and watch three things: when the first readable sentence appears, whether the content jumps after that, and how long the gap is between your first tap and the answer. Those three observations roughly cover the three metrics, only without numbers.

Then comes the machine measurement. A public speed test will give you a report on any public page, with the metrics and a list of which file took how long. Two things are worth knowing about it: the mobile result is the one that counts, not the desktop one, and a single test is not the same as what your real visitors get on their own devices.

If you have a developer, do not ask for a fix list. Ask for these three:

• Numbers: the three metrics for your three most important pages, on mobile, in the same format every month.
• A cause: which element is eating the time, by name, not just that the page is heavy.
• A price: what we lose if it goes, and what we gain if it stays. That sentence decides everything after it.

For us this is not a separate round at the end of the job: our website build page follows the same order, because speed is harder to win back later than it is to never spend.

What did we throw out of our own site?

Three things. The floating cloud layers on the home page, because each was a full-screen texture that a blending mode forced the browser to flatten every frame. A WebGL light effect, for the same reason. And the background pattern on the inner pages: 70 kilobytes on a phone, and wallpaper rather than composition.

Three cloud layers used to drift across each other on our home page, and it looked good. Then we measured it: the layers kept the phone working even when nothing was happening, because the blending mode meant they had to be flattened again on every frame. The WebGL light effect put the same load on the phone, so that went too. The scene got no poorer without either of them.

With images we did not get rid of them, we generate them. Every photo is built as an AVIF and WebP pair in three widths, and the browser downloads the one the screen actually needs. The large master stays on our own machine and never enters the deployed package. The quality bar is not file size either: it is the per-pixel difference from the original, and that number decides whether an image is good enough.

The typefaces come from our own server, not from an external font service link, and there are two of them, not four. The reason is not only speed: such a link hands every visitor's IP address to an American provider, which is a separate line in a Hungarian company's privacy notice.

The result shows best in the opening scene of the page: at rest the hero's background layers do not redraw a single frame today. The look stayed, only the constant redrawing behind it is gone. A human made all of those calls, by the way, even where a machine wrote the words: that is what the post a single prompt wrote is about.

What must not be thrown out?

Accessibility and the words. The focus ring, the skip link and the reduced motion variants all stayed on our own site: these are not decoration, they decide whether someone can use the page at all. And we do not throw out the text either, because an empty page that loads instantly answers nothing.

Speeding things up easily turns into taking something away. The focus ring, the outline that shows where the keyboard currently is, disappears from many sites because somebody found it ugly. If you use a mouse, you never see it. If you cannot use a mouse, without it you have no idea what you are about to press.

The same goes for the skip link that jumps past the menu straight to the content, and for the reduced motion variants: if a visitor turned animation off on their own device, our page does not animate either. Together these are a few lines of code, so deleting them would improve nothing. We do not trade accessibility for speed.

The other thing worth leaving alone is the text. Speed on its own answers nothing: an empty page scores perfectly and says nothing at all. Search engines and AI answers both work from the words, which makes the paragraph that genuinely answers a question the most valuable and the cheapest part of the page. That is the subject of our piece on GEO optimization.

So the right order is not to throw out everything that looks good. It is to ask every element what it adds and what it costs. Whatever answers both questions well can stay. The rest can go.

Measurement decides, not taste.