6 ms·

> 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]. Wha

by nimrody 10y ago

> 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)

jandrese 10y ago
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.
- user5994461 10y ago
  To give a hint to the cache manager about when to remove the file from its storage ;)
- idunno246 10y ago
  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.
  - paulddraper 10y ago
    It ignores it on refresh before the page load event. It respects it otherwise.
user5994461 10y ago
> 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
- DivineTraube 10y ago
  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.
- bzbarsky 10y ago
  > 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.
paulddraper 10y ago
This "always revalidate" behavior only happens on refresh. Normal navigation does not trigger it.

by nimrody 10y ago

jandrese 10y ago

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.

user5994461 10y ago
To give a hint to the cache manager about when to remove the file from its storage ;)
idunno246 10y ago
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.
- paulddraper 10y ago
  It ignores it on refresh before the page load event. It respects it otherwise.

user5994461 10y ago

> 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

DivineTraube 10y ago
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.
bzbarsky 10y ago
> 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.

paulddraper 10y ago

This "always revalidate" behavior only happens on refresh. Normal navigation does not trigger it.