The practical benefit is virtually nil because HTTP already has a proven mechanism for caching and preloading.
By the time you visit the second page on a multi-page site, you are likely to have almost all stylesheets, scripts, and common images already cached. This means you will reject almost all of the resource the server tries to push to you. Even on the first page, modern browsers are very quick to identify resources they need to load, both from headers and the early parts of the document. They load those resources concurrently while they are still parsing the document, so they are rarely blocked for a noticeable time.
Meanwhile, single-page sites have evolved to a point where the entire application is contained in one or two heavily optimized, minified scripts. You just load that one script and you're done. Most small images these days are SVG embedded right in the source code, so again, there's little need to push other resources.
The only time a modern website makes you to load a lot of unanticipated resources is when those resources are used for tracking and advertising. They can't be pushed because they live on different origins.
> Meanwhile, single-page sites have evolved to a point where the entire application is contained in one or two heavily optimized, minified scripts. You just load that one script and you're done. Most small images these days are SVG embedded right in the source code, so again, there's little need to push other resources.
This isn’t true of most websites - look at the developer tools traces - because it’s terrible for performance to optimize for the IE6-era browser design. With those kind of bundles, you have to push a ton of content which didn’t change any time one byte of any resource changes. Since HTTP/2 substantially reduced the cost of multiple requests any site which has repeat visitors will benefit enormously from letting the bulk of the content which hadn’t changed be cached and only refetching the few responses which actually need to be updated.
Not saying it's good design, but a huge bundle is the default for a lot of frontend frameworks these days. :(
On the other hand, sites with lots of separate static assets are often split into multiple origins. Images from a CDN, fonts and libraries from another CDN, and API endpoints on a "serverless" platform somewhere else. These sites won't benefit much from having Push enabled, either.
Of course with HTTP/2 it's better to serve as many resources as possible from a single origin. But that doesn't sit well with the recent trend of sprinkling your stuff across buckets and lambdas, duct-taped together with CORS. Good ol' Cache-Control still does most of the heavy lifting there.
Did you have a particular framework in mind? None of the ones I’ve worked with do that by default and I very, very rarely see even close to a single bundle on a website any more. A decade ago it was more common since HTTP/2 hadn’t shipped and IE6 was still a concern but the cache wins are compelling and well known by now.
I don't have much experience fine-tuning the build options, but last time I tried a new project with default settings, React produced 2 large chunks, and Svelte gave me a single .js file.
> Even on the first page, modern browsers are very quick to identify resources they need to load, both from headers and the early parts of the document.
The premise of http2 push is that those resources could be sent before the first round trip even occured - before any link headers or request body is available.
Which is kind of two things - the round trip of network latency and also the backend latency of how long it takes to make the resource.
The solution was to give up on the round trip network latency, but concentrate on backend latency. Which you can do by sending link headers before the resource is finalized, or if you cant even do that, by sending a 103 response.
The new solutions are still leaving some latency on the table. Price to be paid for simplicity.
The other side of that coin, is if you really care about the latency of those resources for clients who dont have them cached, you can just embed them in the html document.
Backend latency should be negligible next to RTT latency though. If RTT is on the order of 100 ms, shaving off 5-10 ms for request processing doesn't help much.
I don't know the history here, but nginx seemed to have a solution (which was removed) to be able to conditionally attach pushes to a location directive based on a cookie, and then set that cookie to know if it was a first visit. Seems simple enough? Did it actually never work or something?
> Backend latency should be negligible next to RTT latency though
"Should" is doing a lot of work there. For dynamic resources this is often very not true. On the other hand i suppose the landing page is often highly optimized.
The cookie approach does seem like the most common approach to that problem. I have no idea how well it worked.
A modern SPA is often just a static HTML page that loads a whole bunch of minified JS. Backend latency is indeed negligible in that case, compared to the RTT for the multiple MB of scripts that you need to load, parse and execute.
A more traditional multi-page website, on the other hand, can benefit a lot from putting a CDN in front of it. Once the main dynamic resource has been generated, the rest of your assets can be loaded from edge servers closer to your users. When RTT is on the order of 10ms, it doesn't really matter whether you push or pull.
Sure there are scenarios where it doesn't really matter, but that is not everyone.
Edge caching is great if resources can be shared. Sometimes resources are per-user.
SPA's that involve dynamic per user content still have to load it to show the user anything interesting.
Edge caching is definitely not 10ms for everyone. Depending on who you are targeting that could be a reasonable assumption, but it is definitely not true of the world at large.
By the time you visit the second page on a multi-page site, you are likely to have almost all stylesheets, scripts, and common images already cached. This means you will reject almost all of the resource the server tries to push to you. Even on the first page, modern browsers are very quick to identify resources they need to load, both from headers and the early parts of the document. They load those resources concurrently while they are still parsing the document, so they are rarely blocked for a noticeable time.
Meanwhile, single-page sites have evolved to a point where the entire application is contained in one or two heavily optimized, minified scripts. You just load that one script and you're done. Most small images these days are SVG embedded right in the source code, so again, there's little need to push other resources.
The only time a modern website makes you to load a lot of unanticipated resources is when those resources are used for tracking and advertising. They can't be pushed because they live on different origins.