What Is Caching? A Beginner's Guide to Making Apps Faster

There's a famous joke in programming: "There are only two hard things in computer science: cache invalidation and naming things." This guide covers the first one — without the hard part scaring you off, because caching is also one of the simplest ways to make an app fast.

The idea

Caching means keeping a copy of something so you don't have to fetch or calculate it again.

You do it all the time: you keep milk in the fridge rather than going to the shop every time you want tea. The fridge is a cache. It's fast and close by. The shop is the "source of truth" — slower, but always has the real thing.

In apps, fetching data from a database, calling an outside API, or building a complex page takes time. A cache stores the result so the next request can reuse it in a fraction of the time.

Where caches live

A request passes through several layers, and each can cache:

Browser → CDN → Your server → Database

1. The browser cache

Your browser keeps copies of images, stylesheets, and scripts so it doesn't download them on every page. The server controls this with a response header:

Cache-Control: public, max-age=31536000, immutable

That says "keep this for a year." Frameworks give built files unique names like app.3f9a2c.js, so when the file changes, the name changes, and browsers fetch the new one. (HTTP Caching Headers goes deeper.)

2. The CDN

A content delivery network keeps copies of your files on servers around the world, so users download from somewhere near them. (What Is a CDN?.)

3. Your server's cache

Your app can store results of slow operations in memory or in a fast store like Redis: the product list, a user's permissions, the response from a slow external API. (Redis: When You Actually Need It.)

async function getProducts() {
  const cached = await cache.get("products")
  if (cached) return cached                       // fast path

  const products = await db.query("SELECT ...")   // slow path
  await cache.set("products", products, { ttl: 300 })  // keep 5 minutes
  return products
}

4. The database's own cache

Databases keep frequently used data in memory automatically. You mostly don't manage this, but it's why the same query is often faster the second time.

The hard part: stale data

A cache is a copy. When the original changes, the copy is out of date — stale — until it's replaced.

You change a product's price, and the site still shows the old one. You deploy a fix, and your browser still runs the old code. That's stale cache.

There are two main ways to deal with it:

Expiry (TTL). Every cached item has a time to live. After five minutes, it's thrown away and fetched fresh. Simple, and the data is never more than five minutes stale.
Invalidation. When the original changes, delete the cached copy immediately. Fresher, but you must remember to do it everywhere the data changes.

The right choice depends on the data. A product catalogue can be a few minutes old. A bank balance can't.

"Have you tried a hard refresh?"

When a site looks broken after a change, the classic fix is a hard refresh, which reloads the page ignoring the browser cache:

Windows/Linux: Ctrl + Shift + R (or Ctrl + F5)
Mac: Cmd + Shift + R

For a thorough reset, open DevTools, right-click the reload button, and choose Empty Cache and Hard Reload. (Browser Developer Tools for Beginners.)

If a hard refresh fixes it for you, remember your users don't know to do that. The real fix is making sure changed files get new names or appropriate cache headers.

What to cache, and what not to

Good candidates:

Images, fonts, CSS, and JavaScript files.
Data that's the same for everyone and changes rarely: a product catalogue, blog posts, settings.
Results of slow external API calls.
Expensive calculations: reports, statistics.

Be careful with:

Anything personal. Caching one user's page and showing it to another is a serious privacy bug. Personal responses need Cache-Control: private or no caching, and server caches must include the user in the key.
Anything that must be exact right now — balances, stock levels at checkout, permissions just revoked.

Don't cache first

Caching adds complexity and a new class of bugs. Before adding one, check the slow thing can't simply be made faster — a missing database index is a much more common cause of a slow app than a missing cache. (Database Indexes and Why Is My Website Slow?.)

EasySpawn workspaces can run Redis alongside your app on the Team plan, so Claude Code can add a server-side cache — and test it — in the same environment you deploy. See pricing or join the waitlist.