> 95% of the problem with web page performance today is ads.
No. I use extremely strict ad-blocking and many website's performance is still shit, both concerning load times as well as CPU hogging.
The problem with web page performance is people believing that by distributing all their (mostly unnecessary) assets over two dozen unrelated origins they speed things up. They don't. That's what makes things slow.
The problem with web page performance is people believing they need some mirrored btree-reverse-hash-indexed shadow DOM, 1.5 MB of Angular, four to five more JS frameworks and 20000 NPM packages with a "ng build" time no less than 50 seconds to show a news article.
The problem with web page performance is people believing a page would render faster if, instead of sending HTML, you send a giant blob of JS which, after almost choking a parser to death, then does a XHR to actually fetch the content and then starts to render templates into actual HTML.
(You know, before everything went apeshit, we used to tell people to put <script> tags last in the document, because that way the browser can render your page without blocking on downloading, parsing and executing your scripts — no one would notice if the menu bars lacked soft animations for 0.3 s after a page load, but people would of course notice if the page stayed blank for another third of second.)
> The problem with web page performance is people believing that by distributing all their (mostly unnecessary) assets over two dozen unrelated origins they speed things up.
Ironically that is exactly what web developers were told to do for years:
I can't deny that a lot of web pages bundle far too much JS, but if you've been using a strict ad blocker for a long time you perhaps don't realise how bad the ad code has gotten. React loads in the blink of an eye compared to the multi-second load times for five-level embedded popover ads.
I assumed the OP wasn't talking about third party assets since no-one chooses to distribute them across different domains, that's just how they have to be used.
> The problem with web page performance is people believing a page would render faster if, instead of sending HTML, you send a giant blob of JS which, after almost choking a parser to death, then does a XHR to actually fetch the content and then starts to render templates into actual HTML.
"It's asynchronous, and that makes it soooo fast!"
So many people drank that async kool-aid, but didn't understand that the network is slower.
I don't think that anybody believe that Angular/React/Whatever are fast. They may be fast relative to another framework but certainly not to a simple webpage that has almost no JS.
The problem is mostly that most clients nowadays don't want a webpage, they want a web application. Something similar to what they have on their phone, computer, ... But JS is no C++ and so Angular cannot be Qt.
I use to make Qt application, now I work has a webdev. I do really see how web app are slugish and tend to lag everywhere. But the thing is, for most client, they don't really mind. What they see is that they can access the app from all their computer, phone and tablet, and that matters a lot more for them.
Plus, we will probably never come back to the era where most rendering was done server-side, it just cost too much.
To be fair, front-end heavy web apps decrease a lot of human delay: it used to be that I clicked "submit" and then the screen went white and when it came back I had to recontextualize and connect the results to what I had previously inputted. Modern one-page applications with edit-in-place textboxes and content that reacts to draggable maps, etc. are much easier on the human brain.
No. I use extremely strict ad-blocking and many website's performance is still shit, both concerning load times as well as CPU hogging.
The problem with web page performance is people believing that by distributing all their (mostly unnecessary) assets over two dozen unrelated origins they speed things up. They don't. That's what makes things slow.
The problem with web page performance is people believing they need some mirrored btree-reverse-hash-indexed shadow DOM, 1.5 MB of Angular, four to five more JS frameworks and 20000 NPM packages with a "ng build" time no less than 50 seconds to show a news article.
The problem with web page performance is people believing a page would render faster if, instead of sending HTML, you send a giant blob of JS which, after almost choking a parser to death, then does a XHR to actually fetch the content and then starts to render templates into actual HTML.
(You know, before everything went apeshit, we used to tell people to put <script> tags last in the document, because that way the browser can render your page without blocking on downloading, parsing and executing your scripts — no one would notice if the menu bars lacked soft animations for 0.3 s after a page load, but people would of course notice if the page stayed blank for another third of second.)