Guides / Concepts explained

What Is Caching? A Plain-English Guide for App Builders

Caching keeps a ready copy of data so it can be served faster next time. Browser, CDN and server caches explained, plus why you sometimes see old versions.

Mythex Team · 2026-09-29 · 6 min read

Caching means keeping a ready-made copy of something that was slow or expensive to get, so the next request for it can be answered quickly from that copy. The saved copy is called a cache. Your browser caches images so a site loads faster on your second visit; a server caches the result of a slow database query so it doesn't have to run it for every visitor.

Caching makes apps faster and cheaper to run. Its one big trade-off is that a copy can go out of date.

Why caching matters when you build with AI

You'll run into caching in AI-built apps in three ways:

• "I updated the app but I still see the old version." This is the most common caching moment, and it's usually harmless — your browser or a CDN is showing a saved copy.
• Speed. If a page is slow because it recalculates the same numbers for every visitor, caching the result can make it feel instant.
• Cost. Many AI builders and hosts charge for compute, database time and outside API calls. If a thousand visitors trigger the same expensive request, caching lets you pay for it once.

Knowing the basics lets you ask for caching where it helps and spot it when it's the reason something looks wrong.

An everyday analogy

Think of a busy café's kitchen.

Every morning, the chef could brew each coffee from freshly ground beans when it's ordered. That's slow. Instead, they keep a pot of filter coffee ready on the hot plate. Most customers get a cup in seconds — that's a cache hit. When the pot runs out, someone brews a fresh one — a cache miss.

But coffee sitting too long goes stale, so the café has a rule: throw out any pot older than 30 minutes. That rule is the cache's expiry time. Nobody would keep the same pot all day, and nobody would pre-brew someone's custom order with oat milk and three sugars — some things shouldn't be cached at all.

Where caches live

A single page load can pass through several caches, from closest to the user to furthest:

A CDN (content delivery network) is essentially a worldwide network of caches for your site's files.

How a cache decides what to keep

Every cache has to answer the same questions:

• What can be cached? Public, shared data (a product image, a blog post) — yes. Private data (a user's account page, their messages) — never in a shared cache.
• For how long? This is the TTL (time to live). A logo might be cached for a year; a stock level for 30 seconds.
• How does it get updated? Either the copy expires and is fetched again, or the app deliberately removes it when the data changes — called invalidation.

For websites, the server tells browsers and CDNs how to cache each file using the Cache-Control header. For example, Cache-Control: max-age=3600 means "you can reuse this copy for an hour."

Modern build tools handle the hardest part for static files with cache busting: each time a file changes, it gets a new name with a fingerprint, like app.3f9a2c.js. Browsers can cache the old name for a long time, because the new version simply has a different name.

A worked example: a product catalogue

You have a small online shop. The home page shows 50 products with prices and stock levels from the database, plus a "trending" list that requires a slow calculation across all orders.

1. Images and scripts are cached by the browser and the CDN for a long time. Each new build gives changed files new names, so updates still appear.
2. The trending list is calculated once every 10 minutes and stored in an application cache. Every visitor in those 10 minutes gets the saved result instantly.
3. Prices are cached for a short time, and the cache is cleared whenever you edit a product, so customers never see an old price for long.
4. Stock at checkout is never cached. When someone clicks "Buy," the app checks the real database, so it can't sell an item that just sold out.
5. The cart and account pages are never stored in shared caches, because they're personal.

The result: the home page is fast, the database does far less work, and nothing that matters for money or privacy is ever stale.

Key terms

Common misconceptions

• "Caching is always good." Caching the wrong thing causes real bugs: old prices, missing new posts, or — the worst case — one user's private page shown to another. Cache deliberately.
• "If I see the old version, my update failed." Usually it didn't. Try a hard refresh (Ctrl+Shift+R, or Cmd+Shift+R on a Mac) or a private window before assuming something is broken.
• "Caching fixes a slow app." It hides slowness for repeated requests. The first request is still slow, and if the underlying problem is a missing database index, fix that too.
• "I should cache everything for as long as possible." Long cache times suit files that get new names when they change. For HTML pages and data, shorter times are safer.
• "Clearing my cache fixes it for everyone." It only clears your browser. Visitors and CDN caches still have their own copies.

What to ask your AI builder

• "Which parts of this app are slow, and which could be cached safely?"
• "Cache the [trending list / API result] for [N] minutes, and clear it when the underlying data changes."
• "Make sure no page with personal or account data can be cached by a CDN or shared cache."
• "Set long cache times for fingerprinted static files and short ones for HTML."
• "Cache responses from [outside API] so we don't call it on every page load — and tell me how stale that data might get."
• "I see an old version after publishing. Is that my browser cache, or is something not deployed?"

Caching in Mythex

After you publish an update to a Mythex app, the docs note that CDN caches can lag briefly, and a hard refresh of the public URL shows the new version — see How to publish. The Hosting limits page also recommends caching static assets, since hosting, database time and bandwidth are paid for from your credit balance. Anything beyond that — caching query results or API responses — is something you ask the agent to build into your app.

Related reading: what a CDN is, how to make your website faster and what rate limiting is.