Hundreds of comments yet not one questions the fact that the premise of the article might be flawed. They're using "onload" event times and calling this "webpag

Hundreds of comments yet not one questions the fact that the premise of the article might be flawed. They're using "onload" event times and calling this "webpage speed" (there's no such thing as webpage speed btw[0]). It's especially known onload is not a very reliable metric for visual perception of page loading[1] (visual perception of loading = what most think of as "page speed"), that's why we have paint metrics (LCP, FCP, FMP, SI, etc). Tools like PageSpeed Insights/Lighthouse don't even bother to track onload. In fact, HTTPArchive (the source of data the article uses) has been tracking a lot of performance metrics, not just onload. Some have been falling, some have been rising, and it depends on the device/connection. Also, shaving 1 second off a metric can make a huge difference. These stats are interesting to ponder about, but you can't really make any sweeping judgements about it. It looks like people just want to use this opportunity to complain about JavaScript and third party scripts, but for above-the-fold rendering, this isn't usually the only issue for most websites. Frequently it's actually CSS blocking rendering or other random things like huge amounts of HTML, invisible fonts, or below-the-fold images choking the connection. Of course, this doesn't fit the narrative of server-side vs client-side dev very well, so maybe that's why there's hundreds of comments here without any of them being an ounce skeptical of the article itself. [0]. https://developers.google.com/web/fundamentals/performance/speed-tools#myth_1 https://developers.google.com/web/fundamentals/performance/s... [1]. https://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/ https://www.stevesouders.com/blog/2013/05/13/moving-beyond-w...