How exactly modern web ended up in a situation where, first time browser is displaying a single page (with maybe 3 pictures and 2 paragraphs of text), it has to download 300 resources from 12 different servers, including 2 megabytes of minified javascript?
Not sure about typical, but here is rough estimate for the rock bottom of it: "feh" image viewer on Ubuntu/X11:
$ strace -e openat -o >(wc -l) feh -F \
one.jpg two.jpg three.jpg
105That said, I would not be surprised if XFree86 was, at some point, significantly larger than contemporary web browsers, given the enormous amount of functionality that was loaded into it. Of course, modern web browsers definitely trump any old X server, so is this really relevant? I guess it depends. I get a huge sense that what people are longing for is a return to the "good ol days" when software was simple and fast, and X is a damning counter example, though it certainly doesn't mean that there's no point to be made at all, just that it is perhaps less black and white than people suggest.
I am not trying to say that feh is as complex or as slow as a web browser, only that in general, people treat the division of "native code" and "browser code" such that code running in a browser is always more bloated and slow. Somehow though, this is demonstrably not true. Looking at only very simple software with intentionally very limited scope is not going to give the whole picture. When you look at fairly complex software, the additional burden of having a browser underneath can fade away compared to algorithmic complexity issues and poorly optimized code. Your text layout and font shaping routines are probably going to struggle to compete with a browser if you have a very heavy layout to handle, and if you're doing accidentally quadratic things it's going to matter more than JIT or GC overhead.
And this time it's orders of magnitude worse.
Strawman argument.
I just want to read a damn article. Why does it need to download hundreds of resources from dozens of origins? Reading a PDF article on my desktop touches exactly one file, the PDF. Ok, maybe some dylibs from the OS related to PDF rendering. But surprise! Browsers already have everything built-in for HTML rendering! No need to download an HTML rendering engine, because it’s already there: it’s the browser!
The real waste is in the time it takes to create and destroy the connection. (hence why http/3 switched to UDP, and also why multiplexing is a thing.)
Thing is, combining js and css on the server side into 1 file pretty much negates this speed benefit. I've been building sites this way forever, and performance is great. First page takes longer, but then those files are in the cache anyway.
The actual problem is Ads. They require tracking, and of course displaying. If you're looking for waste, or indeed why a server would bother with http/3 then look no further. No ads, no problem.
Unfortunately for those sites that rely on advertising for revenue, I don't have an alternative suggestion. I get it, ads pay for lots of the Internet I "browse". I'm not a fan of pay walls and subscriptions.
So http/3 is a solution to an economic reality - and really only benefits the ad-supported Web - but for them it is important.
The wife's family living away from the main city have intermittent connection and slower speeds. We have only one submarine cable and poor infrastructure further out. So heavy, bloated sites eat up people's pre-paid internet packages quickly or have trouble loading altogether. Prepaid is around $1.25 for 500MB or $10 for 5.5GB.
I think lower bundle sizes should be a goal. Or lower bandwidth websites should be available such as a 'm.' Domain. IMO
Statements like this reminds me we live in different planets. I'd argue we should still care, just like we care about accessibility in general, but obviously it's indeed a lost cause. Anyone not on 1Gbps and 32 GB of RAM is to be relegated
The problem is that who make websites, instead of making documents, maybe built dynamically by the server and with some interactive elements in it, doesn't sent you a document but instead sends you an application that builds the document into the browser, basically turning an application that simply displays you document into a virtual machine that runs an entire graphical environment.
The fact is that most of the websites to function doesn't need a line of JavaScript, and still are downloading Mb of libraries to do what?
Most of the problems wouldn't be even present if we reason in terms of documents, and in terms of operations that you can do on these documents (GET, PUT, DELETE, POST). You find out that for most website you don't need JS!
One could argue that JS is an optimization because you don't load up again the whole page each time you navigate to a different URL. That is false: if you cache the assets that doesn't change between pages such as stylesheets and images correctly, downloading just the HTML of the page is something trivial. Look at the number of requests that a webpage that uses JS does: is that more efficient?
Mostly to polyfill around the fact that basic DOM manipulation is garbage and the default UI widgets are ugly.
^Who cares about 2 MB with 5G? That's exactly how we get into current shitty situation. Network is fast, memory is cheap so let's do whatever we want. In 2004, I only had 512MB memory on my computer, it run pretty smoothly. But now I got 64GB of memory and I run of memory now and then. I'm wondering how soon I'm going to put 1TB of RAM into my computer, not going to be too far away I reckon.
Ads.
> 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
Fortunately, Reader Mode is available in a few user-friendly browsers.
If it's just a normal non-interactive website then it shouldn't have any javascript in the first place.
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).
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.
What you describe was a huge pain, most page forced us to download 15MB of data and load it in memory just to display 2 small images and some text.
A format like PDF would have been much better because we could have read enough byte until we are able to render the visible part of the document.
But instead we had to download and execute 30 javascript files.