How Does Caching Work?

When you load a webpage for the first time, your browser downloads dozens of files from the internet: HTML, images, scripts, stylesheets. The process takes a second or two. When you load the same page an hour later, it appears almost instantly. Nothing has changed about the internet. What has changed is where the data sits.

That instant load is the work of caching: a system of temporary storage that keeps copies of frequently used data close to where it is needed, so the computer does not have to travel as far to fetch it again.

The short answer

Caching is the practice of storing a copy of data in a faster or more convenient location so it can be retrieved without re-fetching from the original source. Caches exist at almost every level of computing, from the tiny memory inside a CPU to the browser on your phone to the servers run by companies like Cloudflare and Akamai. Each layer caches data that is likely to be needed again, trading a small amount of storage space for a large reduction in access time. The result is that the modern internet feels fast, even when the underlying networks have not changed at all.

The full picture

Why caching exists: the tyranny of distance

Every time your computer requests data from the internet, it travels through cables, switches, and routers to reach a server somewhere far away. That server processes the request and sends the data back along the same path. Light through fiber moves at about 200,000 kilometers per second, which sounds fast until you realize that a server on another continent is 10,000 kilometers away. A single round trip across the Atlantic can take 70 milliseconds.

Now multiply that by 50, the number of files a typical webpage loads. A page with no caching could require 50 separate round trips to render. With caching, many of those files come from a location within milliseconds of your computer, not thousands of kilometers away.

The fundamental insight behind caching is this: most requests to any system are for the same data, over and over. A news article gets viewed 10,000 times. A profile picture is loaded by everyone who messages that person. An application icon does not change for months. Re-fetching the same data from the original source every time is expensive. Caching eliminates that waste.

The layers of the cache stack

Caching is not a single technology. It is a hierarchy of systems, each operating at a different distance from the CPU and serving a different purpose.

CPU cache is the closest to the processor. Modern CPUs have multiple levels of cache: L1, L2, and L3. L1 is the smallest and fastest, often just 64 kilobytes, embedded directly in the CPU core. L2 and L3 are larger but slightly slower. When a CPU needs to read from memory, it first checks whether that data is already in its local cache. If it is, the CPU avoids a trip to main memory entirely, saving 100 or more clock cycles per access. Computer memory is covered in detail in another article.

The operating system cache sits between the CPU and the disk. When an application reads a file, the OS keeps a copy in free memory. Subsequent reads of the same file are served from RAM instead of the disk, which is 10 to 100 times slower. This cache is completely invisible to applications. The program asks for data, and the OS decides whether to serve it from the cache or the disk.

The disk cache lives inside hard drives and solid-state drives themselves. A modern NVMe SSD has a small amount of very fast memory dedicated to caching reads and buffering writes. This is separate from the OS-level cache and operates autonomously inside the drive.

Browser caching is what most people interact with directly. When your browser downloads a file, it stores it locally with a label saying when it can use that copy again. This label is called the TTL, or time-to-live. If you revisit a page before the TTL expires, the browser uses the local copy instead of asking the server for it again. This is why the second load of any webpage is almost always faster than the first.

CDN caching distributes content across hundreds or thousands of servers worldwide. When you request a file from a CDN, the request is routed to the server physically closest to you. If that server has the file in its cache, it serves it immediately. If not, it fetches it from the origin server, caches it, and then serves it to you. Major streaming services like Netflix use CDN caching to serve hundreds of millions of hours of video daily without overwhelming any single server.

Cache hits and cache misses

Every cache system uses the same vocabulary. A cache hit occurs when the data being requested is found in the cache. A cache miss occurs when it is not, and the system must fetch from the original, slower source.

The hit rate of a cache, expressed as the percentage of requests served from cache, is the primary measure of cache effectiveness. A 90% hit rate means 9 out of 10 requests never touch the original source. Optimizing for higher hit rates is a core engineering concern for any system that deals with large volumes of repeated requests.

When a cache is full and new data needs to be stored, the cache must decide what to remove. This is called eviction. Common eviction strategies include LRU (least recently used), which throws out the data that has not been accessed in the longest time, and FIFO (first in, first out), which removes the oldest entry. CPUs and databases use LRU because recently used data is statistically more likely to be needed again soon.

HTTP caching headers: the rulebook for the web

When your browser caches a webpage, it does not make this decision alone. The web server sends instructions with every response, telling the browser and any intermediate caches how long they may keep a copy. These instructions are HTTP headers.

The Cache-Control header is the most important. A response with Cache-Control: max-age=3600 tells every cache in the chain to keep that data for 3600 seconds, or one hour. During that hour, any request for that URL can be served from the cache without contacting the origin server.

