Let me trade one dead horse for another: Product and marketing teams are at fault for all this. Or if you prefer, the advertising industry is at fault.
Take the payload of any typical blog or (God help you) your small-town newspaper website and count how many requests correspond to the actual content. Now ask yourself, who's paying someone to bloat this website, and why?
The bottom line is that nobody really has any strong incentives to advocate for performance, so it falls by the sidelines.
If your school uses gsuite (which they likely will given free stuff and integration), you can't choose not to use gsuite.
Same way as dev employees are forced by companies to prioritise features over optimisation.
Yet they keep on adding more and more crap, soon Gmail is going to load for over a minute..
I once saw a website that took a full minute to load, and it was literally a page with images, text overflowing around it, and then some download links. But the way it was built... my god, the way it was built.
That company brought in a new "CTO", and his solution was to dump the entire thing in google cloud. I shit you not, this CTO initially installed an EOL version of PHP, and when errors started happening, he started submitting PR's to revert the PHP code to be compatible with the EOL version of PHP.
Dumpster Fire.
Been there, done that, have scars.
I'm more inclined to believe he googled and blindly followed an old guide with an old ppa than I am to believe that google cloud by default installed an EOL PHP server.
I'm pretty sure he was a node guy who found himself in the PHP world.
I started working with some web developers for a simple project recently, my mock product was built with vue.js using the standard way of “including” it: But what really threw me for a loop was that the web developers told me that that’s wrong, they are now _compiling_ (Or, semantically “packing”) JavaScript blobs to make even very simple websites.
I don’t know why we as a community have started doing that, but it feels like an anti-pattern, it makes adding new dependencies opaque and we can very quickly end up including dozens and dozens of lines of code which must all be rendered by every device that comes into contact with my site.
Often this happens because we want only a small bit of the functionality too.
I think it's for two main reasons:
1. If you don't use complicated new technology you won't get a job doing web dev.
2. Many new JS devs don't understand JS/HTML/CSS well, they only understand a particular framework - and even then not in a sufficiently deep way.
When you come across a seemingly normal site that requires JS in order to display anything, it's pretty unlikely that anyone involved ever considered not doing it that way.
To be fair, this 'compiling' also allows for tree shaking, which if you use a well-structured library like lodash/date-fns etc, allows you to get that small bit of functionality without paying for the whole library.
I personally think it's a bit insane to add node.js as a dependency to a simple PHP project.
As a recent front end dev, I fought tooth and nail not to include all kinds of tracking drek into the company's site. I lost every time because management overruled me.
At some point, it occurred to me that it's not my site and I shouldn't be taking personally that which doesn't belong to me.
It's come to the point where i feel bad for using plain old single-request-loading html, because it doesn't look 'spinny' enough, and users may think it's uncool.
On the other side, I've been building websites that gets +95 on mobile on Google page speed. If no image above the fold... It gets 100. In mobile, yes. And I still have analytics, YouTube and images...
So I'd say depends by what business needs.
The vast majority of "page" content is baked into prerendered HTML and CSS rendered. I'm not sure what spinners you're talking about unless you're referring to web apps with timelines/news feeds that dynamically load.
Users love sites that load the important content and are interactive ASAP. Trust me, they appreciate your boring (fast) HTML.
The behaviour of desktop software developers in 1990's was a prelude to web frontend and app developers today. As the resource capacity of PC's increased through the 90's, software developers grabbed it for themselves; for the end user, the experience of using the software never got any faster.
As the storage, processing power and network speeds have increased, web frontend and app developers seem to have grabbed it for themselves as well; the end user experience has generally not gotten faster (if the user follows the instructions: use popular, Javascript-enabled browser, enable images, video).
In the 1990's, users were asked to upgrade their computers so they could run the new, larger but not experientally faster, desktop software. Today, we see the same sort of OS and device upgrades; "unsupported" versions of software that will not run on newer version of the OS. Plus we have a culture of allowing automatic, remotely-controlled installation of new software. Automatic upgrades. Telemetry. "Field testing" of new features. A sizeable amount of user choice and necessity for user consent has been successfully eliminated.
The number of outgoing TCP connections made by today's average websites, usually triggered through cascades of Javascript files, is simply staggering. It would never have been acceptable to do that with the networks and server software of the 1990's and 2000's. Users were not involved in the decision of developers to grab the newly available network resources and CPU for themselves.
I do not use a popular browser for most web use. This allows me to only make a single TCP connection to a website when I access it and can retrieve dozens or hundreds of pages over a single connection, thanks to old, standard features of the web documented in RFCs (pipelining). It is very fast and efficient. For me, the web has gotten much faster, but only because I choose the software and I decide whether and when to upgrade. It is my computer, after all. I am not really impressed by the popular browsers of today because it does not feel at all like the user is in control. Users of these programs have been reduced to guinea pigs.
The javascript cascade from hell starts when you add a single ad. We wrote a test param to remove ads and the page load went from 35Mb to 1.2Mb... all of it was JS and ad tracking code.
Edit: Server-side and client-side rebidding.
This is very much like the idea of the optimal price point where the customer already cringes but still buys.
That's why there's such insane churn in the tooling and ecosystem. People rewrite and redesign constantly in order to work with the new cool framework.
React has dominated "real" frontend webapp development for a solid 5 years.
These things don't make headlines or get retweeted. The web produces a lot of variety because it has the widest distribution and the lowest barriers to entry.
I had a front-end developer come in and add node, bootstrap, and SCSS as a dependency to a very simple app. We went from having a super simple build chain to one that now needed maintenance. And part of his argument? he "thought better" in SCSS.
People have zero respect for the risk of dependencies, complicating the buildchain, or long term maintenance.
The last ui dev I had to work with managed to produce in about 1 year a very complicated dockerfile, that was spewing, between other things, an image for e2e testing - but no actual tests and you needed a huge makefile to actually build the thing, a soup of copy-pasted config files that resulted in a vendors.js bundle of about 100 megs - there were more config files than source code, 2 branches named <username>.wip.somedate with commits that commented out some parts of a config, just to uncomment them back in the next commit. The app itself, with ssr no less, was a logo and some text, that was using some custom components, built with some third party vue component that was rendering css in js, thus you had to wait for the entire vendors.js to download before you got anything rendered. His answer to anyone questioning his choices was "this is how modern ux development works".
After he was let go, I took over the ui and along with another coworker we managed to have a working version of the app in 9 days, with no prior knowledge of vuejs and nuxtjs. You can imagine how complicated the app is...
Still, to my point, the tools mentioned here have existed for a very long time with very large communities and are hardly the new shiny thing. Your complaint here seems to be more around using the wrong tool for the job.
This particular frontend person had convinced the owner of the company that there were things you could do in SCSS that you couldn't do in CSS. I had to explain to said owner that SCSS was compiled down to CSS because the browser didn't understand SCSS. That you literally couldn't do anything in SCSS that wasn't allowed in CSS.
The owner ended up having a come to jesus moment when he tried to take all of the tools that frontend developer added and make them available in docker so that no one else had to install custom development tools. He spent several days, failed on it, and realized exactly why I was being so hardheaded about the build chain.
We never ended up getting rid of those dependencies, but I know the owner finally understood my point. Instead the team bifurcated into those who had their local environment setup to be able to successfully work on the frontend, and those who didn't.
A news site. It does precisely the same thing as news sites did a decade ago. On my machine, it loads slowly. Then, it needs to re-load every time you scroll. It's extremely slow. Indeed, on Firefox, it doesn't load everything consistently. If you click on an article, things get even worse because it needs to reload text when you scroll. This website is what I would call "barely usable".
Let me reiterate: This site does nothing new compared to old news websites. There is zero benefit to the user. It simply is slow.
I don't know who is to blame for this. But if even your text loads slow, you are building a bad website. I am sure, some frontend developer got paid for making this website. I am not sure they should have been.
AJAX (and, I suspect, the shadown DOM model) have proliferated in recent years, and there is no site design simple enough that someone hasn't thought to put every page element behind a JS call. Don't forget to put CSS in there, too!
Frontend developers are at fault for all this. There, I said it.