> that loose back-and-forth over HTTP weighs more than an always-open WebSocket
This is definitely true for HTTP/0 and /1. Is it still true under HTTP/3, or has the underlying ‘single conduit, many channels’ model improved things if used correctly?
This is definitely true for HTTP/0 and /1. Is it still true under HTTP/3, or has the underlying ‘single conduit, many channels’ model improved things if used correctly?
Our webapp is achieving 800:1 to 5000:1 compression ratios pushing down the entire HTML page over brotli and zstd. The first render is about 20:1 compression, every interaction after that is 800-5000:1.
We are using datastar with the recommended "fat morph" approach where we re-render the entire HTML page from scratch on every request. Our typical RTT is <100ms including rendering, then the brotli / zstd compression window cuts down the wire size to literally _bytes_.
This is SO much more efficient than our previous reactjs & graphql render waterfalls with state duplication in the client side. All states lives on the server, all renders are authoritative, and we need to maintain roughly half the code size for better first-render and massively better interactive performance. Appserver and DB pressure is massively reduced too.
(This is a medical device with a highly interactive UI, image viewers, editors, not a boring old static website.)
Have you tested that same app over http/3 with tuning to reuse the underlying channel, and if so, what were your outcomes?
H1 can be pretty awesome but my core curiosity here is whether reducing the connection overhead through H3 matters or not. I am not out to disprove H1 full-page HTML as a delivery mechanism.
I don't have direct HTTP/1 vs HTTP/3 comparisons, because 0% of our requests are over HTTP/1 today...