cache
A cache is a stored copy of a page kept close to the visitor so it can be handed over instantly, instead of being rebuilt or fetched from further away each time.
A cache is a copy of something, kept somewhere fast to reach, so the same work does not have to happen again. In web hosting, it usually means a copy of a page or an image, stored at a data centre close to the visitor, ready to be handed over the instant it is asked for, instead of being rebuilt or pulled from further away each time.
Think of it as the difference between answering a question from memory and looking it up again from scratch every single time someone asks. If the answer has not changed, there is no reason to redo the work.
For a static site, most pages are close to ideal candidates for this, because the file that gets served is the same for every visitor until the next deploy changes it.
Why it matters to you
Caching is one of the biggest reasons a site served from a CDN feels instant. Instead of every visitor’s request travelling all the way to wherever the page was originally built and waiting for it to be assembled, the nearby the edge location has already got a copy ready, and hands it over immediately.
It also reduces load on the systems that build the page in the first place. If ten thousand people ask for the same page in an hour, a well cached setup answers most of those from stored copies, rather than doing the same work ten thousand times.
How I set it up
Because the sites I build are static files, most pages are cached aggressively at the edge by default, with rules that say how long a copy is considered fresh before checking for a newer one. When I deploy a change, that deploy also tells the network the old cached copies are no longer valid, so visitors get the new version right away instead of waiting for a cache to expire on its own.
I am careful about what does and does not get cached this way. A page that is the same for everyone is a good candidate. Something that depends on who is asking, such as a logged-in area, is handled differently, so a cache never accidentally shows one visitor’s information to another.
What it looks like in practice
Caching is invisible when it works, which is most of the time. A visitor loads a page and it appears immediately, whether they are the first person to view it that day or the ten-thousandth. If I make a change and deploy it, that change is live everywhere within a couple of minutes, without anyone needing to manually clear anything or wait out an old cached copy.
Questions I get about this
- If my page is cached, will visitors see an old version after I make a change?
- For a moment, possibly, depending on how the cache is set up. On the sites I build, a deploy clears the relevant cache automatically, so a change goes live and stops serving the old cached copy at the same time, not on some separate delay.
- Is caching the same as backups?
- No. A cache is about speed, a temporary copy kept for quick delivery. A backup is about recovery, a copy kept in case something is lost. A site needs both, but they solve different problems.
- Can caching cause a page to look broken?
- It can, if it is set up carelessly, for example if a page that changes per visitor gets cached as if it never changes. That is why the cache rules matter and are not just switched on blindly for everything.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.