Comment by user5994461 | Hacker News Reader

Comment by user5994461 | Hacker News Reader

> Furthermore, browser caching is highly effective and should always be used. It fits in all three optimization categories because cached resources do not have to be loaded from the server in the first place.

That is incorrect.

The browser issues requests for all cachable content with a last-modified-date [or similar special metadata], the webserver replies with a 304-not-modified + empty body, if the file was not updated.

There are still HTTP requests sent, there is still network latency, there is still server processing involved. [Worst case scenario: For tiny JS/css/icon files, the latency might dominate everything and nullify the benefits of caching].

It gets more complex: Since a few years ago, Firefox stopped issuing HTTP requests ENTIRELY for some cached content. It speeds the load time but it causes caching issues.

Last I checked, chrome and IE didn't adopt this behavior yet. That may or may not chance in the (near?) future.

P.S. I felt like being pedantic about caching tonight. Otherwise, a nice article =)

You're right that browser caching has a few tricky parts, which is why we do a some things differently.

What you describe is an HTTP revalidation (If-None-Match, If-Modified-Since) which the browser triggers in two cases:

-if the TTL defined in the Cache Control header has expired

-or if the user hits F5

In the normal case where a user revisits a site, the browser takes all the cached resources without doing a revalidation and that is the case one should optimize for.

The cases you seemed to have in mind is explicit refreshes (F5), expired cache entries, or servers that respond with a max-age=0 header (which is useful in many situations).

The most difficult part when caching dynamic data is purging stale content from browser caches. Because if the TTL is too high and the content changes ealier, users will see stale cached data. At Baqend we solve this problem by piggybacking a Bloom filter of potentially stale URLs to the client [1]. The client checks the Bloom filter to determine whether to do a revalidation or use the cache. In order for the Bloom filter to remain small, we have a learning TTL Estimator that calculates TTLs by approximating the expected time to the next write.

[1] https://medium.baqend.com/announcing-availability-of-baqends...

> There are still requests sent, there is still network latency. [In the case of small JS/css/icon files, the latency can be as much as the transfer time].

What? When the "Expires" header indicates the item is still valid the browser should use the cached object without making any requests.

Some servers (Rails for example) just serve assets with "Expires" set to some distant future time. When they want to expire these files, they simply change the name (hence the long numeric suffix appended to js/css/etc. files)

Yeah, I was wondering why I bother to set the expires header if the browser is going to ignore it and check every time anyway.

To give a hint to the cache manager about when to remove the file from its storage ;)

It doesnt ignore it. In chrome, if you keep the network tab in dev tools open, you will see "From disk/memory cache" in the size column with a status of 200 when it comes from local cache.

It ignores it on refresh before the page load event. It respects it otherwise.

> the browser should use the cached object without making any requests.

That's a common (mis)assumption, but that's not how it works in practise. Sorry ^^

I cannot comment on what was the intended behavior when HTTP caching and headers were first designed, a very long time ago.

It seems to me, that is was "request everytime + get 304 if not modified, thus save the file transfer time". That's how most implementations work in my experience.

Historically, transfer duration was way more problematic than latency. It's only recently that there are pages with hundreds of dependencies.

---

Rails and webservers: They MUST change the filename or the application will be fucked because of caching issues, mostly because of Firefox :D

All major browsers do respect the TTL if one is set. So it does save many requests. If it's not possible to the the TTL because the content might change at any time it is still useful to a caching header with a TTL of 0. Otherwise the browser will perform heuristic caching and compute a (often imprecise) estimation based on the last-modified header.

> but that's not how it works in practise

As someone who has actually worked on a browser's network stack, I can assure that it _is_ how it works in practice.

This "always revalidate" behavior only happens on refresh.

Normal navigation does not trigger it.

304, not 204.

There have been proposals for "immutable" or similar additions to Cache-Control that would not have the validation.

Reply on news.ycombinator.com