When a website feels instant, that's not luck. Someone made it feel that way with a stack of small, deliberate choices. And when a site makes you wait, that's usually a stack of choices too, just ones nobody stopped to make.
I care about this from both directions. I build sites to be quick, and lately I spend a good chunk of my time rescuing apps that are painfully slow. So I get to watch the same thing from both ends: what makes a page feel instant, and what makes someone give up before it even finishes loading.
What "fast" actually means
To a visitor, fast is a feeling more than a number on a stopwatch, and that feeling has surprisingly precise limits.
There's some lovely old research from Jakob Nielsen on how people experience waiting. Under about a tenth of a second, something feels instant, like you caused it directly. Up to about a second, you notice the delay but your train of thought holds. Past about ten seconds, you've lost the person, they've mentally wandered off (Nielsen Norman Group). Those numbers were true decades ago and they're true now, because they're about people, not computers.
Google cares too, and it's put numbers on it. Its Core Web Vitals ask for three things: the main content should show up within 2.5 seconds, the page should respond to a tap in under 200 milliseconds, and things shouldn't jump around while it loads (Google). Hit those and you're in good shape. Speed on its own is a small ranking factor, more of a tiebreaker between two otherwise equal pages, but it quietly decides money too. Google's own research ties faster pages to real jumps in sales and fewer people leaving (web.dev).
Why sites make you wait
Most slowness comes from a short list of usual causes, and I see all of them in the apps I get called in to fix.
The biggest one is almost always images. On a typical site, images are around half of everything the page has to download (HTTP Archive). A single hero image can weigh three or four megabytes when it would look identical at a couple hundred kilobytes. Nobody sets out to ship a giant image. They just drop in the photo straight from the camera and move on.
Then there's too much code loading at once. Every extra script and style the page pulls in is more it has to fetch and run before it can show you anything. This is where template and page-builder sites really struggle, because they load the code for every feature they offer whether your page uses it or not. A lean, hand-built site only ships what it actually needs.
And last, but not least, there's the slow servers. Before any of the visible stuff can happen, the page has to travel from a server to your visitor, and if that server is far away or overloaded, everything is slow before it even begins. One thing I lean on here is serving sites from the edge, from machines close to wherever the visitor is, so that first trip is short. My own site runs this way.
And then there's the stuff that isn't loading speed at all but feels like slowness. The layout jumping around as things pop in, so you go to tap one thing and something else shoves it aside. Taps that don't respond for a beat. Scrolling that stutters and lurches. None of these are about how many seconds the page took. They're about whether it felt smooth while you used it, and people remember that just as sharply.
Show the important thing first
You don't have to make everything fast at the same moment. You have to make the right thing fast.
When someone lands on a page, they want one thing first: the main content, the headline, the hero, the reason they came. So that's what I load first, and I let the less urgent stuff (things further down, extra scripts, anything they can't see yet) come in a moment later. Get the top of the page painted quickly and the site feels ready, even while a few things are still arriving quietly in the background.
This is also where feeling fast and being fast stop being the same thing, and I care about both.
Say something really does take a second or two, a bit of data loading in. A blank screen with a spinner in the middle feels like being made to wait. Showing the shape of the page first, a soft outline of where the content will be, feels like the page is already arriving. Same wait, completely different experience. Progress feels quicker than a blank pause, every single time.
So I put thought into the wait itself, the same as the load. Buttons that react the instant you press them. Content that fills in as it arrives instead of appearing all at once. Nothing jumping around to make you lose your place. The goal is a site that feels quick to a person, which is a slightly different and more human target than a site that just scores well on a test.
Two checks you can run today
You don't need to be technical to get a feel for this on your own site.
First, run it through Google's PageSpeed Insights. Paste your address in, and it grades you on those Core Web Vitals using real visitor data, then tells you in fairly plain terms what's dragging you down. It's free, and it's the same data Google itself looks at.
Second, open your site on your phone, on mobile data, not your fast home wifi. That's how a lot of real people arrive, and it's revealing. Watch what loads first, whether anything jumps around, and how long it is before you could actually do something. If you find yourself waiting, so is everyone else.
And if you want the quickest check of all, notice the images. They're usually the heaviest thing on the page, so when a site feels heavy, that's the first place I look.
Fast is a choice
Almost none of this is visible. Nobody lands on a quick site and thinks about the compressed images or the code that didn't load. They just feel like the site respects their time, so they stay.
That's why I treat speed as part of the design from the start, rather than something added at the end. A site that's ready the moment someone arrives has already made a good impression, before it's said a single word. 🐾