102 ms·

Along this theme of knowledge, there is the lost art of tuning your page and content sizes such that they fit in as few packets as possible to speed up transmis

Along this theme of knowledge, there is the lost art of tuning your page and content sizes such that they fit in as few packets as possible to speed up transmission. The front page of Google for example famously fitted in a single packet (I don't know if that's still the case). There is a brilliant book that used to be a bit of a bible in the world of web sysadmin from the Yahoo Exceptional Performance Team which is less relevant these days but interesting to understand the era. https://www.oreilly.com/library/view/high-performance-web/9780596529307/ https://www.oreilly.com/library/view/high-performance-web/97...

NelsonMinar 2y ago
See also the 14KB website article: https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/ https://endtimes.dev/why-your-website-should-be-under-14kb-i... Optimizing per-packet really improves things but has gotten very difficult with SSL and now QUIC. I'm not sure Google ever got the front page down to a single packet (would love a reference!) but it definitely paid very close attention to every byte and details of TCP performance.
- ryantownsend 2y ago
  iirc, most content delivery networks have now configured initcwnd to be around 40, meaning ~58kb gets sent within the TCP slow start window and therefore 14kb is no longer relevant to most commercial websites (at least with H1/H2, as you mentioned QUIC/H3 uses UDP so it's different)
  - divbzero 2y ago
    When and where you heard that initcwnd is typically 40 for most CDNs? I was curious but the most recent data I could find was from 2017 when there was a mix of CDNs at initcwnd=10 and initcwnd>10: https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-p... Currently Linux still follows RFC6928 and defaults to initcwnd=10: https://github.com/torvalds/linux/blob/v6.11/include/net/tcp.h#L242-L243 https://github.com/torvalds/linux/blob/v6.11/include/net/tcp...
- eastbound 2y ago
  And the good olden time when IE only supported 31KB of Javascript.
  - recursive 2y ago
    It's time to bring back that rule.
    - o11c 2y ago
      I recently did a deep dive into the history of JavaScript standards: (pre-ecmascript versions of JS not investigated) EcmaScript 1(1997) = JavaScript 1.1 - missing many ES3 features (see below), of which exceptions are the unrecoverable thing. EcmaScript 2(1998) - minimal changes, mostly deprecations and clarifications of intent, reserve Java keywords EcmaScript 3(1999) - exceptions, regexes, switch, do-while, instanceof, undefined, strict equality, encodeURI* instead of escape, JSON, several methods on Object/String/Array/Date EcmaScript 4(2003) - does not exist due to committee implosion EcmaScript 5(2009) - strict mode, getters/setters, remove reservations of many Java keywords, add reservation for let/yield, debugger, many static functions of Object, Array.isArray, many Array methods, String().trim method, Date.now, Date().toISOString, Date().toJSON EcmaScript 5.1(2011) - I did not notice any changes compared to ES5, likely just wording changes. This is the first one that's available in HTML rather than just PDF. EcmaScript 6(2015) - classes, let/const, symbols, modules (in theory; it's $CURRENTYEAR and there are still major problems with them in practice), and all sorts of things (not listed) EcmaScript 11(2020) - bigint, globalThis If it were up to me, I'd restrict the web to ES3 with ES5 library features, let/const from ES6, and bigint/globalThis from ES2020. That gives correctness and convenience without tempting people to actually try to write complex logic in it. There are still pre-ES6 implementations in the wild (not for the general web obviously) ... from what I've seen they're mostly ES5, sometimes with a few easy ES6 features added.
- divbzero 2y ago
  The “Slow-Start” section [1] of Ilya Grigorik’s High Performance Browser Networking also has a good explanation for why 14 KB is typically the size of the initial congestion window. [1]: https://hpbn.co/building-blocks-of-tcp/#slow-start https://hpbn.co/building-blocks-of-tcp/#slow-start
