Hacker News Reader

Comment by michaelkscott | Hacker News Reader

Yes, this. It will also make the pages render faster. On the homepage alone there are 30 instances of grayarrow.gif.

The image is only loaded once and does not block anything (in fact it's loaded in parallel with — and the same size as — the orange Y logo at the top-left, and the tracking gif).

Furthermore the images on YC have extremely low dynamicity and size, so there's little chance they'll be evicted from the browser's cache (short of a manual cache clear), so their 100 bytes will only be loaded once the first time ever you visit YC.

So no, it won't make pages render faster overall.

On the other hand, it will make pages look better on zoomed or high-DPI displays.

The image is only downloaded once, but each page you load re-requests it. If your account has enough karma to downvote posts, you're requesting two array gifs per page view.

There's no Expires header being set, so your browser is not caching these images. A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.

> There's no Expires header being set, so your browser is not caching these images.

That is not in the slightest correct.

It has both a Last-Modified and an Etag so it's definitely cached.

> A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.

Also incorrect. The roundtrip is done once per session. A session is not well defined, but it's basically till you close the browser or till you click reload. Merely clicking on other stories will not trigger another roundtrip.

(Also pressing enter on the url line will not trigger a roundtrip, but reload will. This is important sometimes.)

> It has both a Last-Modified and an Etag so it's definitely cached.

Even without that, it'd still be cached: pretty much all browsers will cache things by default.

Last-Modified and Etag only come into play when the internal cache expires (this expiration time can be configured with the HTTP/1.0 Expires header or the HTTP/1.1 Cache-Control: max-age attribute, but the timeout does not default to "don't cache anything").

> The image is only downloaded once, but each page you load re-requests it.

No, it most definitely does not does not.

> There's no Expires header being set, so your browser is not caching these images.

You're out of your mind, of course the browser caches it, the browser caches everything it can by default: http://i.imgur.com/hrmIs.png

> A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.

That is not even remotely close to what happens in the actual reality we're part of.

If you are really worried about performance (and the operators of of this forum should be) then there are more important things that need to be fixed besides just adding caching headers to an images (which is still a good idea). https://developers.google.com/speed/pagespeed/insights#url=h...

On the other other hand, it takes 83 bytes of HTML to represent the image tag which requests that 100 bytes of image. It only takes a couple of bytes to represent the Unicode character.

Sure, that's a valid point. However considering the HN home page is sent as raw HTML right now, there'd be much better savings by enabling gzip, reducing the home page's over-the-wire size from ~22k to ~5k. Compared to ~2.5k (from 22k to 20k) of savings from removing all 30 instances of the image tag.

right, because a page made on tables feels like needing micro-optimization for the arrow

/a></u></font></td></tr></table></td></tr><tr><td><table border=0><tr><td><img

Reply on news.ycombinator.com