Yesterday's perf best-practices are today's HTTP/2 anti-patterns - Velocity 2015 (Santa Clara)

[@igrigorik]

*Yesterday's perf best-practices are today's HTTP/2 anti-patterns...* Video of my Velocity talk from a few weeks back! If you want to quickly scan through the slides, see: bit.ly/http2-opt.

[@tiltmaniac]

Go tell 'em Ilya!

[@AbhishekTyagi]

That was great insight into http2. I have been thinking about adoption but was keeping at bay. This just made it a whole lot interesting.

[@achieverism]

Superb explanation @Ilya. It couldn't be perfectly explained and compared with HTTP/1.*. Great & Thanks a lot!

[@srcspider]

26:00 the example is valid for css and images since there is no incremental loading strategy (with out migrating the css to javascript via loading or natively), but in the case of javascript using webpack you can have essentially a entry point files per page type then have partial files generated automatically for you that will add to the page the minimum required code for getting the page to work; in addition to still be a perfect gzip target. The idea that "if you just change one file, you now don't have to hit everything" sounds good but in practice we care a lot more for initial cold load so its not really a great benefit. Also, the code does not change on a minute by minute basis (generally) for this to be an issue. And if it does change often just devide and conquer. Even today it's better to have a Some_Page.js and a Common_Parts.js then to have a single app.js. Also, I've yet to see a http2 spec that details how exactly its able to gzip all the files togheter. Everything I've read basically has been a raise your hands in the air, give up, and just gzip individually. Many javascript libraries today are extremely small, so small that individually gziping it compared to gziping the whole thing is just a huge loss; some to the point where its so small (under 1kb) that gzipping makes them bigger. For some use cases this might be perfectly fine solution but not really a general purpose one. Another big issue is manifests. The presentation says its better to split your js files as if the server can actually send all of them in one fell swoop, but servers are actually dumb and as far as I'm aware ES6 + http2 still requires the client to process dependencies then ask for the next files (eg. home.js might as for input.js then input.js might ask for ui.js which might as for an each and component implementation which in turn might as for some base iterator implementation, etc ...you get the idea). Packaging all in one package avoids the resolution and any sophisticated mechanism that would need to exist on http/server/client to resolve that. And by using something like webpack you get the benefit of still only grabbing the minimum required for the page to function and not some giant monolith.

[@oleksandrlytvyn532]

Hello, interesting, is these advices still actual in 2021, or there are something changed (in term of advices given)?

[@sasinosrce]

@igrigorik Where could I find more info on server push? Graphs if possible to understand it more easy whats going on with the stream and how the PUSH_PROMISE is sent and the HEADERS and DATA frames?

[@hrgwea]

What was the question at 45:00? I can't understand a single word.

[@bruhatube]

How service worker will handle that server pushes? I mean, now we can check each request and watch it's resource, but how it will work if on one request i'll receive multiple resources?

[@igrigorik]

+Филипп Борисов there is no JS-land callback for server push today. The push response is held by the client and is then matched with the JS-initiated request. I do hope that we'll get an API in place to notify apps of incoming server push streams.. at some point in the future.