ETag and Last-Modified headers provide a more conditional form of caching. Instead of trusting a fixed timer, the server sends a tag or timestamp with the data. On subsequent requests, the browser asks the server whether the cached version is still valid. If the server says yes, it sends a tiny 304 Not Modified response instead of re-sending the entire file, saving the full download.

For static assets like images, CSS, and JavaScript, developers typically set long cache lifetimes, sometimes a year. This is why updating a website sometimes does not immediately show changes for all users: their browsers are serving old cached copies. The standard workaround is cache busting: changing the filename or URL of updated assets so browsers treat them as new requests.

DNS caching: the internet’s address book

DNS caching is one of the most consequential forms of caching, yet most users never think about it. The Domain Name System translates human-readable addresses like google.com into IP addresses like 142.250.80.46. Without caching, every website request would first require a DNS lookup, adding latency before a single byte of actual content was fetched.

Your router, your operating system, and your ISP all maintain DNS caches. A typical ISP DNS cache holds entries for as long as the domain’s TTL specifies, often several hours. When you type a URL into your browser, the DNS lookup might be answered in under a millisecond because the result was already cached somewhere nearby. The DNS system is explained in detail in another article.

Memory caches and key-value stores

For applications that need to store large amounts of transient data, traditional disk-backed databases are too slow. This gave rise to in-memory key-value stores, the most widely used being Redis and Memcached.

These systems keep entire databases in RAM. A social media application might store each user’s session, recent posts, and notification count in Redis, so every page load avoids a slow database query. According to a 2024 Redis survey, Redis is used in some capacity by the majority of the Fortune 100, typically for session caching, real-time analytics, or message queues.

The tradeoff is persistence. RAM is volatile. If the power goes out, everything in an in-memory cache disappears. Most Redis deployments use persistence mechanisms like periodic snapshots or write-ahead logs to recover state after a crash, but the cache itself does not guarantee durability the way a disk-based database does.

Why it matters

Caching is why the internet feels fast, but its importance goes beyond convenience. For large-scale services, caching is a primary cost-control mechanism. A single CDN cache hit means one fewer request reaching an origin server. For a service handling millions of requests per minute, the difference between a 90% and a 95% cache hit rate can mean eliminating thousands of server instances and millions of dollars in infrastructure costs annually. Akamai’s 2024 State of the Internet report found that e-commerce sites with sub-second load times saw conversion rates 3x higher than slower competitors, much of that advantage attributable to aggressive caching at the network edge.

For developers, understanding cache behavior is essential for building reliable systems. Users who see outdated data after a site update, or who are locked out of an application after clearing cookies, are experiencing cache-related failures. Knowing which cache layer is responsible and how to clear or invalidate it is a fundamental debugging skill.

For users, the same principles apply at a personal scale. Your browser cache, if left unchecked, can accumulate gigabytes of stored images and scripts over months. Periodically clearing it is not just a troubleshooting step for broken websites. It reclaims real storage space on your device and prevents old versions of pages from loading when you want fresh content.

Common misconceptions

“Clearing your cache fixes most problems.” It helps in some cases, but not as many as people assume. If the problem is caused by a server-side change, a cached error page, or an issue with a network-level cache operated by your ISP or corporate firewall, your local browser cache is not the culprit. Clearing it is the first step in a troubleshooting process, not the last.

“Caching saves bandwidth, so it is mainly about speed.” While caching does reduce data transfer, its primary performance benefit is latency reduction, not bandwidth savings. Serving a file from a CDN cache in the same city as the user might save 500 kilobytes of bandwidth, but the real benefit is avoiding the 100 milliseconds it would take to fetch that file from an origin server across the country. The bandwidth difference between a cached and uncached load is often negligible; the time difference is not.

“Once data is cached, it stays cached until you clear it.” Caches actively manage their storage. They set expiration times, evict old data when space runs out, and respect instructions from servers. A CDN cache might hold a file for 24 hours and then automatically discard it, even if you never manually clear anything. Browser caches typically enforce size limits, evicting the least recently used items when storage exceeds a threshold.

Key terms

Cache hit: A request that is served from cached data instead of the original source.

Cache miss: A request for which no cached copy exists, requiring a fetch from the original source.

TTL (time-to-live): The duration a cached item is considered valid before the cache must re-fetch from the origin.

Eviction: The process by which a cache removes old entries to make room for new ones, typically following a least-recently-used strategy.

Cache busting: A technique where updated files are given new URLs so that caches treat them as fresh requests, bypassing old cached copies.

Origin server: The original source of data, as opposed to any intermediate cache that stores a copy of it.

CDN (Content Delivery Network): A geographically distributed network of servers that caches content close to end users to reduce latency and origin load.