4 ms·

> How exactly modern web ended up in a situation where [...] > it has to download 300 resources from 12 different servers, > including 2 megabytes of minified

by jupp0r 4y ago

> How exactly modern web ended up in a situation where [...] > it has to download 300 resources from 12 different servers, > including 2 megabytes of minified javascript? This is "best practice" that is used widely to work around HTTP 1.1 Head of Line Blocking [1]. HTTP/2 and to a greater degree HTTP/3 (as it also alleviates TCP head of line blocking) are fixing the underlying problem making the former best practice an anti pattern (but only for those users able to use modern HTTP implementations). [1] https://en.wikipedia.org/wiki/Head-of-line_blocking#In_HTTP https://en.wikipedia.org/wiki/Head-of-line_blocking#In_HTTP

divbzero 4y ago
“12 different servers” and “minified JavaScript” were indeed workarounds for head-of-line blocking, but I think the GP’s main point is that “300 resources” and “2 megabytes” should not be required for displaying a web page.
- nine_k 4y ago
  They are not required to display a web page. They are mostly required to make money off that web page, and, to a smaller degree, to observe how users interact with it and thus improve it (also aligns with making more money). Fortunately, Reader Mode is available in a few user-friendly browsers.
  - deleted 4y ago
    [deleted]
- jupp0r 4y ago
  Adobe Photoshop and Quake 3 are JS apps nowadays so depending on your use case it's completely legitimate to download hundreds of megabytes of code and data in modern browsers. I once worked on an app that was a heavily optimized tree shaken 40MB bundle of JS because it was a telephony system, video conferencing and document sharing and collaboration app. Completely ok size for that use case. If it's just a normal non-interactive website then it shouldn't have any javascript in the first place.
SahAssar 4y ago
Newer HTTP versions solve some some things but are not magic pixie dust. For example: * If you have file A requiring file B requiring file C requiring file D you still get a chain of requests. * Compression works a lot better the more data you throw at it, especially similar data which is usually the case for JS/CSS. SDHC was supposed to solve this, but it was never adopted by any major players besides linkedin (and google itself).
- jupp0r 4y ago
  HTTP/3 is pixie dust. It solves most problems that previous transport layers had and also supports 0 RTT TLS handshakes in case of QUIC. Of course the transport layer can't magically resolve application layer dependencies as you mentioned, that's not its job.
toast0 4y ago
HTTP/2 was supposed to help avoid openning too many connections, but of course TCP in TCP is bad form. Now HTTP/3 is TCP in UDP, and has separate connections (more or less) per resource. I'm not sure what the big difference is between that and HTTP/1.1 with multiple TCP connections. There is an argument for better congestion control. Which is funny coming from Google where they control the kernel on the server and the clients. Yes, it takes more time to deploy better congestion control if it needs kernel updates, but if it's really important to update congestion control without kernel updates, you could make interfaces for usermode congestion control.
- jupp0r 4y ago
  Too many TCP connections is a browser limitation (for DDOS prevention reasons mostly). Inside each connection you are limited by head of line blocking, either by HTTP/1.1 itself or by TCP when using HTTP/2. You are correct that HTTP/3 can stream multiple resources over one QUIC connection via multiple channels and each channel can make progress independently from each other channel. Nowadays (assuming a modern browser in a non-udp restricted environment), you can just download hundreds of resources at the same time from the same server through one HTTP/3 connection without much overhead and transport level limitations.
  - toast0 4y ago
    Seems like all the churn could have been avoided by webservers advertising a limit on number of connections and browsers opening up to that limit if needed. Maybe in the connection header, or the keep-alive header, or some new header that Google servers and Chrome Browser could have tried out first.
    - jupp0r 4y ago
      That doesn’t really solve head of line blocking.

by jupp0r 4y ago

divbzero 4y ago

“12 different servers” and “minified JavaScript” were indeed workarounds for head-of-line blocking, but I think the GP’s main point is that “300 resources” and “2 megabytes” should not be required for displaying a web page.

nine_k 4y ago
They are not required to display a web page. They are mostly required to make money off that web page, and, to a smaller degree, to observe how users interact with it and thus improve it (also aligns with making more money). Fortunately, Reader Mode is available in a few user-friendly browsers.
- deleted 4y ago
  [deleted]
jupp0r 4y ago
Adobe Photoshop and Quake 3 are JS apps nowadays so depending on your use case it's completely legitimate to download hundreds of megabytes of code and data in modern browsers. I once worked on an app that was a heavily optimized tree shaken 40MB bundle of JS because it was a telephony system, video conferencing and document sharing and collaboration app. Completely ok size for that use case. If it's just a normal non-interactive website then it shouldn't have any javascript in the first place.

SahAssar 4y ago

Newer HTTP versions solve some some things but are not magic pixie dust. For example: * If you have file A requiring file B requiring file C requiring file D you still get a chain of requests. * Compression works a lot better the more data you throw at it, especially similar data which is usually the case for JS/CSS. SDHC was supposed to solve this, but it was never adopted by any major players besides linkedin (and google itself).

jupp0r 4y ago
HTTP/3 is pixie dust. It solves most problems that previous transport layers had and also supports 0 RTT TLS handshakes in case of QUIC. Of course the transport layer can't magically resolve application layer dependencies as you mentioned, that's not its job.

toast0 4y ago

HTTP/2 was supposed to help avoid openning too many connections, but of course TCP in TCP is bad form. Now HTTP/3 is TCP in UDP, and has separate connections (more or less) per resource. I'm not sure what the big difference is between that and HTTP/1.1 with multiple TCP connections. There is an argument for better congestion control. Which is funny coming from Google where they control the kernel on the server and the clients. Yes, it takes more time to deploy better congestion control if it needs kernel updates, but if it's really important to update congestion control without kernel updates, you could make interfaces for usermode congestion control.

jupp0r 4y ago
Too many TCP connections is a browser limitation (for DDOS prevention reasons mostly). Inside each connection you are limited by head of line blocking, either by HTTP/1.1 itself or by TCP when using HTTP/2. You are correct that HTTP/3 can stream multiple resources over one QUIC connection via multiple channels and each channel can make progress independently from each other channel. Nowadays (assuming a modern browser in a non-udp restricted environment), you can just download hundreds of resources at the same time from the same server through one HTTP/3 connection without much overhead and transport level limitations.
- toast0 4y ago
  Seems like all the churn could have been avoided by webservers advertising a limit on number of connections and browsers opening up to that limit if needed. Maybe in the connection header, or the keep-alive header, or some new header that Google servers and Chrome Browser could have tried out first.
  - jupp0r 4y ago
    That doesn’t really solve head of line blocking.