Why websites get faster the second time you open them

Most of what we call "fast" on the web comes down to one habit: not doing the same work twice.

That's the theme of this week's Tech Titbit Thursday, my weekly series where I pick five tech words and explain them in plain language, the way I'd explain them over a cuppa. Last week was about how the internet talks. Quick recap: DNS is the phone book. Latency is one trip, throughput is how much you carry. TCP signs for the parcel, UDP just shouts. And HTTP/2 and HTTP/3 are the self-checkouts.

This week is about speed, and almost all of it is about keeping copies close by.

One: caching

Caching means keeping a copy of something close by, so you don't have to fetch it again.

Think of milk in the fridge. You don't drive to the shop every time you want a cuppa. You bought it once, it sits there, and you pour.

Websites do the same thing all over the place. Your browser keeps copies of images and files it has already downloaded, so the second visit to a page usually feels quicker than the first. That's the whole trick behind the title of this post.

Two: CDN

CDN stands for content delivery network. Picture one big warehouse that ships everything, to everyone, from one spot. It works, but customers on the far side of the world wait longer.

A CDN is the other approach. You keep stock in branches all over the world, so visitors get your files from somewhere nearby. Same products, shorter drive. If you remember latency from last week, this is how you cut it without asking anyone to move house.

Three: edge caching

The edge is the server closest to your visitor. Edge caching means the copy is already sitting there, so the request gets answered on the spot and your main server never even hears about it.

I like this one because it's so relatable. The corner dairy has the pies, so nobody rings the bakery. The bakery gets to keep baking instead of answering the phone all day, and your main server gets the same break.

Four: cache invalidation

Here's the catch with keeping copies everywhere. Things change.

Cache invalidation is telling every copy it's out of date, so it goes and gets the fresh one. Skip it and the cache lies to you. It's a cafe board with yesterday's prices on it: confident, nicely written and wrong.

My view: of the five, this is the one that actually bites people. Adding a cache is the easy part. Remembering that every copy needs to know when the original changed is where the afternoons go. You update a page, refresh, and nothing has changed. You refresh again. Still nothing. Usually the page is fine and a copy somewhere hasn't been told.

Mr. Mummu, who turns up in these posts now and then, once took a photo of the price board at the fruit shop. Walking to the back of the shop to read it was, in his words, "thirty seconds of my life I am not getting back". Three weeks later he arrived at the counter with exact change for two mangoes and held his phone up to the cashier as evidence. The cashier pointed at the actual board, which had gone up a dollar. "Your phone is lying, Uncle." Mummu went home and opened his notebook marked "Urgent", just under "ghee", and wrote: "New photo every week." Then he crossed out "every week" and wrote "when the mangoes change."

He doesn't know it, but he'd just described the two usual ways caches get told to refresh. On a timer, or when the thing itself changes.

Five: cold starts

Serverless code is code that only runs when someone asks for it. That's handy, because you're not paying to keep a server awake all night. The trade-off is that code which has been sitting idle has to start up before it can answer, so the first request is slow.

It's the coffee machine first thing in the morning. The first cup takes ages while it warms up and gurgles at you. The second cup is quick.

So if a page on your site is sometimes slow and sometimes fine, and the slow one is usually the first visit after a quiet spell, a cold start is a good suspect.

Where the analogies stop

One honest limitation. These analogies are simplified on purpose. Real caching setups have more layers and more settings than milk and a fridge, and two sites can behave quite differently for reasons a pie shop can't explain. Treat these as a map for asking better questions, and the documentation for whatever you're using as the actual answer.

Still, the map is useful. Next time an AI coding assistant tells you "it's probably a stale cache", you'll know what it means and where to look first.

The video version is about two minutes long and has a joke I'm still slightly proud of: why are caches terrible at arguments? They keep bringing up old stuff. It's episode two of the series on my YouTube channel, and I'll drop it in the comments.

Next Thursday is what happens when everyone turns up at once: load balancing, scaling up versus scaling out, and health checks.

Until then, wipe the board when the prices change.