HTTP/3 Is Fast
This comment is not specifically about quic, which I believe is a solid idea and would love to see used and supported more, but about the topic of requiring super fast connections to do things that really shouldn&#x27;t need them.<p>Accessing a page where all useful information I am interested in is text, should not require a new protocol developed by genius engineers to work without delay. If I want to read an article that is 50kB of text, it&#x27;s not unreasonable to expect that information to be here before my finger leaves the ENTER key, regardless of how its transmitted.<p>Why isn&#x27;t that the case?<p>Because said article is not transmitted with a dollop of html to structure it, and a sprinkle of CSS and JS to make it look nice. It&#x27;s delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where, mostly to spy on me or trying to sell me crap I don&#x27;t need.<p>I am not saying &quot;don&#x27;t invent new protocols&quot;. But maybe think about why it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s, despite the fact that our networks and computers were little more than painted bricks and paper-mache by todays standards.<p><a href="https:&#x2F;&#x2F;idlewords.com&#x2F;talks&#x2F;website_obesity.htm" rel="nofollow">https:&#x2F;&#x2F;idlewords.com&#x2F;talks&#x2F;website_obesity.htm</a><p>If we don&#x27;t think about this, then neither QUIC, nor QUIC2 or REALLY_QUIC will save us from being wading through a pool of molasses slow crap. Because inevitably, following each techical improvement that could makes our stack faster, is an even bigger pile of bloat that drags it down again.