I'm curious with the multiplexing improvements if we'll see greater performance gains in the long-term as we changed how we package and bundle JS.
I've seen a significant improvement in general page performance using Webpack's chunking, where it automatically breaks up each of your components into smaller .js file and only loads them if the page uses them (basically on-demand async importing of JS files that were preprocessed with webpack).
It went from loading one giant blob of JS on every page into one primary JS file (about 25% smaller) + a bunch of tiny 1-10kb .js files that load async. A typical heavily interactive page would load 5-10 of these async files.
There's probably opportunities to go even further in breaking up the primary file (which handles the logic of which JS components to load + includes the Vue/whatever framework and other JS dependencies).
I understand the utility of "loading once and caching" stuff but for serious JS-heavy frontends the bundled JS files becoming extremely bulky (sometimes in multiple megabytes due to legacy dependencies) and ideally you'd minimize that always-cached part as much as possible.
If you’re comparing it to HTTP/1.1, the performance improvements are generally a lot better than that. The latency improvements are commonly something around that, but the total page loading performance will tend to be better because you get proper multiplexing.
But then you may say, why do we need this instead of HTTP/2, which had proper multiplexing? Well, it improves things a bit further, commonly improving throughput and latency by 1–10% if I’m recalling the right figures; but more importantly, it fixes the TCP head-of-line blocking issue that made HTTP/2 often actually perform a lot worse than HTTP/1.1 on low-quality connections.
I know of sites that have held off on HTTP/2 or rolled it back because it made things measurably worse for some users, and of sites that split things across domains with some HTTP/1.1 and some HTTP/2, deliberately, purely because of the TCP HOLB issue. HTTP/3 fixes that, so that it should no longer be a question of whether you make things faster for some users at the cost of others—you can instead make it faster for everyone.