Why Your Code Changes Aren't Showing Up: A Quick Guide to Caching

The simple version

Imagine you’re in a library that keeps a copy of every book you borrow. The next time you want the same book, the librarian hands you the copy from the shelf instead of fetching it from the main collection. That’s caching in a nutshell: a temporary copy of data that makes future requests faster.
When you update a file or change a piece of code, the old copy in the cache can still be served. That’s why your latest changes sometimes look like they never happened. This article explains why caching exists, where it lives in a typical web project, and how to make sure your changes appear right away.

How Caching Works in Everyday Apps

Think of a cache as a mini‑fridge in your house.

• Freshness: The fridge keeps food warm, but if you put a new item in, the old food might still be there until you open the door.
• Speed: You can grab something from the fridge in seconds, whereas getting it from the pantry would take longer.

In software, a cache stores data (HTML pages, images, database query results, etc.) closer to the user or the part of the system that needs it. When a request comes in, the system first checks the cache:

1. If the data is there and still valid, it returns it immediately.
2. If it’s missing or expired, it fetches fresh data from the original source (disk, database, or remote API) and then stores that copy for the next request.

Because the cache is faster, most applications use it for everything that doesn’t change every second.

Where Caching Lives in Your Project

A web project can have several layers of caching, each with its own purpose:

If you’re working on a front‑end project, the browser and CDN are most likely the culprits. If you’re on a back‑end or full‑stack project, server‑side caching or database caching might be involved.

Why Your Changes Don’t Appear Immediately

There are a few common reasons why a new change might be invisible:

1. Stale cache – The old data is still stored and being served.
2. Time‑to‑live (TTL) – Each cached item has an expiration timer. Until that timer runs out, the old copy remains.
3. Cache‑busting missing – Static files often get a hash or version number in their filename (e.g., app.3f4a.js). If you change the file but don’t update the reference, the browser keeps loading the old one.
4. Development mode caching – Some frameworks keep a cache even in dev mode to speed up builds.
5. Proxy or CDN cache – If you’re behind a reverse proxy or a CDN, they might be caching your responses for a long time.

Quick Diagnostic: Inspect the HTTP Headers

curl -I https://your-site.com/static/app.js

Look for headers like Cache-Control, Expires, or ETag. If Cache-Control: max-age=31536000, the file is cached for a year.

Common Fixes and Best Practices

Example: Cache‑busting with a Query String

<!-- Old: -->
<script src="/static/app.js"></script>

<!-- New: -->
<script src="/static/app.js?v=20240927"></script>

Every time you change the file, bump the value after ?v=. Browsers treat it as a new URL and fetch the latest version.

Tools and Commands to Inspect Caches

If you’re using a CDN like Cloudflare, they provide a “Purge Cache” button in the dashboard. Use it when you know the content has changed.

What to try next

1. Clear your browser cache – Press Ctrl+Shift+Delete (or the equivalent on your OS) and remove cached files. Reload the page and see if the changes appear.
2. Add a cache‑busting query string – Append ?v=1 to the URLs of your static files, then increment it whenever you update those files.
3. Check the HTTP headers – Run curl -I https://your-site.com/static/app.js and look for Cache-Control. If it’s set to a long period, lower it or purge the cache.

By understanding where caching lives and how to control it, you’ll stop chasing invisible changes and get back to coding faster. Happy hacking!