I find it odd to call it a bait and switch when the first thing in the article is an outline.
> It is about "network" vs "the (usually antiquated) file-backed database your browser calls a cache."
It's actually nothing to do with the design of the cache itself as far as I can tell. If you finish reading the article you'll see that it's about a throttling behavior that interacts poorly with the common optimization advice for HTTP 1.1+, exposed by caching.
> The latter is kind of self-evident: the browser cache is there to save bandwidth, not to be faster.
I don't think that's something you can just state definitively. I suspect most people do in fact view the cache as an optimization for latency. Especially since right at the start of the article, the first sentence, the "race the cache" optimization is introduced - an optimization that is clearly for latency and not bandwidth purposes.
Memcached exists for two reasons: Popular languages that hit inflection points when in-memory caches exceeded a certain size, and network cards becoming lower latency than SATA hard drives.
The latter is a well known and documented phenomenon. The moment popular drives are consistently faster than network again, expect to see a bunch of people writing articles about using local or disk cache, recycling old arguments from two decades ago.
Agree with GP that this is getting pretty far off the article, but also--I think remote caches in datacenters are sometimes as much about making the cache shared as about the storage latency.
If you have a lot of boxes running your application, sometimes it's nice to be able to do an expensive thing once per expiry period across the cluster, not once per expiry per app server. Or sometimes you want a cheap simple way to invalidate or write a new value for the full cluster.
The throughput and latency of SSDs does make them a workable cache medium for some uses, with much lower cost/GB than RAM, but that can be independent of the local/remote choice.
When I have worked on distributed systems, there are often several layers of caches that have nothing to do with latency: the point of the cache is to reduce load on your backend. Often, these caches are designed with the principle that they should not hurt any metric (ie a well-designed cache in a distributed system should not have worse latency than the backend). This, in turn, improves average latency and systemic throughput, and lets you serve more QPS for less money.
CPU caches are such a common thing to think about now that we have associated the word "cache" with latency improvements, since that is one of the most obvious benefits of CPU caches. It is not a required feature of caches in general, though.
The browser cache was built for a time when bandwidth was expensive, often paid per byte, the WAN had high latency, and disk was cheap (but slow). I don't know exactly when the browser cache was invented, but it was exempted from the DMCA in 1998. Today, bandwidth is cheap and internet latency is a lot lower than it used to be. From first principles, it makes sense that the browser cache, designed to save you bandwidth, does not help your website's latency.
Edit: In light of the changes in the characteristics of computers and the web, this article seems to mainly be an argument for disabling caching on high-bandwidth links on the browser side, rather than suggesting "performance optimizations" that might silently cost your customers on low-bandwidth links money.
Cache is "slow" because the number of ongoing requests-- including to cache! --are throttled by the browser. I.e the cache isn't slow, but reading it is waited upon and the network request might be ahead in the queue.
The first three paragraphs you wrote are all very easily shown to be irrelevant. Again, the very first sentence of the post shows that the cache is designed to improve latency.
And as the article points out, the cache is in fact lower latency and does improve latency for a single request. The issue is with throttling.
The article is absolutely not suggesting disabling caching, nor does any information in the article indicate that that would be a good idea. Even with the issue pointed out by the article the cache is still lower latency for the majority of requests.
The title doesn't necessarily imply it's general. For one, the first word is "When". If the title was instead "Network is faster than browser cache" you'd have more of a point.
> It is about "network" vs "the (usually antiquated) file-backed database your browser calls a cache."
It's actually nothing to do with the design of the cache itself as far as I can tell. If you finish reading the article you'll see that it's about a throttling behavior that interacts poorly with the common optimization advice for HTTP 1.1+, exposed by caching.
> The latter is kind of self-evident: the browser cache is there to save bandwidth, not to be faster.
I don't think that's something you can just state definitively. I suspect most people do in fact view the cache as an optimization for latency. Especially since right at the start of the article, the first sentence, the "race the cache" optimization is introduced - an optimization that is clearly for latency and not bandwidth purposes.