benmmurphy 2y ago
It is interesting how bad some of the http2 clients in browsers send the first http2 request on a connection. It’s often possible to smush it all into 1 TCP packet but browsers are often sending the request in 3 or 4 packets. I’ve even seen some server side bot detection systems check for this brain dead behaviour to verify it’s really a browser making the request. I think this is due to the way all the abstractions interact and the lack of a corking option for the TLS library.
deleted 2y ago
[deleted]

NelsonMinar 2y ago

See also the 14KB website article: https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/ https://endtimes.dev/why-your-website-should-be-under-14kb-i... Optimizing per-packet really improves things but has gotten very difficult with SSL and now QUIC. I'm not sure Google ever got the front page down to a single packet (would love a reference!) but it definitely paid very close attention to every byte and details of TCP performance.

ryantownsend 2y ago
iirc, most content delivery networks have now configured initcwnd to be around 40, meaning ~58kb gets sent within the TCP slow start window and therefore 14kb is no longer relevant to most commercial websites (at least with H1/H2, as you mentioned QUIC/H3 uses UDP so it's different)
- divbzero 2y ago
  When and where you heard that initcwnd is typically 40 for most CDNs? I was curious but the most recent data I could find was from 2017 when there was a mix of CDNs at initcwnd=10 and initcwnd>10: https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-p... Currently Linux still follows RFC6928 and defaults to initcwnd=10: https://github.com/torvalds/linux/blob/v6.11/include/net/tcp.h#L242-L243 https://github.com/torvalds/linux/blob/v6.11/include/net/tcp...
eastbound 2y ago
And the good olden time when IE only supported 31KB of Javascript.
- recursive 2y ago
  It's time to bring back that rule.
  - o11c 2y ago
    I recently did a deep dive into the history of JavaScript standards: (pre-ecmascript versions of JS not investigated) EcmaScript 1(1997) = JavaScript 1.1 - missing many ES3 features (see below), of which exceptions are the unrecoverable thing. EcmaScript 2(1998) - minimal changes, mostly deprecations and clarifications of intent, reserve Java keywords EcmaScript 3(1999) - exceptions, regexes, switch, do-while, instanceof, undefined, strict equality, encodeURI* instead of escape, JSON, several methods on Object/String/Array/Date EcmaScript 4(2003) - does not exist due to committee implosion EcmaScript 5(2009) - strict mode, getters/setters, remove reservations of many Java keywords, add reservation for let/yield, debugger, many static functions of Object, Array.isArray, many Array methods, String().trim method, Date.now, Date().toISOString, Date().toJSON EcmaScript 5.1(2011) - I did not notice any changes compared to ES5, likely just wording changes. This is the first one that's available in HTML rather than just PDF. EcmaScript 6(2015) - classes, let/const, symbols, modules (in theory; it's $CURRENTYEAR and there are still major problems with them in practice), and all sorts of things (not listed) EcmaScript 11(2020) - bigint, globalThis If it were up to me, I'd restrict the web to ES3 with ES5 library features, let/const from ES6, and bigint/globalThis from ES2020. That gives correctness and convenience without tempting people to actually try to write complex logic in it. There are still pre-ES6 implementations in the wild (not for the general web obviously) ... from what I've seen they're mostly ES5, sometimes with a few easy ES6 features added.
divbzero 2y ago
The “Slow-Start” section [1] of Ilya Grigorik’s High Performance Browser Networking also has a good explanation for why 14 KB is typically the size of the initial congestion window. [1]: https://hpbn.co/building-blocks-of-tcp/#slow-start https://hpbn.co/building-blocks-of-tcp/#slow-start

benmmurphy 2y ago

It is interesting how bad some of the http2 clients in browsers send the first http2 request on a connection. It’s often possible to smush it all into 1 TCP packet but browsers are often sending the request in 3 or 4 packets. I’ve even seen some server side bot detection systems check for this brain dead behaviour to verify it’s really a browser making the request. I think this is due to the way all the abstractions interact and the lack of a corking option for the TLS library.

deleted 2y ago

[deleted]