Maybe this has happened to you. You finally updated your company’s website ── but when you open it, the old version is still staring back at you. Or the other way around: someone tells you “the site is fixed now,” yet nothing has changed on your screen. You search around or ask support, and the answer is almost always the same: “Please clear your cache.” You do, and sure enough, it works. But very few people can explain what they just deleted, or why deleting it helped.
This article explains what the cache actually is, from the ground up. Here is the whole map in one line ── the cache is the very reason the same page opens faster the second time, and the “I updated it but nothing changed” incident is the side effect you pay for that speed. The two are the front and back of the same mechanism. If any of these sound familiar, read on.
- A site was updated but kept showing the old version ── on your screen, or your visitors’ screens
- You get told “please clear your cache” but can’t explain what that actually does
- You’ve never wondered why the same page opens noticeably faster the second time
- You clear the cache nervously, unsure whether it will log you out of everything
To keep things beginner-friendly, this article goes easy on jargon. And it won’t stop at how things work ── it goes all the way to the practical calls: in what order to fix “nothing changed,” and what really happens when you clear the cache.
| Question | Section |
|---|---|
| So what is the cache, really? | §1 |
| Where does the cache live? | §2 |
| How long does the old version keep showing? | §3 |
| Why does “I updated it but nothing changed” happen? | §4 |
| How do I fix it? | §5 |
| Does clearing the cache log me out? | FAQ Q1 |
In our series overview, What Happens Between Typing a URL and the Page Appearing?, we noted that “the incident caused by a stale warehouse is a whole article of its own.” This is that article.
1. What the Cache Really Is ── Reusing Materials You Already Fetched Once
1-1. A Single Page Is Built from Dozens of Fetched Materials
When you open a page, what arrives is not one single file. First comes the blueprint (HTML), and as the browser reads it, it fetches every missing material ── images, the styling instructions (CSS), the moving parts (JavaScript) ── from the server, one by one (for the full picture of this process, see What Happens Between Typing a URL and the Page Appearing?). Dozens of materials for a single news page is completely normal.
Now think about it. When you visit the same site tomorrow, its logo image will be the same as today’s. The styling instructions will almost certainly be the same too. Fetching identical files across the world again, every single day, is plainly wasteful, isn’t it?
1-2. So the Browser Keeps a Local Warehouse ── That Is the Cache
So the browser stores materials it has fetched once in a local warehouse (a storage area inside your PC) for a while. The next time you open the same page, any material already in the warehouse skips the fetch entirely and comes straight off the shelf ── this mechanism, and the warehouse’s contents, are the cache.
That is exactly why “the second time feels faster.” On the first visit, every one of those dozens of materials has to be fetched; on the second, most come straight from the warehouse. The more fetches you skip, the faster the page opens.
First visit vs. second visit First visit (every material is fetched) Blueprint HTML : you <──────── server Logo image : you <──────── server Styling CSS : you <──────── server △ one fetch per material Scripts JS : you <──────── server Second visit (straight off the shelf) Blueprint HTML : you <──────── server Logo image : you <── [local warehouse] Styling CSS : you <── [local warehouse] △ the fetch is skipped entirely Scripts JS : you <── [local warehouse]
1-3. Cookies Do a Completely Different Job
Because they always sit next to each other in the delete dialog, cookies and the cache get mixed up constantly ── but their jobs are entirely different. A cookie is the membership card that tells a site “who you are“; the cache is the reuse of materials that are “the same for everyone.” A logo image is the same logo whether it’s you or anyone else, so it can be reused from the warehouse; a membership card is not something you reuse for other people. Deleting them differs just as sharply: clear cookies and you get logged out; clear the cache and pages simply load slower for a while (we’ll sort this out once more in FAQ Q1).
2. Caches Are Everywhere ── the Browser’s Warehouse Is Just One of Them
2-1. “Cache” Is the Name of an Idea, Not a Feature
Here’s the thing: “cache” is not the name of one particular browser feature. It’s the umbrella name for an idea ── instead of fetching something again, reuse the copy you kept at hand. And that idea is used all over the computing world.
| Where | A copy of what | Related article on this site |
|---|---|---|
| The browser’s warehouse | Page materials (images, CSS, JS) ── the star of this article | This article |
| The phone-book notes | Answers to lookups: “this site’s address (IP address) is here” | What is DNS? §5 |
| Shared warehouses in offices and networks | Popular materials pooled for everyone on the network | ── |
| The delivery network’s warehouses (CDN) | Copies of a site’s materials placed around the world | Planned for a future article |
| Ultra-fast memory inside the CPU | Copies of data used in computation (L1/L2/L3 cache) | The memory-hierarchy diagram in the restart article |
If you’ve read our DNS article, you’ll remember this: “once you’ve looked up a number, keep the note for a while and don’t ask again.” That is exactly the same idea. Whether it’s a lookup answer (DNS) or the goods themselves (page materials), the pattern is identical ── reuse a copy, skip the fetch.
2-2. More Layers Mean More Speed ── and More Places for Stale Copies
It’s because all these cache layers are stacked on top of each other that the internet runs at its current speed. If every access worldwide did every fetch in full, every time, neither the lines nor the servers would survive.
But this creates the property at the heart of this article. More places holding copies means more places where an outdated copy can linger. Your warehouse is fresh, but a shared warehouse along the way still holds the old copy ── that can absolutely happen. We’ll pick this thread back up in §4.
The “site side” in that table ── what exactly the server holding the original materials is ── deserves an article of its own. We plan to cover it in a future post.
3. How Long May a Copy Be Reused? ── Best-Before Labels and Stock Checks
3-1. Every Package Carries a Best-Before Label
If the warehouse reused its goods forever, no site update would ever reach your screen. But if the browser phoned the server “is this still good?” for every single item, skipping the fetch would lose half its point.
The compromise is a best-before label. When the server hands over a material, it sticks an expiry on the package: “reuse this for up to an hour,” “this one keeps for a year” (technically, a setting called Cache-Control ── no need to memorize the name). For anything within its date, the browser takes it straight off the shelf and doesn’t even ask the server. That is the fastest path.
The site sets the date per material. A logo image that almost never changes gets a long date; a frequently changing homepage blueprint (HTML) gets a short one ── that’s the typical split.
3-2. Expired Doesn’t Mean Discarded ── the Stock-Check Call
So when the date runs out, does the browser toss the goods and fetch everything again? Not yet ── there’s one more clever step: the stock-check call.
The browser simply asks the server, “this item ── still usable?” If nothing changed on the server’s side, the whole reply is one line: “still good, keep using it” ── the goods themselves are not sent (technically, a short response called 304). However large the file, the call itself takes an instant, so this path is fast too. Only if the item really changed does a new package arrive, fresh label included.
- 1Within the dateStraight off the shelf. The server isn’t even asked (fastest).
- 2Expired → call → “still good”A one-line reply settles it; no goods are shipped (still fast).
- 3Expired → call → “it changed”A new package arrives and replaces the copy on the shelf (same as a first visit).
3-3. The Phone-Book Notes Carry the Same Label
Does this rule ── reuse until the date, then re-fetch ── feel familiar? It’s exactly the TTL from our DNS article (the setting that says how many seconds a phone-book note may be reused). And remember the story that “waiting for a site move to propagate” is really just waiting for notes around the world to expire ── you could say that was the DNS version of the very incident we’re about to solve in §4.
4. The Real Cause of “I Updated It but Nothing Changed” ── the New Files Should Be There
4-1. Nothing Is Broken, Yet the Page Stays Old
We now have every tool needed to solve the incident from the introduction.
The moment you update your site, the new materials really are on the server. But in the visitor’s local warehouse sit old materials whose best-before dates haven’t run out yet. As we saw in §3, the browser doesn’t even ask the server about anything within its date ── which means it never gets a chance to notice the new files exist, and keeps serving the old ones.
What's happening during "I updated it but nothing changed"
server local warehouse screen
[new files] ×── [old files] ──> still the old page
△ within date
they exist "still fine to reuse" nothing is broken
so nobody asks
That is the whole mystery. No bug, no breakage ── the old page persists precisely because everyone followed the rules. It is the unavoidable flip side of the decision that buys the speed: “within the date, don’t ask.”
4-2. Why It Looks Fixed for You but Not for Everyone Else
This is the part that confuses site owners the most. On your screen, clearing the cache fixed it. And yet customers keep writing in: “it still shows the old version.”
The explanation is simple: every visitor has a warehouse of their own. What you emptied was your warehouse, and only yours; your customers’ warehouses keep their old materials until the labels expire. You can clean your own shelf ── you cannot reach anyone else’s (what the site itself can do is covered at the end of §5).
4-3. There Is More Than One Warehouse ── Where Is the Stale Copy?
Now to collect the thread we left in §2: between you and the materials there can be several tiers of warehouses. Your browser’s warehouse, your company network’s shared warehouse, the delivery network’s (CDN’s) warehouses, and the phone-book notes (DNS) ── which tier the stale copy sits in decides who can actually fix it. The only one you control is your own.
When “I cleared my cache but it’s still old,” the stale copy usually isn’t in your warehouse at all ── it’s in an intermediate warehouse (your office’s shared one, or the delivery network’s) or in the phone-book notes (DNS). Cleaning your own shelf a hundred times won’t empty a warehouse along the way. Right after a site migration, suspect the DNS notes waiting to expire (→ the “propagation” story in our DNS article).
5. How to Fix It, and How to Live with It ── Don’t Wipe Everything First
5-1. Try the Lightest Fix First
When a page “won’t update,” jumping straight to a full cache clear is actually the wasteful move. The rule of thumb is three steps, smallest impact first.
| Step | Move | What it does | Impact |
|---|---|---|---|
| 1 | Hard reload (Windows: Ctrl+F5 / Mac: Cmd+Shift+R) | Orders a re-fetch, ignoring the labels, for this page’s materials only | This page only. Practically no side effects |
| 2 | Open the page in a private/incognito window | Tests with an empty warehouse ── if it looks right there, your warehouse is confirmed as the culprit | Diagnosis only. Deletes nothing |
| 3 | Clear the cache | Empties the warehouse for every site | Last resort. Everything loads slower for a while |
Step 2 is quietly the important one. If the page is still old even in a private window, your warehouse is not the problem (suspect the intermediate warehouses from §4-3 ── or the possibility that the update never actually went live). Diagnose first, and you’ll never empty every shelf for nothing.
5-2. Clearing the Cache Does Not Log You Out
The most common reason people hesitate is “won’t it log me out of everything?” ── and here you can relax. As we saw in §1-3, the cache (copies of goods) and cookies (your membership cards) live in separate drawers. Clearing only the cache leaves your logins intact.
The catch: the browser’s delete dialog usually lists a “cookies too” checkbox right next to it, and ticking that one will, of course, log you out. The dialog’s entries map onto three separate drawers ── copies of goods (cache), membership cards (cookies), and notes of the places you’ve been (history). Once you see that you’re choosing which drawer to empty, there’s nothing scary about it (FAQ Q5).
Clearing the cache has exactly one downside: for a while, every site is back to a “first visit” and loads slower. Nothing breaks.
5-3. Half a Step for Site Builders ── Delivering Updates Without the Wait
To finish, half a step into the site builder’s side. Since you can’t go around emptying visitors’ warehouses, sites that need updates delivered reliably use this trick: rename the material itself, and ship it as a different item. Turn logo.png into logo-v2.png, and no visitor’s warehouse holds a copy of that name ── a fetch is guaranteed. (This is called cache busting.) A site that never suffers from “my update isn’t showing” is something you can build by design.
Summary ── the 4-Line Essence
- The cache is a local warehouse: copies of materials fetched once get reused, skipping the fetch ── the very reason “the second time is faster”
- Every package has a best-before label: within the date, the server isn’t even asked (fastest). After it, a stock-check call ── “still good” settles it in one line
- The incident is a stale copy within its date: the new materials are already on the server, but a warehouse within its date never asks ── nothing is broken, yet the page stays old
- Fix with the lightest move first: hard reload → private window to diagnose → clear. Clearing doesn’t log you out (membership cards live in another drawer)
And with that, the set is complete: the box (HTTPS), the membership card (cookies), and the warehouse (cache). To re-read from the full picture of a request, head to the series overview.
FAQ
Q1. Does clearing the cache log me out? How is it different from cookies?
A. Clearing only the cache does not log you out. The cache is “copies of materials (images and such) you’ve already received”; what keeps you logged in is the cookie (your membership card) ── a separate drawer (→ our cookie article). You only get logged out if you also tick cookies in the delete dialog. The full cost of clearing the cache is “pages load slower for a while” ── nothing breaks.
Q2. I cleared my cache and it’s still old. Now what?
A. That’s the sign the stale copy lives somewhere other than your warehouse. Three candidates: ① a shared warehouse on your office network or similar (wait it out, or ask the network admin), ② the site’s own or the delivery network’s (CDN’s) warehouse (only the site operator can purge it), ③ the phone-book notes ── the DNS cache (typical right after a site migration; → the Tip in our DNS article). If a private window still shows the old page, it’s almost certainly one of these. Comparing the page over mobile data vs. Wi-Fi helps split ① from ②.
Q3. Should I clear my cache regularly?
A. No ── it’s unnecessary. The warehouse manages itself by the best-before labels: expired goods get replaced on their own, and when space runs low, the oldest items are discarded automatically. Clearing it on a schedule only sends every site back to a “first visit” and slows things down each time. Reserve clearing for one situation: diagnosing a display problem.
Q4. Does the same thing happen on phones?
A. Yes ── the mechanism is identical, and your phone’s browser has a warehouse too. One thing worth knowing: the browser that opens inside an app (when you tap a link in a social app, say) keeps a warehouse separate from your regular browser’s. “It’s fixed in Safari but still old from the app” happens because those are two different warehouses.
Q5. In the delete dialog, what’s the difference between “cache,” “cookies,” and “history”?
A. Three separate drawers. The cache is copies of materials (deleting it only slows things down); cookies are membership cards (deleting them logs you out and resets site settings); history is the notes of where you’ve been (deleting it removes past visits from your address-bar suggestions and the like). When “a site looks wrong,” the relevant drawer is basically the cache alone ── so the safe habit is to empty only the drawer that matches your goal.
Leave a Reply