3 ms·
Absolutely not, even on HTTP1.1. Our webapp is achieving 800:1 to 5000:1 compression ratios pushing down the entire HTML page over brotli and zstd. The first r
by Aeolos 2mo ago
Absolutely not, even on HTTP1.1.
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.)
- altairprime 2mo agoOkay, so, to parse this — you have a highly performant http/1 app using a fresh connection setup/teardown at 100ms per cycle? 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.
- Aeolos 2mo agoWe are serving over HTTP/2 and currently testing HTTP/3. I don't have direct HTTP/1 vs HTTP/3 comparisons, because 0% of our requests are over HTTP/1 today...