Hacker News new | ask | show | jobs
by joshstrange 4123 days ago
Agreed, as someone who has done a significant amount of work to sprite our images and concat our js/css files this title, and most the content, scared me. The only thing I haven't pushed through is different domains for static assets (though I have them cached for a year with a query string as a cache-buster for when we deploy new js/css). None of this, in a HTTP2 context, seems like it would be extremely, or at all for that matter, harmful. Furthermore with our aggressive caching the request only needs to be made a single time (assuming the user hasn't cleared their cache).

I welcome HTTP2 but I'm not too sure on the timeline for rollout and if it will end up being an "IE6"-type thorn in my side. Even if we are split 50-50 between HTTP1 and HTTP2 it sounds like the best approach is keep doing what you are doing... Either way I don't think sprites/concating/minifying is going anywhere anytime soon.

3 comments

I think if there's a significant enough uptake on HTTP/2, we may get to a point where we start feeling that it's not worth optimizing for HTTP/1.1 anymore. Obviously HTTP/1.1 will still just work, but the HTTP/2 approach _can_ potentially work much more elegantly, when all the tooling is in place, and I definitely believe it will be preferable.

I agree that the existing approaches are very much valid though, but I also look forward to not having to concatenate javascript files anymore. We've developed a lot of tooling to work around issues that stem from that, and it doesn't address the problem of needing a varying set of javascript files on a per-page basis easily.

I've said this before and I'm still not certain, but given that all browsers on desktops now auto update, and that browsers on phones and tablets have a short shelf life because those devices are far more disposable, I can't see how we're going to end up in an IE6 scenario.
A few reasons why concatenating CSS and JS might be harmful under HTTP2. Firstly, it means that the code must be downloaded serially. Given that the per-request overhead is minimal for HTTP2, it's more efficient to download the files separately in parallel. Second, in most cases you don't actually depend on all the CSS/JS for the user to start interacting with the page so keeping things separate can mean that the perceived response time is shorter. Finally, separate resources can result in less cache invalidation when assets are changed which could make a big difference for repeat visitors.