💾 Archived View for warmedal.se › ~bjorn › posts › website-bloat.gmi captured on 2023-12-28 at 15:30:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
I held a talk at my work today about bloat of the modern web. I'd like to share it with a wider audience, especially since so many kind people on fedi helped me with the opinions I needed to start off ❤️
It comes as no surprise that different people mean different things when they use the term. I would collect the common opinions I've found into roughly three categories.
"If the numbers of blocked elements in my adblocker/privacy plugin ticks up a bit I know it’s bloated."
"If it requires Javascript to work at all (i.e. display content) it’s bloated."
In FLOSS circles there is a pervasive experience of being constantly under attack while online. Being targeted with advertisement or trackers, or being required to execute code in order to gain basic functionality of a site, is seen as a form of attack or abuse. Therefore any site that assumes my consent to this is bloated.
"How many graphical elements does it load? Do I have to navigate around them to find the content I came for?"
If visual elements get in the way, or act as obstacles or distractions, a lot of users will experience the site as bloated regardless of other factors. It's just too much to take in, or too confusing with a bunch of transitions, layout changes, autoplay movies, or large eye-catching graphics or ads.
"Speed of loading/rendering matters. If the website is slow on a slow connection or device, it’s bloated."
"It’s not about how heavy it is. It’s about how much lighter and faster it could be while still fulfilling its purpose."
The most common perception of bloat is the total size and experienced speed of the site. Does it load megabytes of assets? Does it make a lot of requests? How long does it take to render, and how long before I can interact with it?
Note that the user doesn't really care about limiting factors such as having a patchy internet connection or old/slow device here; if your site has poor performance under these very real circumstances it will be experienced as bloated. Period.
As you may have gathered we can address all three of these to some extent by focusing on the last (and most pervasive) viewpoint. Because the answer to the question of whether big is automatically bloated is YES!
And no.
The thing is that there's no clear limits on size, and it's dependent on context. If I want to read a blog post I expect the page to load swiftly and present the text I'm looking for clearly, but if I'm about to play a browser based game with lots of graphics and cool mechanics I probably expect it to be relatively demanding and take some time to load. I'm also not likely to expect it to run well on an old device.
The rule of thumb here is that megabytes and clock cycles used should serve a direct purpose for the user. Immediately beneficial in a meaningful way.
Don’t load large assets for small uses: an entire font family for a headline, a large Javascript framework just to have tabs or tracking, large high-resolution images just for background/ambience.
It comes down to sustainability of different categories.
"53% of mobile website visitors will leave if a webpage doesn’t load within 3 seconds." - Google
If you want first time visitors, recurring visitors, and organic recommendations, you need your visitors to like your site. And that's not just about content, as we all know. It's also about resources and presentation, and how you treat your visitors.
Bloated websites contribute to the premature obsolesence of devices, forcing users to upgrade. This is of course bad for the user's economy, and for the environment. An increased need for fast connections and better hardware also means you're locking poorer users out of your website, and pushing the need for extensive infrastructure expansions in many areas of the world.
More assets and dynamic functionality also means more storage, CPU and bandwidth requirements on the server side. This is both more expensive for the producer and more straining for the environment.
It's quite possible that website producers end up adding more frameworks and complex tools in order to optimize or handle the size and complexity of their website, which of course may be beneficial for the user but at the cost of added maintenance burden.
All of these may seem bloated from the user's perspective, but I'm sure twitter developers would claim that the 960kB of javascript serves some sort of purpose. Whether or not it's a purpose that the user agrees with is another question.
I'm sure you've noticed that news articles or blog posts are often adorned with a stock image if no original photo fitting for the topic can be obtained. That's of course because we're more likely to read it if it does. Can we really blame The Guardian for their high ratio of image content in that case?
But the fact is that back in the nineties a groundbreaking 3D first person shooter with lots of levels, fun mechanics, and sophisticated shader and reflection handling took up less space than most websites do today.
“[...] web struggles to deliver a page of web content in the same size [as the game Doom, 2.4MB].”
https://www.theregister.com/2016/04/22/web_page_now_big_as_doom/
https://www.webbloatscore.com/
https://developers.google.com/speed/pagespeed/insights/
I hope this helps you with your next website project, or starts a thought process or discussion that is fruitful 😊️
-- CC0 ew0k, 2021-04-16