web caching

Imagine you keep photocopying the same page from a library book that lives across town. Instead of walking there every time, you keep one copy on your desk. The next time you need it, you just read your copy — far faster, and the library doesn't have to dig out the book again. Web caching is that idea applied to the web: when content is fetched, a copy is kept somewhere closer to the user (in the browser, in a proxy, in a CDN edge server) so that the next request for the same content can be answered from the nearby copy instead of going all the way back to the original server.

Why does this help so much? Two things dominate web latency: distance and round trips. A request to a server on another continent can take a hundred milliseconds or more just for the signal to travel there and back, and a page is usually built from dozens of separate items (HTML, images, scripts, fonts), each potentially its own round trip. A cache short-circuits the long trip. The first fetch is a cache miss (the copy isn't there yet, so it must be fetched and stored — a cache fill); later fetches are cache hits, served instantly from the nearby copy. The art is deciding how long a cached copy stays valid, because content can change.

Why it matters: caching is the single biggest lever for making the web fast and scalable. It cuts latency for users, cuts load and bandwidth cost for the original server (the origin), and lets a small server survive a huge audience. The catch — and the source of most caching bugs — is staleness: a cache can serve an out-of-date copy. So real systems pair caching with rules for freshness (how long a copy may be reused) and validation (cheaply checking whether the stored copy is still current). Caching does not make any single round trip faster; it avoids round trips. Bandwidth and the speed of light are unchanged — you are simply not making the long trip.