We’ve written before about why a faster website is worth paying for - people leave slow pages, and Google notices. This is the other half of that: what actually makes a page fast or slow in the first place. None of it is magic, and most of it comes down to a few decisions made early.
You can think of loading a page as a delivery. The browser has to find out what to fetch, go and get it, and then assemble it into something you can see. Speed is mostly about how much gets sent, how far it travels, and how much work the browser has to do once it arrives.
How much you send
The single biggest factor is weight. Every image, font, script, and stylesheet is something the browser has to download before it can finish the page, and on a phone with a patchy signal, every extra kilobyte is felt.
Images are usually the worst offender. A photo straight off a camera or a stock site can be several megabytes - many times the size of everything else on the page combined. Saved properly, that same photo can look identical at a fraction of the size. Done right, the browser is also handed a smaller version for a phone and a larger one for a desktop, instead of sending everyone the giant one. This is dull, unglamorous work, and it’s where most of the real speed on a page is won or lost.
Then there’s code. A site stitched together from a page builder and a stack of plugins tends to load a pile of JavaScript and CSS, most of which the page doesn’t even use, because each add-on brings its own. We dug into that in the hidden cost of page builders. A hand-built page sends close to what it needs and not much else.
How many trips it takes
Beyond size, there’s the number of separate things the browser has to go and fetch. Each file is a small errand, and a page cobbled together from dozens of them spends real time just asking for them all and waiting for replies.
This is part of why a lean site feels quick even on a slow connection: there’s less back-and-forth. Fewer fonts, fewer scripts, fewer third-party widgets each phoning home. Every chat embed, tracking pixel, and “free” tool you drop onto a page is another errand, often to a server you don’t control and can’t speed up.
How far it travels
A server in one country answering a visitor on the other side of the world adds a delay you can’t code your way out of - the request physically has to get there and back. The fix is a CDN, which keeps copies of your site on machines all over the world so each visitor is served from one near them.
For a static site like the ones we build, this is close to free and enormously effective, because there’s no database to wait on - the page is already built and just needs handing over. The visitor gets a finished page from a nearby machine, which is about as fast as the web gets.
How fast it shows up
The last piece is what the browser does once everything arrives. A page can technically have all its files and still sit blank because it’s waiting on a big script to run before it shows anything. Pages that lean on heavy JavaScript to assemble themselves in the browser are prone to this - there’s a beat where the visitor stares at nothing.
The opposite approach is to send a page that’s already mostly built, so the browser can show it almost immediately and fill in the interactive bits after. That’s why a well-built static site feels like it just appears, while a heavier app-style site loads in visible stages.
Where it actually comes from
Notice what isn’t on this list: a magic plugin. You can’t bolt speed onto a slow site after the fact, not really. The “performance” plugins that promise to fix it are mostly papering over a foundation that was heavy from the start, and they bring their own weight doing it.
Fast pages come from decisions made at the beginning: send less, ask for fewer things, serve from nearby, and show the page without waiting on a pile of script. Get those right and you rarely have to think about speed again. Get them wrong and no amount of patching gets you all the way back. If you’re not sure which side your current site is on, a quick look will usually tell.
