The metrics focus on the website but ignore the browser/client.
I use a text-only browser. It does not support Javascript. I also use TCP clients to make HTTP requests and fetch the HTML, then I read the HTML with the text-only browser. I use stored DNS data so there are no DNS lookups except one authoritative query over the loopback. With the exception of Washington Post, all news sites "load", i.e., download, at about the same speed.
If one is trying to demonstrate how fast the www can be without Javascript, then it seems counterintuitive to exclusively select only big, fat, graphical, Javascript-enabled browsers for the demonstration. Those enormous, complex programs^1 are part of the problem. Keep in mind that popular websites are generally^2 designed to take advantange of "browser features" such as images, CSS, Javascript, and automatic fetching of resources from external sources. "Tech" companies desperately try to make these "complex" websites faster through "engineering", but not by changing the design to obviate the need for features and external resources. The later method works. It has been thoroughly tested by yours truly for two decades.
If one uses a client that avoids images, CSS, JS and autofetching, then websites are generally faster. This method is not suitable for all websites, but it is ideally suited for websites that are textual and meant for reading, e.g., news websites. I cannot read for very long if using a graphical browser, it causes too much fatigue on the eyes. Whereas I can read for extended periods using a text-only browser on the console with zero eye fatigue. YMMV.
1. The Chrome binary, without all the libraries, is something like 150MB. The text-only browser I am using to type this comment is only 1.3MB, compiled statically.
Images and videos add a lot to the news and in many cases not seeing a visual leads to an incomplete story. Of course text only will be faster, it’s not something that needs to be explicitly pointed out.
In general. Most time is spent on command line in so-called virtual terminals (VTs) with no graphics layer and no GUI. All programming is done without a GUI or IDE.
I do not use a terminal emulator^1 inside X11, or something like X11. I no longer use X11. Nor do I use VMs. I write scripts and compile programs on small, underpowered computers.^1 IME, switching between graphics layer and console text VTs (e.g., Ctrl+Alt+F2) is slow, so I have learned to stay in one context. I prefer VESA textmode on older computers and something like VESA textmode on newer ones.
It would be nice to have a framebuffer instead of GUI where I could view images, watch video, etc. without having to use a different computer or switch contexts.
1. I do use a terminal multiplexer (tmux).
2. If I wrote scripts and compiled programs on a larger, more powerful computer I would be less sure that they would also compile quickly and run fast on smaller, underpowered ones.
I use a text-only browser. It does not support Javascript. I also use TCP clients to make HTTP requests and fetch the HTML, then I read the HTML with the text-only browser. I use stored DNS data so there are no DNS lookups except one authoritative query over the loopback. With the exception of Washington Post, all news sites "load", i.e., download, at about the same speed.
If one is trying to demonstrate how fast the www can be without Javascript, then it seems counterintuitive to exclusively select only big, fat, graphical, Javascript-enabled browsers for the demonstration. Those enormous, complex programs^1 are part of the problem. Keep in mind that popular websites are generally^2 designed to take advantange of "browser features" such as images, CSS, Javascript, and automatic fetching of resources from external sources. "Tech" companies desperately try to make these "complex" websites faster through "engineering", but not by changing the design to obviate the need for features and external resources. The later method works. It has been thoroughly tested by yours truly for two decades.
If one uses a client that avoids images, CSS, JS and autofetching, then websites are generally faster. This method is not suitable for all websites, but it is ideally suited for websites that are textual and meant for reading, e.g., news websites. I cannot read for very long if using a graphical browser, it causes too much fatigue on the eyes. Whereas I can read for extended periods using a text-only browser on the console with zero eye fatigue. YMMV.
1. The Chrome binary, without all the libraries, is something like 150MB. The text-only browser I am using to type this comment is only 1.3MB, compiled statically.
2. HN is one exception.