What actually matters in a website (and why fast ones win)

It's easy to assume a website needs to look impressive to work well. In practice, the sites that actually do their job — get someone to understand what you offer, and then do something about it — usually look plain next to the ones stuffed with animation and video backgrounds. What actually matters is shorter than it looks, and speed turns out to be most of it.

What genuinely earns its place

• A clear answer, immediately. A visitor decides whether to keep reading within a couple of seconds — what you do, and whether it's for them, needs to be obvious without scrolling.
• It works on a phone, properly. Most visits to most small business sites happen on a phone, not a laptop — a site that only really works on a wide screen is failing most of the people who arrive at it.
• One clear way to act. Call, buy, book, get in touch — pick the one thing you actually want a visitor to do, and make it impossible to miss. A page offering five equally-loud choices usually gets none of them taken.
• It loads before someone gives up. Everything else on this list is wasted if the page isn't on screen yet when a visitor decides to leave.

Why speed specifically matters this much

A slow site doesn't just feel worse — it measurably loses visitors before they see anything at all, and search engines factor real-world loading speed into ranking directly, under the umbrella of what Google calls Core Web Vitals. Neither of those is a minor detail: one affects whether somebody who found your site stays on it, the other affects whether they find it in the first place.

The frustrating part is that slow websites are rarely slow for a good reason. The usual culprits are avoidable rather than necessary:

• Images sized for a camera, not for a screen. A 4000-pixel-wide photo shown at 400 pixels is 10x more data than the browser will ever actually display — the single most common source of a slow page, and the easiest to fix.
• JavaScript the page didn't need to run. A large framework downloaded and parsed just to render some text and a button costs real, measurable time — before a visitor sees a single word.
• Third-party scripts nobody's watching. Trackers, chat widgets and embeds pulled in from elsewhere each add their own round trip, and each one can be a website's speed silently getting worse over time as more get added and none get removed.

How the site you're reading this on was actually built

Since this is the exact question this article is about, it seems fair to say plainly how webaki's own pages are put together — because it's the same three ideas as above, just applied rather than just described.

• Every page is assembled into one complete, self-contained document ahead of time, rather than a shell that then asks the browser to fetch and assemble several more pieces before there's anything to show.
• Every image on this site is resized and compressed specifically for the exact size it's ever actually shown at — the three illustrations on our homepage, for instance, are a tenth the size they started as, with no visible difference at the size anyone actually sees them.
• There's no large front-end framework running in the background, doing work a visitor never notices except in the form of a page that takes longer to feel ready.

None of that is a clever trick — it's mostly the absence of things that didn't need to be there in the first place, which is a genuinely boring answer, and also the honest one.

What to actually check on your own site

If you're looking at an existing site and wondering where to start: open it on a phone, on an ordinary connection, and time how long it takes before you can actually read the main heading. If that feels slow to you, it's slow to every visitor who doesn't already know and trust the business behind it enough to wait.

Our website builder is built around exactly this — a fast, working one-page site out of the box, without a framework to configure or a plugin to go looking for.