Two of the words engineers throw around most often are CDN and caching. They sound like deep infrastructure, the kind of thing you leave to the people with terminal windows open. They are not. The ideas are simple, the decisions behind them are mostly yours, and getting them wrong is a common reason a site that looked fast in the studio feels slow to a real customer.
This is the plain version: what these systems do, why they matter to anyone who cares how a site performs, and how to tell whether yours is set up well.
Start with the problem they solve
Every web page lives on a server somewhere. When someone visits, their browser asks that server for the page, the server builds a response, and it travels back across the internet. The further away the visitor is, and the more work the server has to do per request, the longer that round trip takes.
Distance is physical and unforgiving. A request from Sydney to a server in Virginia crosses an ocean and back. Light is fast but not instant, and every hop adds milliseconds. Multiply that by the dozens of files a modern page pulls in (images, fonts, scripts, styles) and the delay stacks into something a person feels.
CDNs and caching attack this from different angles. One shortens the distance. The other removes the work. Together they decide whether a site responds the moment someone taps or makes them wait.
What a CDN actually is
A CDN, or content delivery network, is a fleet of servers spread across the world. Instead of every visitor reaching back to your one origin server, they reach the nearest copy.
Picture a popular book. If the only copy lives in one library and everyone has to mail in a request, every reader waits for the round trip. Put a copy in every city library and most readers walk down the street instead. A CDN does that for your site, keeping copies of your files in data centers (often called edge locations) close to where people are, so a request never has to cross the planet.
This matters most for the heavy, unchanging parts of a site. Your logo, fonts, product photos, and compiled stylesheet do not change between one visitor and the next. Those files can sit at the edge, milliseconds from anyone, and they should.
The payoff shows up in the loading metric Google grades you on. Our field guide to Core Web Vitals covers how edge delivery lowers the time to first byte, which sets the ceiling on every other speed number on the page.
What caching actually is
Caching is the practice of saving a result so you do not have to produce it twice. If something was expensive to make and is going to be asked for again, keep the answer ready.
Building a web response can be a lot of work. The server might query a database, assemble the page, render templates, and stitch in personalized fragments. Do that fresh for every visitor and the server strains, the response slows, and costs climb. Cache the finished result and the next thousand visitors get a copy that was already made, instantly.
A cache hit is a question you never had to answer twice. That is the whole game.
Caching does not happen in one place. It happens in layers, and knowing the layers is what separates a confident decision from a guess.
The layers worth knowing
- Browser cache. The visitor’s own browser keeps copies of files it already downloaded. Return to a page and the logo loads from the device, not the network. You control it with headers that say how long a file may be reused.
- CDN cache. The edge servers hold copies so they can answer without bothering your origin. This is where a CDN and caching meet: the CDN is the delivery network, the cache is what lets it answer on its own.
- Server cache. Your origin can store the result of expensive work (a rendered page, a database query) so it skips that work next time.
- Application cache. Inside your code, frequently used data is held in fast memory instead of being recomputed or refetched every time.
Most performance wins come from the first two. The browser cache and the CDN cache are the ones a non-engineer can reason about, and where teams leave the most speed on the table.
The one hard problem: knowing when to let go
Here is the trade-off at the center of all caching, and the reason it is famously tricky. A cached copy is fast precisely because it is not freshly made. So what happens when the real thing changes?
You update a price. You publish an article. If the cached copy is still being served, visitors see the old version until the cache expires. Cache too aggressively and people see stale content. Cache too timidly and you throw away the speed you were paying for.
The answer is to cache different things differently.
- Static assets that never change in place: cache hard. Stylesheets, scripts, fonts, and images can be cached for a year if you give each version a unique filename. Change the file, change the name, and the browser fetches the new one because it has never seen that name before. This technique, called fingerprinting, lets you be aggressive without ever serving something stale.
- HTML and data that changes: cache briefly and invalidate on purpose. A page might cache for a few minutes, or until you tell the CDN to drop it. Modern CDNs support a purge that clears a cached item the instant you publish, so you get freshness without the wait.
The principle underneath both: separate the things that change from the things that do not, and treat them on their own clocks. Sites that feel both fast and current are not lucky. Someone decided, file by file, how long each thing could live.
How to tell if yours is set up well
You do not need to read config to sense whether this is working. A few honest checks:
- Is the second visit faster than the first? Load a page, then reload. If the second load is noticeably quicker, your browser cache is working. If it is identical, files are not being cached, and that is worth raising.
- Is the site fast far from your office? A site can feel instant where it is hosted and crawl on another continent. Test from elsewhere, or ask someone abroad. A working CDN flattens that gap.
- Does a change appear quickly after you publish? Update something and watch how long the old version lingers. If stale content sticks around for hours, the invalidation strategy needs work.
- What is the time to first byte? This number measures how long the server takes to start responding. Caching and edge delivery are the biggest levers on it, and a slow figure drags everything behind it. The compounding cost is real money, which we broke down in the cost of a slow website.
If those checks come back clean, the plumbing is probably sound. If they do not, you now know exactly which layer to ask about.
Where architecture does the work for you
Some setups make this easy, and some fight you the whole way. A site that builds its pages ahead of time, as static files, is cacheable by default, because there is nothing to recompute and nothing to go stale unexpectedly. That is one of the quiet reasons the Jamstack approach became popular: when pages are pre-built and served from the edge, the CDN is not an optimization you bolt on later. It is the default delivery model, and caching becomes a property you get for free rather than a risk you manage. The shape of your build decides how cacheable your site can ever be, which is why it belongs in the first conversation, not the last.
How Strynal approaches CDNs and caching
Speed is not something we chase at the end of a project. It is decided at the start, in the rendering model and the delivery strategy, before a page is designed. As a boutique studio, the senior team that scopes the build is the team that ships it, so caching decisions live with the people who understand the whole system, not a handoff where they get forgotten.
We default to architectures that are fast because of how they are built: pre-built pages, fingerprinted assets, deliberate cache rules per file type, and edge delivery so distance stops mattering. That discipline is part of our websites and apps practice, and it is the standard we hold as the in-house studio for Global Digital Platforms.
If your site feels quick to you but slow to your customers, the gap is almost always here. Tell us what you are seeing, and we will start by finding which layer is costing you the most.