Cache | Learn IT Fundamentals with Teacher Pochi

Key points

A cache is a mechanism that temporarily stores data you've fetched once, so it can be reused later.
It's used in multiple places along a request's path — the browser, the CDN, a reverse proxy, and the application itself.
Beyond faster page loads and reduced server load, it's an important factor in SEO and conversion rates too.
There are plenty of real-world caching solutions in everyday use, from Cloudflare to Redis to Varnish.
Some data — personal information, anything that needs to be real-time — is a poor fit for caching, and misconfiguring it can cause real incidents.

What is a cache?

A cache is a mechanism that temporarily stores a copy of data fetched from a server — close at hand, whether in the browser or at a relay point along the way — so it can be reused the next time that same data is needed.

Because you don't have to go all the way to the server every time, pages load faster and the server's load is reduced too.

Teacher Pochi's hintThink of it like keeping a stock of food in the fridge. Instead of going out to buy a seasoning you use often every single time (asking the server), you keep it stocked in the fridge ahead of time (stored in the cache) and can grab it whenever you need it.

Cache types, part 1: browser cache and CDN cache

Caching doesn't happen in just one place — it exists at multiple points along the path from a user's device all the way to the server. Let's start with the two layers closest to the user.

🖥️ Browser cache Stored on the user's device Effective when the same person revisits

🌐 CDN cache Stored at delivery points around the world Effective no matter who accesses it

Teacher Pochi's hintThe browser cache is like "the stock in your own fridge," and the CDN cache is like "the inventory at your neighborhood convenience store." Only you can use your own fridge, but anyone can walk into the nearby convenience store and pick up the same item right away.

Cache types, part 2: server-side caching

Caching isn't limited to the browser and the CDN out near the user — there are layers on the server side too. The more places along the way that can short-circuit a request and answer it directly, the less load reaches the application and database behind them.

Client

CDN

Reverse proxy
cache

App / DB

🚪 Reverse proxy cache Sits in front of the application server and answers on its behalf for identical requests Examples: Varnish, Nginx's proxy caching feature

🗄️ Application (data) cache Temporarily stores database query results or the output of expensive computations Examples: in-memory stores like Redis, Memcached

Teacher Pochi's hintThink of a company's front desk. For a frequently asked question, the receptionist can just answer it directly instead of forwarding it to the specialist in the back (the database). The fewer times something gets forwarded, the lighter the specialist's workload.

First requests vs. cache hits

The first time you access something, the data is fetched from the server, but from the second time onward the stored copy in the cache is used as-is (this is called a "cache hit"), which can even eliminate the need for network communication entirely.

1st time:
fetch from the server

Store locally

2nd time onward:
reuse the stored copy

First accessCommunicates with the server. Takes time.

Cache hitUses locally stored data. Displays fast.

The Cache-Control header

A server can attach a header called "Cache-Control" to a response to tell the browser or CDN "how long this data may be cached for."

max-age=3600The cache may be reused for one hour.

no-cacheCheck with the server before using it, every time.

no-storeDon't store it in a cache at all.

Files that rarely change, like images and CSS, are typically cached for longer, while frequently changing information is cached for a shorter time or not at all — the settings are chosen accordingly.

Common uses for caching

Caching isn't just about making pages load faster — it's put to work for a range of purposes.

🚀 Faster page loads Load speed is graded as part of Core Web Vitals, a factor in search rankings, and it also directly affects bounce rate and conversion rate

💾 Lighter load on APIs and databases Reusing the same query results reduces the load on servers and databases

🎬 Faster video and image delivery Large media files get cached at the CDN so they can be delivered without delay

📴 Offline support A Service Worker (PWA) serves cached content so pages still work under a weak connection

Real-world caching solutions

Each caching layer has well-known products and services that see heavy use in practice.

🌐 CDN services Cloudflare, Amazon CloudFront, Akamai, Fastly, and more

🚪 Reverse proxies Varnish, Nginx, and more

⚡ In-memory caches Redis, Memcached, and more

🔌 CMS caching plugins WordPress plugins like WP Rocket and W3 Total Cache

These solutions are built to manage cache duration settings and cache-invalidation mechanisms for you, in one place.

Data that's a good fit for caching — and data that isn't

Caching isn't a universal fix. Depending on the nature of the data, some things are well-suited to it and others aren't.

✅ Good fits for caching Static content shared by every user (images, CSS, JS files) Data that rarely changes (a product catalog, article body text) Expensive computations that produce the same result every time (aggregated stats)

🚫 Poor fits for caching Responses containing personal data (a user's dashboard, order history, account balance) Data that needs to be real-time (stock levels, live prices, chat messages) Requests with side effects, like POST, PUT, or DELETE (not cacheable to begin with)

Caveats when using a cache

Caching is convenient, but getting the configuration wrong can lead to unexpected trouble. The main risks are:

Leaking personal dataForget a "private" directive, and a screen meant for one user only can end up served to someone else.

Defense: Cache-Control: private / no-storeAlways set this on any response containing personal data.

Cache poisoningMalicious input gets cached as if it were legitimate content, then served to every subsequent visitor.

Defense: validate input, and limit the cache keyOnly use trusted headers and parameters when deciding what to serve from cache.

Cache stampedeThe moment a popular item's cache entry expires, a flood of requests hits the server all at once.

Defense: locking or staggered expiry (jitter)Keep serving the existing entry while a fresh one is being generated, or spread out expiration times instead of having them all land at once.

Teacher Pochi's hintAccidentally caching data that's a poor fit for it is a lot like handing one customer's order to a different customer by mistake. Figuring out what's safe to cache takes careful judgment.

The "update isn't showing" problem, and how to fix it

Caching comes with a familiar problem: "I updated the data on the server, but the old content keeps showing."

This happens because the browser or CDN decides "we're still within the cache's validity period" and doesn't bother checking with the server. If you make a code change during development and it "doesn't seem to be reflected," caching is often the first thing worth suspecting.

Teacher Pochi's hintThis is a lot like being a regular at a shop where the staff recognizes you by sight. It's convenient when the clerk remembers you and says "the usual, right?" — but if your preference has actually changed, they might not notice and serve you your old order anyway.

Common fixes for this include "cache busting" — baking a version or hash into the filename (e.g. style.abc123.css) — and "purging," where you force a CDN to throw out its stale copy.

Summary

A cache is a mechanism that improves page-load speed and reduces server load by reusing data that's already been fetched once. It's used across multiple layers along a request's path — not just the browser and CDN, but reverse proxies and the application layer too — with well-known solutions like Cloudflare, Varnish, and Redis. It isn't a universal fix, though: data containing personal information or requiring real-time accuracy is a poor fit. Page load speed affects both SEO and conversion rates, and it's worth staying alert to risks like stale content and cache poisoning, using techniques like cache busting and purging.