What is caching?
Useful first: HTTP · optional, not a requirement
Choose your depth
Stay with the essentials, or look closer.
YOUR GOALUnderstand how reusing something can save repeated work.
Keep a useful copy close by.
The recipe on the kitchen counter
You find a recipe in a big cookbook and keep a copy on the counter. Next time, you can use the copy instead of searching again. A cache works on the same idea: save something useful so it can be reused.
Your browser might save a website’s logo. When you open another page with that logo, the browser may use its copy instead of downloading the image again.
[1]Copies need rules
If someone changes the recipe, your copy may be out of date. The same can happen to a saved logo or page. A browser follows rules that tell it when it can reuse a copy and when it needs to check for an update.
Caches appear in many parts of computing. Here, we are looking at the copies used when loading things from the web.
[1]Caching reuses a saved result instead of repeating all the work.
A cached copy is always the latest version.
A saved copy may need to be checked or replaced before it can be reused.
Show the explanation
It can avoid downloading the same image again. Reusing a permitted saved copy avoids another image download. Saving one image does not keep it permanently up to date or make the whole site work offline.
Progress is saved only in this browser.
This is the last topic in the starting path. Revisit any idea at a different depth.
YOUR GOALTell a fresh cached response apart from a validated response.
Save, reuse, or check again.
A cache hit or a cache miss
If an appropriate stored response can satisfy a request, that is a cache hit. Otherwise, the request needs more work, often a network fetch. A browser has a private cache; a shared cache can serve multiple users.
[1]Freshness is one part of the decision
A fresh response is still within its freshness lifetime. That does not prove the original has stayed unchanged, and it does not automatically permit reuse: the request must match and other rules may require a check first.
A stale response is past that lifetime. It may need checking or replacement; some policies explicitly allow stale copies to be used.
[2]Ask whether it changed
A server can send an ETag, a label for the version it returned. Later, the browser can send that label back to ask whether its saved version is still valid. This check is called validation.
A 304 Not Modified reply lets the browser reuse the saved content after updating its cache information. The check still uses the network, but the content does not need to be sent again.
A cache checks both freshness and reuse rules; validation can confirm that a saved version is still usable.
Every repeat visit downloads the full page and every asset again.
Freshness rules and conditional requests can reduce repeated transfers.
Show the explanation
The need to send the stored response body again. 304 saves retransmitting the body, not the validation request or its reply. Later reuse still depends on the cache rules and the response’s age.
Progress is saved only in this browser.
This is the last topic in the starting path. Revisit any idea at a different depth.
YOUR GOALExplain freshness, validation, and the no-cache / no-store distinction.
Read the policy, not just the word “cache.”
A small policy with important meaning
Cache-Control: max-age=60
ETag: "revision-7"The freshness lifetime is 60 seconds. If the calculated current age is 20 seconds, 40 seconds of freshness remain; receiving a cached response does not restart the full minute.
When a check is needed, the browser can send If-None-Match: "revision-7". A 304 Not Modified reply supports reusing that saved body; a changed version can arrive in a new 200 OK response.
Two directives that are not synonyms
Used without a list of header fields, Cache-Control: no-cache allows storage but requires successful validation before reuse, even while the copy is fresh. Cache-Control: no-store tells an HTTP cache not to retain the response for reuse.
These are response policies, not commands to erase every previous copy. Browser history, application storage, and access control need separate consideration.
[1] [2]Match the policy to how content changes
Suppose an illustration is named /assets/map.a1b2.svg, with the suffix derived from its content. An edit produces a new file, /assets/map.c3d4.svg, and the page points to that new URL. Each unchanged file can have a long cache lifetime.
The article at /topics/dns/ keeps its URL as its text changes. A policy such as no-cache with an ETag lets it be stored while requiring a check before reuse. A long lifetime without validation could leave readers seeing an older article.
Personal content changes the problem
A shared cache serves multiple people. The plain private response directive prevents shared-cache storage while allowing a user’s own cache to store the response when other rules permit. It does not decide who may access the resource or encrypt the content.
Choose what can be stored, when it can be reused, and whether it may be shared.
no-cache means the response cannot be stored.
Plain no-cache allows storage but requires a successful check before reuse. Plain no-store prohibits retaining the response for later reuse.
Show the explanation
no-store no-store instructs compliant HTTP caches not to store the response. It is not a universal deletion command.
Progress is saved only in this browser.
This is the last topic in the starting path. Revisit any idea at a different depth.
Keep asking. Check the details.
Source-linked, AI-assisted draft. Human editorial review is still pending; this page is not presented as expert-reviewed.
How explanations are prepared