1. 59
  1. 20

    TLS probably has a lot of impact on this. First, TLS handshake requires at least two exchanges that need to be ACKed before sending the actual HTTP response. In that time TCP might figure out the bandwidth. Or if not, spent most of those initial 10 packets leaving almost nothing for HTTP.

    1. 7

      It does seem really weird that this is only barely mentioned in the article when it’s overwhelmingly likely to dominate any considerations having to do with slow-start.

      1. 6

        Exactly this. Terminating TLS has a real cost and eats up the budget that you’re talking about. I can’t stand this sort of posturing bull that ignores reality. The original author should go funroll some loops.

      2. 22

        Once you lose the autoplaying videos, the popups, the cookies, the cookie consent banners, the social network buttons, the tracking scripts, javascript and css frameworks, and all the other junk nobody likes

        This seems like a very simplified view of web development. I’m not sure I’d describe something that makes our work manageable as “junk nobody likes”

        1. 17

          Just as often (more often, I’d argue) they can be what makes the work unmanageable.

          1. 3

            I think it depends on whether you’re the creator or the consumer of the site.

          2. 7

            We should distinguish between websites and web apps. Does a web app have to be under 14kb in size? I don’t think so.

            1. 0

              We should distinguish between websites and web apps.

              No such thing like “web apps” exists. There are still HTML documents, just because you rearrange them faster than display pipeline can show them doesn’t mean there aren’t regular web pages still.

              After all, the whole movement to make HTML document browser a some sort of application runtime is just silly, if not stupid.

              1. 9

                There are still HTML documents, just because you rearrange them faster than display pipeline can show them doesn’t mean there aren’t regular web pages still.

                I don’t think anybody is arguing this. But its important to acknowledge different “HTML documents” on the web serve different purposes. “Web apps” do serve a different purpose to regular HTML “documents”.

                the whole movement to make HTML document browser a some sort of application runtime is just silly, if not stupid.

                Well, its too late for that unfortunately. The fact is for most users of the WWW, the browser is an application runtime more so than a document browser.

                1. 7

                  Yet it exists as a distinct term because enough people understand the phrase “web app” as a thing separate from “web site”, especially when used in context or in comparison to each other. I can use the term “web app” and expect a large majority of people to understand me. Refining it into a technically-precise definition may be more fraught, but that does not mean there is “no such thing”. It is just as useful to use as other generally-acknowledged categories with fuzzy boundaries: fruit, vehicle, city, democracy.

                  As the kids might say, “Language be like that sometimes.”

                  1. 4

                    It would seem most disagree with you. As a developer of a webapp myself, there are stark differences between that which is meant as a document and that which is meant to be worked with.

                    1. 2

                      If you think there’s no meaningful distinction between a web app and a web site, I disagree with you.

                      1. 1

                        The web browser was initially created to have links between text documents. That’s it. That proved to be not useful enough in many cases, because people want more interactivity. Hence almost every big feature in the web standards in the last 25 years has been targeted at web apps, not HTML documents.

                        Calling these apps just “HTML documents” is like saying that modern applications are just “assembly programs” because that’s all they are under the hood.

                    2. 4

                      Doesn’t this apply only if the whole thing is served in a single request (that is, there are no linked stylesheets or scripts)?

                      1. 5

                        It implies that your minimum viable stylesheets are inline, yes.

                        1. 4

                          With HTTP pipelining, maybe that doesn’t matter?

                          1. 4

                            Good question. It still matters. The second request isn’t going to be initiated until at least the first byte from the first request returns. (Containing either Link headers or tags in the html .)

                            HTTP 2 server push was intended to be a way around this but hasn’t worked out spectacularly well in practice.

                            1. 2

                              It really depends on a context and will be different for each site. For example if you host resources on a different CDN domain, you’ll suffer the slow start on both the page itself and on the first resource from CDN.

                              Then again, your resources may not be delayed for too long, because they’re likely referenced in the first 14kb of it that you’ll receive and parse quickly. Then quic may influence what’s happening again. It’s impossible to generalise this.

                          2. 4

                            The initcwnd is usually tunable[1], many commercial CDNs run with more than 10 segments, sometimes much higher [2]. Note this is not good behavior, especially in the extreme.. I think some of these operators run lower than the 2017 numbers now.

                            [1] https://svnweb.freebsd.org/base?view=revision&revision=290043

                            [2] https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/

                            1. 3

                              I mean, I guess.

                              CDNs are pretty famous for playing with the Initial Window size with some having been found using an IW of 100. You are probably safe tuning IW for your content size, the negative impacts might be entirely external to your metrics though. I know of some QUIC implementations that did IW30, but in the form of IW10 followed by the rest being paced out of a guess of the RTT.

                              If you want best response then you can align TCPs (and QUICs) parameters to your application. The ‘rules’ in the standards aren’t exactly enforced by anyone.

                              1. 2

                                I remember it being in the tech press a bunch when Google publicised that they had switched to an initial window size of 10 from the previous default of 4. About a decade ago I think? The publicity convinced people to change the defaults.

                              2. 4

                                Is this still true now that we have HTTP/2 and QUIC?

                                1. 2

                                  It says so in the article.

                                  1. 3

                                    Except the article seems to sort of handwave TLS away while in practice HTTP/2 only works over TLS…

                                    1. 1

                                      To be pedantic, http2-the-protocol works without tls. The spec does NOT require it. http2-as-implemented by most (all?) browsers requires it.

                                      1. 1

                                        That is precisely what I meant by “in practice” :)

                                        1. 1

                                          Whoops, I missed that :p

                                  2. 1

                                    This slow start algorithm occurs at the TCP level, which underlies HTTP, so I doubt that HTTP/2 or QUIC has any bearing on this.

                                    1. 19

                                      QUIC is on UDP

                                        1. 2

                                          Oh wow, I didn’t know that, thanks!

                                          1. 0

                                            In http3. Everything still sits on tcp in http2.

                                            1. 2

                                              HTTP/2 has nothing to do with QUIC and predates it by quite some years.

                                              1. 1

                                                I think you’re replying to the wrong person?

                                                1. 1

                                                  You are both technically correct, but it’s hard to understand what both of you are trying to convey apart from being technically correct.

                                                  1. 1

                                                    Yes, this thread was a disaster.

                                      1. 3

                                        What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.

                                        I had no idea! That’s pretty interesting.

                                        1. 1

                                          I was reminded of this blog post about TLS record size and buffering.

                                          1. 1

                                            I wonder if this could be hilariously sidestepped by setting your MTU to some higher value. Of course, fragmentation will occur, but those 10 initial packets will carry a lot more data than 14kb.

                                            1. 4

                                              You can, but there is no promise anything will handle a larger MTU.

                                              For networks you completely control(like say an Intranet app) perhaps a large MTU is reasonable. On the public internet, it’s unlikely to work out very consistently.

                                              1. 2

                                                This comment reminds me that the XBOX 360 set some weird MTU like 1492 or something as a default.

                                                1. 5

                                                  1492 is the maximum MTU when using PPPoE. Someone working it probably just decided it was better to default to that so things would work well for people with DSL.