← All notes

What actually makes a website fast

Most “slow website” problems aren’t caused by slow code. They’re caused by decisions made months earlier, usually before speed was part of the conversation. Here’s where the time actually goes.

1. How much you send

The single biggest factor is the amount of stuff a browser has to download before it can show anything useful. A typical small-business site built on a page builder ships somewhere north of 2MB before a word appears on screen: a theme framework, a slider plugin, three icon libraries, and a font family in nine weights when the design uses two.

Nothing you do later fixes this. You can compress a 2MB payload, cache it, and serve it from a CDN — it’s still 2MB.

The fastest code is the code you never sent.

2. Where it comes from

Every separate domain a page talks to costs a DNS lookup, a TCP connection, and a TLS handshake before a single byte of content moves. Do that four times for fonts, analytics, a chat widget and a tag manager, and you’ve spent half a second on paperwork.

Self-hosting fonts instead of loading them from a third party is usually the cheapest win available — it removes an entire connection from the critical path. It also means visitor IP addresses stop being shared with someone else, which is a privacy question as much as a speed one.

3. What blocks rendering

Browsers stop and wait for some resources but not others. A stylesheet in the <head> blocks rendering until it’s parsed. A <script> without defer blocks HTML parsing where it sits. Fonts without font-display: swap can leave text invisible while they load.

These are one-line fixes that routinely account for a second or more:

  • Add defer to scripts that don’t need to run before paint
  • Set font-display: swap so text renders in a fallback immediately
  • Give images explicit width and height so the layout doesn’t jump
  • Load anything below the fold lazily

What this means if you’re hiring someone

Ask how they plan to keep the site fast before the build starts, not after. “We’ll optimize it at the end” usually comes down to compressing the images. That’s the smallest lever of the three, and it’s the only one that survives a bad architecture.

If you want to check your own site, PageSpeed Insights is free and reports real-world data from actual Chrome users, not just a lab test. Look at the field data at the top rather than the score — the score is a lab simulation, the field data is what your visitors experienced.

Got a question this didn't answer?

I answer these myself. Twenty minutes on a call, no pitch.

Required