3 ms·

Without md5 tagging but with a reasonably configured web server, the browser gets an eTag in the response headers to the first request to load that cover image,

Without md5 tagging but with a reasonably configured web server, the browser gets an eTag in the response headers to the first request to load that cover image, and sends it in the headers to the second request and gets a 304 Not Modified response with an empty body. The size of the cover image is completely moot when comparing a proper Hugo config vs a proper asset pipeline config.

qw 8y ago
The main advantage of a hash is that browsers will download the new version of your CSS/JS on the next page view, while still caching it «forever» If the url stays the same, you never know what version your visitors will get. You might publish a new version, but the user would not see it due to browser caches or proxies.
- benatkin 8y ago
  Caching something forever just doesn't impress me at all, it did when I first heard about the rails pipeline, but what matters to me more is that it's cached through a proxy or CDN, and that eTags prevent large files containing the exact same bytes from being sent repeatedly to the same client.
  - always_good 8y ago
    It impresses me as a user though since ETag still incurs a round trip while "forever" expiration doesn't. There's a night and day difference between ETags and no HTTP request at all. You are likely complacent because you're always on a good connection, since you keep arguing in these comments (even farther down) as if conditional GET requests obsolete other forms of caching. The real benefit of ETags is that they generalize over all content dynamically, but they come at the cost of incurring more requests than expiration caching. I don't see how you could keep arguing here unless you didn't understand that trade-off.
    - rimliu 8y ago
      Another thing to remember: browsers don't fire up unlimited requests, usually you have 6-8 pipes to get your assets through. Even simple if-modified-since will still take space in them, while "eternal caching" will leave them free, i.e. no request will be made.

qw 8y ago

The main advantage of a hash is that browsers will download the new version of your CSS/JS on the next page view, while still caching it «forever» If the url stays the same, you never know what version your visitors will get. You might publish a new version, but the user would not see it due to browser caches or proxies.

benatkin 8y ago
Caching something forever just doesn't impress me at all, it did when I first heard about the rails pipeline, but what matters to me more is that it's cached through a proxy or CDN, and that eTags prevent large files containing the exact same bytes from being sent repeatedly to the same client.
- always_good 8y ago
  It impresses me as a user though since ETag still incurs a round trip while "forever" expiration doesn't. There's a night and day difference between ETags and no HTTP request at all. You are likely complacent because you're always on a good connection, since you keep arguing in these comments (even farther down) as if conditional GET requests obsolete other forms of caching. The real benefit of ETags is that they generalize over all content dynamically, but they come at the cost of incurring more requests than expiration caching. I don't see how you could keep arguing here unless you didn't understand that trade-off.
  - rimliu 8y ago
    Another thing to remember: browsers don't fire up unlimited requests, usually you have 6-8 pipes to get your assets through. Even simple if-modified-since will still take space in them, while "eternal caching" will leave them free, i.e. no request will be made.