My big hope for HTTP push was to avoid having to bundle JS. If the server knows which JS files depend on which other JS files, they can be served together individually without there being a performance hit, and you get the benefit of avoiding a build step, easier dynamic loading of code groups and more pleasant browser side debugging.
I’m also disappointed that it never really achieved adoption.
My big hope for HTTP push was to avoid having to bundle JS
HTTP/2 still does request and response multiplexing and stream prioritization, though (along with header compression and the binary protocol). If a web page includes a bunch of separate resources, I believe the server can utilize the same connection, thus still increasing performance over HTTP/1.x. I haven’t messed with front end sites in a while, but I’d be curious to see some benchmarks around HTTP/1.x with a big blob of JS vs. HTTP/2 with separate JS files and with and without push.
Ah yes, I should have said that I was thinking of JS files that refer to other JS files. If they have to come down to the browser before you can request the next one, then that one has to come down to the browser only to discover that it needs another, etc, I would expect that to add up quite quickly.
If you have several that are used for some pages and others not, it doesn’t, because the next file might be cached from having been used by another page.
It does add up if you have several that are always used together, and you may expect that if one is cached, all are cached, and vice versa. IMO this is a stupid situation to get into. It makes some sense for images (which don’t chain to each other), IMO zero for javascript or CSS assets. If they’re always used together, pack them into one asset to begin with.
Good performance is first and foremost a question of designing and implementing such that you don’t create problems that HTTP can make worse.
Well, at least there is an alternative. Maybe even better, as from what I see 103 is easier to implement with caching, as server do not need to know whether client have or have not something in cache already.
So just to clarify this is for serving content and unrelated to Server-Sent Events (SSE)? I thought that HTTP/2 would be able to kill off WebSockets for such use cases.
Yes, HTTP/2 push was never related/similar to the use-case of SSE or WebSockets. In fact, WebSockets are currently being updated to allow them to work inside HTTP/2 frames (which is currently not possible)
My big hope for HTTP push was to avoid having to bundle JS. If the server knows which JS files depend on which other JS files, they can be served together individually without there being a performance hit, and you get the benefit of avoiding a build step, easier dynamic loading of code groups and more pleasant browser side debugging.
I’m also disappointed that it never really achieved adoption.
HTTP/2 still does request and response multiplexing and stream prioritization, though (along with header compression and the binary protocol). If a web page includes a bunch of separate resources, I believe the server can utilize the same connection, thus still increasing performance over HTTP/1.x. I haven’t messed with front end sites in a while, but I’d be curious to see some benchmarks around HTTP/1.x with a big blob of JS vs. HTTP/2 with separate JS files and with and without push.
Ah yes, I should have said that I was thinking of JS files that refer to other JS files. If they have to come down to the browser before you can request the next one, then that one has to come down to the browser only to discover that it needs another, etc, I would expect that to add up quite quickly.
Consider when/whether it adds up:
If you have just one, it doesn’t.
If you have several that are used for some pages and others not, it doesn’t, because the next file might be cached from having been used by another page.
It does add up if you have several that are always used together, and you may expect that if one is cached, all are cached, and vice versa. IMO this is a stupid situation to get into. It makes some sense for images (which don’t chain to each other), IMO zero for javascript or CSS assets. If they’re always used together, pack them into one asset to begin with.
Good performance is first and foremost a question of designing and implementing such that you don’t create problems that HTTP can make worse.
Webpack or something similar would solve this issue, as long as all the JS is served from your domain.
Early Hints looks great. However, I’m failing to see how this is backward compatible with browser that doesn’t support it yet.
Well, at least there is an alternative. Maybe even better, as from what I see 103 is easier to implement with caching, as server do not need to know whether client have or have not something in cache already.
103 doesn’t save RTT, which was the primary motivation for push. Cache digest could handle caching.
So just to clarify this is for serving content and unrelated to Server-Sent Events (SSE)? I thought that HTTP/2 would be able to kill off WebSockets for such use cases.
Yes, HTTP/2 push was never related/similar to the use-case of SSE or WebSockets. In fact, WebSockets are currently being updated to allow them to work inside HTTP/2 frames (which is currently not possible)
Thanks for helping me understand!