HTTP Cache vs localStorage

Client‑side caching is one of the highest‑leverage ways to speed up modern web apps. Two mechanisms that often come up are HTTP cache and localStorage. Both persist data in the browser, but they behave very differently under the hood.

Over the past 15 years since localStorage was introduced, we’ve seen various usage patterns emerge. It’s always interesting to observe the difference between an API’s intended purpose and how developers actually use it. This has happened with localStorage too, it became used as a caching mechanism. Most commonly for fonts, does anyone remember the localFont project? Smashing Magazine and The Guardian were among the first to use this technique. I see these misuses of APIs as helpful in identifying gaps in other APIs or browsers themselves. This pushed the browser vendors to improve HTTP cache.

Today, there is a push to discourage using localStorage for two main reasons:

1. For storing secure tokens (a separate topic)
2. For caching

This post covers the second case, is it truly black and white? Spoiler: it’s not.

Let’s start by understanding the HTTP cache and some hidden implications it brings.

HTTP cache is browser‑managed storage for network resources. The focus here is on browser-managed as that brings a lot of benefits you don’t have to think about:

• Asynchronous: reads and writes happen off the main thread.
• Integrated with HTTP semantics: Cache-Control, Expires, ETag, revalidation, and standard freshness rules.
• Managed eviction: the browser expires and evicts items automatically.

The benefits above shift the responsibility of cache busting to server and browser and not the actual client, which is great.

On the other hand, the localStorage doesn’t come with any of these benefits:

• Synchronous: every read and write blocks the main thread.
• String‑only: binary data must be encoded (often base64), which increases size and CPU cost.
• No eviction policy: when you hit quota, writes fail.

Due to synchronous behavior browser vendors limited the storage size to 5MB but Chrome has bumped this up in 2023 to 10MB. Firefox has it still at 5MB.

So, ok this clearly means use only HTTP cache for caching, simple, right? It is never that simple.

Of course, this is a performance-oriented blog so we must talk about performance. HTTP cache comes with two implications that we will deep dive into.

When you request a resource in the browser, it calls into the HttpCache to create an HttpCache::Transaction. The cache checks for an entry matching the URL and NetworkIsolationKey. If no entry exists, the transaction calls HttpNetworkLayer to create a network transaction. (Low-level browser networking details are beyond this post’s scope.) The HttpCache::Transaction determines if a request can be served from cache, or if it needs revalidation, it sends a conditional request over the network.

This means even cached requests see noticeable queuing time. To demonstrate, I built a few stress tests.

Below you can see a HAR table of what happens when you request 100 small images from cache inside Chromium.

You’ll notice that blocking time grows with each request. For the last request, it waits 105 ms to return a 2ms response.

The actual HTTP cache is stored on disk. Browsers use a dedicated I/O thread to prevent rendering from blocking the UI. However, they don’t fully use asynchronous I/O—not all operations can be async. For example, opening and closing files are synchronous, making them susceptible to significant delays under heavy I/O load.

The disk cache wasn’t visible in the first table because the files were very small. With 1MB+ files, the results change significantly.

If you look at Table 2, you see different results. Notice rows like id=img15: a significant amount of time (~154 ms) is spent downloading. Compare to id=img48 (~8 ms)—same file size. The culprit: hitting the disk cache bottleneck.

So, request-heavy applications face a disadvantage with HTTP cache due to this disk bottleneck.

Web development is unique because it must run across every OS and browser. As a result, behavior can vary between browsers, and even the same browser can behave differently across operating systems because it relies on OS‑provided APIs.

I tested the HTTP cache across multiple browsers and OSes; see the table below.

Test with two configurations:

• 1KB images (1,000 images, 25 iterations)
• 5MB images (100 images, 10 iterations)

For each browser and configuration, the cache is primed once, the test is run 5 times, and the best run is selected based on the lowest P95 latency. All systems are using an SSD.

Key Findings:

• Small files (1KB): WebKit generally performs best on macOS, while Chromium leads on Windows and Ubuntu
• Large files (5MB): Firefox dramatically outperforms others across all platforms, while Chromium struggles significantly
• Platform variance: The same browser can show 10x+ performance differences across operating systems

Local storage doesn’t have that problem, because it doesn’t pass through the network stack.

If we race localStorage against HTTP cache, loading 100 1kB images from cache, we get:

HTTP cache is slower due to queuing. While the difference here is small, localStorage consistently stays below 1ms. This is consistent across all major browsers and OSes.

Nothing is black and white. There are pros and cons to each approach, and you must choose the right solution for your specific problem.

In my experience, trying to fight the browser is never a good option. Browsers are actually very smart and they do a lot more under the hood than developers realize.

The HTTP cache story is more complex than I’ve shown. I focused on disk cache, which is most common, but browsers also maintain an in-memory cache.

As you can see, this cache is blazing fast, connection timings measured in microseconds (μs). (I’ll explore in a future post how browsers decide what to store where.)

Additionally, caching behavior differs by resource type. Caching JavaScript or WebAssembly is fundamentally different from caching fonts or images, and browsers have optimized accordingly.

I love browsers because they’re constantly improving and changing to adapt according to the user’s needs. Historically, during the HTTP 1 days it was better to send one big file compared to multiple smaller ones. With the introduction of HTTP 2, this changed—now it is preferred to have smaller files compared to bigger ones, but as we saw, this can constrain the browser. Chrome is actually experimenting with different backends and you can change them by going to chrome://flags/#http-cache-custom-backend.

You can try to use SQLite, which is the next experiment that should work better with smaller files. I ran a few benchmarks with 1,000 images, each at 1KB, over 25 iterations:

Always ask: what problem are you solving? If it’s display latency (especially for images), progressive loading often yields better results than repurposing localStorage.

Common approaches:

• Progressive JPEG/PNG
• WebP with progressive behavior or low‑quality first chunks
• Inline tiny placeholders
• Load higher‑resolution versions later

If you got to this part, congratulations and thank you for trying to understand all the little details. You might ask yourself, well none of these solutions look right for me, what are my alternatives? Yes, there are. People that know me know that I love to say, “On the web there are always at least three ways to solve a problem.” Of course IndexedDB is something that pops up, and then the Cache API, the decision just becomes harder.

Because my posts tend to be very technical and deep, I want to keep them focused. Therefore, I plan to cover IndexedDB in upcoming posts.

While localStorage can be faster for serving repeated data, the trade-offs are significant: synchronous access blocks the main thread, storage is capped at 5-10MB, and using it for cache can conflict with legitimate application data. HTTP cache, browser-managed and integrated with HTTP semantics, handles eviction and freshness automatically, but suffers from network stack serialization and disk I/O bottlenecks.

The answer isn’t always one or the other; it depends on your specific problem. For display latency concerns, progressive loading strategies are often better. For raw speed with full control over storage and application needs, localStorage can work. In most cases, though, let the browser do what it does best with HTTP cache, especially its in-memory layer for hot resources.

Choose the tool that solves your actual problem, not the symptom.