What does bloated website actually mean? What is characteristics of a bloated website?
I could imagine something that bloated for you, might not be bloated for me? Are there any metrics that quantifies this?
For example:
* Page should load to a useful state (could still be background tasks) in under 2s
* Clicking a link should take me to the next page and it should be useful in under 2s
* Making a change to a config item and saving the update should complete in under 2s
If your service can do that, you customers will feel like your system is fast. On the other hand, this is generally considered a technical crowd and we probably look at resource consumption. A site that eats 25% of one of my CPUs and requires 128M of RAM just to load is going to check my box for bloated.
All the stuff that is extraneous to the reason you visited the webpage would be bloat.
Think about a news article on [insert your favorite news website]. Often before you can see the article, you have to process a bunch of JS (SPA framework, tracker code, etc) before the text loads and you can get the info you were looking for.
Sure, adding tracker and other stuff might be a jarring experience. But I think you can have all the stuff in your app and make it async so that it does not impact the core functionality of the app.
A page of text should just be a page of text. That's the beauty in sites like hackernews and craigslist. They are down-and-dirty, just-the-facts, we'll-get-out-of-your-way websites.
You see bloat when you start adding stuff that obscures that core functionality and/or slows down/degrades the experience.
Of course, the core functionality changes depending on who you are. The customer might just want to read the article, but the sales team wants to get you to see/click on ads and the marketing team wants you to signup for their newsletter. So, one person's bloat is another person's core functionality.
If you, as a user, feel that the site is sluggish, unresponsive or difficult to use because it feels too crowded or has too many features, you might judge that site to feel bloated.
In a more technical sense, bloated might refer to very large (or poorly optimized) files, either javascript or static assets, required to run the thing, causing it to load slowly (i.e. at a speed that the user feels is "slowly").
So maybe a good summary might be: "does too much stuff and/or poorly optimized/coded"
Again, not exactly a tight definition, but UIs are inherently characterized by the perception of their users.
I know it is subjective thing that is the reason why I asked this question. For me all UIs are bloat the CLI experience is the best, for someone else, it might not be.
The bloating problem from my perspective might just be a UX problem that the framework you use or the library you use.
It is difficult. It's probably the central difficulty of UIs on the web. However what I said is still true: The quantification inherently rests on users' perception of their experience. This is more a question of psychology than of computer science.
What percentage of your users feel that the app is too slow or confusing? What percentage would you be okay with? If you're selling some kind of enterprise software whose users will not be the buyers but rather the buyers' employees, who cares if it takes 30 seconds to load every page and another 30 seconds to find the widget you need once it's loaded?
The definition of "too bloated" is a function of both how users feel and also how much value you get from reducing it, and the measurement of "bloated-ness" (as well as many other parameters of UX) can't happen without getting feedback from users, which means there's a pretty strict limit to how much we can understand just from discussing theory.
And just to further complicate things: If I'm making a richly featured web app (something like Slack for example) I have a predefined set of features that will need to be implemented using javascript. Obviously there are many parameters that determine how well these are designed and implemented and optimized, all of which will affect how the users perceive the app as a whole. However, what about users (say, some plurality of HN readers) who intrinsically value websites which function without javascript, and will always consider those that don't to be bloated; What use is it to quantify that if it's always going to run up against my stated goal of building a chat app in the browser?
In the background, it can be that your browser is making requests to heaps of tracking services and CDNs when loading the page.
I’ve basically just stopped browsing the web at this point. It’s nigh on unusable sometimes. I buy recipe books, read the NYTime’s daily newsletter, and browse hackernews. Reddit’s unbearable these days, Twitter’s a bit of a dumpster fire even if it wasn’t bloated (I don’t have social media accounts to curate the experience either), and god forbid you click a link on a news aggregator site like Fark (where the headlines are as misleading as something your Great Aunt shared from some long chain of disinformation anyways), even with ad blockers half the pages are just absolutely bonkers.
It’s just not worth it anymore. My print copy of the New Yorker and occasionally some blog posts from here.
On the other hand, JIRA displays lists of tickets. It should be a bit snappier probably. There’s gotta be a way to display 200 tickets without it slowing my computer down. It’s certainly not the text that’s the issue, HN displays that many comments fairly easily and without hiccup.