Live data from Hacker News

How web bloat impacts users with slow devices

danluu.com

341–350 of 613 posts

Re: How web bloat impacts users with slow devices

#341
post #316

as a data point youtube is unusable on raspberry pi 3. This happened within the last year, because prior to that you could "watch" videos at about 10-15FPS which is enough, for instance, to get repair videos in a shop setting (ask me how i know). When the raspberry pi model B - the first one released - came out, you could play 1080p video from storage, watch youtube, play games . I'm not sure what youtube is doing (o…

>If we're serious about this climate crisis/change business, someone needs to cast a very hard look at google and meta for these sorts of shenanigans By all accounts client devices' energy consumption is a rounding error in terms of contribution to climate change. Going after them to solve climate change makes as much sense as plastic straw or bag bans.

It has a cumulative effect and drives the continual "upgrade" cycle. When you consider the life-time of an average mobile device, and the resources required to manufacture and ship them, it's a not insignificant problem.

Re: How web bloat impacts users with slow devices

#342

I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. They’re just as to blame for the sad world of web software as the big boss or corporate overlord that forced someone to make bad software.

That's not fair. Sure, if there's an experienced dev who _values_ efficiency on the team, who pushes for the site to be more efficient or builds it more efficiently to begin with, the page would be better off. But it's mostly about incentives. If management doesn't care, they will likely not react well to programmers spending time making the site more efficient instead of spending half the time to just get it running and then crunching through their backlog.

Re: How web bloat impacts users with slow devices

#343
I think it would be useful to separate data & code here. What if you kept the code the same, and downgraded the assets so the overall package is smaller/easier to process/execute? Or maybe tweaked the renderer so the same code & data can render quicker and slightly worse image quality consuming fewer CPU cycles? Basically I'm envisioning something like a game where the same game data+code can support multiple performance targets (except in this case the different CDN hookups to get the assets out, rather than everyone getting the bloated data download)

Re: How web bloat impacts users with slow devices

#344

I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. They’re just as to blame for the sad world of web software as the big boss or corporate overlord that forced someone to make bad software.

Usually bad web software correlates with bad content. Therefore having a slow device is an excellent filter helping to avoid garbage.

Re: How web bloat impacts users with slow devices

#345
post #320

I think bloat could be prevented if it was noticed the moment it is introduced. After application evolves bloated, it's difficult to go back and un-bloat it. Bloat is often introduced accidential/y, without need, and unnoticed just because developers test on modern and powerful devices. If developer's regular test matrix included a device with minimal hardware pewer that was known to run the product smoothly in the p…

> After application evolves bloated, it's difficult to go back and un-bloat it. It will be hard to get to pristine quality, but there ought to be some amount of low hanging fruit, where minimal changes bring noticeable improvement.

Maybe, but determining it will take some investigation. If the regular testing is done on a low profile device, developer knows as soon as possible that his recent changes introduced a bloat regression.

Re: How web bloat impacts users with slow devices

#346

Every company stopped caring, especially the companies who were at the forefront of standards and good web design practices, like Google and Apple. Google recently retired their HTML Gmail version, mind you, it still worked on a 2008 256MO RAM Android phone with an old Firefox version and it was simply fast... of course the new JS bloated version doesn't, it just kills the browser. That's an extreme example, yet low…

Yes, on Thursday Google ended their only viable "product". RIP Google. The new Reddit is unusable, and the old is well too old. Twitch is borderline usable, with chat and video stream problems... The list is long... All changes are bad when you have the final formula because they are job security. Eventually the monkeys on this ball of dirt will realize that jobs and money don't exist, but then it will be to late...…

> the old is well too old

What's wrong with the old Reddit UI?

Re: How web bloat impacts users with slow devices

#347
post #7

Earlier quoted context omitted.

> readers are asked to build up an idea of what attitudes software engineers supposedly have. But they do, don't they. Discourse's founder's words are just very illustrative. Have you used the web recently? I have. It's bloated beyond any imagination to the point that Google now says that 2.4 seconds to Largest Contentful Paint is fast now: https://blog.chromium.org/2020/05/the-science-behind-web-vit... (this is from…

You're making the same mistake the post did. It depends on the reader already having sympathy for the idea that bloat is bad in order to make its case. I can read nerd site comments all day that lament bloat. For an article to stand on its own on this point it has to make the case to people who don't already believe this. Dan's articles have usually been very good at that. The keyboard latency one for example makes f…

The article you diss has actual benchmarks in it. The article I linked has actual numbers in it.

At this point you're willingly ignoring it because you dislike that this is additionally illustrated by quotes from specific people.

Re: How web bloat impacts users with slow devices

#348
post #339

I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. They’re just as to blame for the sad world of web software as the big boss or corporate overlord that forced someone to make bad software.

"it's better for the company that I don't try, my time is expensive and any minute not spent on a feature is a waste of my salary" - is a common justification that I hear all too often.

"It's better for the company that I don't try" seems like a convenient take for a dev without the skills to have. I'd argue that performance is a feature, and if someone can't deliver it their salary is being wasted already.

Re: How web bloat impacts users with slow devices

#349
post #44

Not only the user is affected by this. The difference between a 2MB and a 150KB CSS file can be a lot of bandwidth. The difference between a bad and good framework can be a lot of CPU power and RAM. Companies pay for this. But I guess most have no clue that these costs can be reduced. And some companies just don't care as long as money is coming in.

It's a numbers game. Mostly the difference doesn't matter at all to the vast majority of users. Optimizing for the bottom 1 or 2 percent that don't have any disposable income to update their phones, or pay for your wonderful products or services is not a big priority. And not all companies have rockstar developers working for them. That's why things like wordpress are so popular.

I actually pulled the plug on a wordpress site for my company last week. We now have a static website. It's a big performance improvement. But the old site was adequate even though it was a bit slow to load. So, nobody really noticed the improvement. Making it faster was never a requirement.

What is worth optimizing for is good SEO. There's of course a correlation between responsiveness and people giving up and abandoning web sites. That's why big e-commerce sites tend to be relatively fast. Because there's a money impact when people leave early.

What I find ironic is that the people complaining about this stuff are mostly relatively well off developers with disposable incomes and decent hardware. If they use crappy/obsolete hardware it's mostly by choice; not necessity. Some people are a bit OCD about performance issues as well. They notice minor stutters that nobody cares about and it ticks them off.

2MB is nothing. I'm saying this as somebody who used cassettes, and later floppy disks with way less capacity. But that's 35 years ago. The only time when this matters to me is when I'm on a train in Germany and my phone is on a really flaky mobile network that barely works. Germany is a bit of a third world country when it comes to mobile connectivity. So, that's annoying. But not really a problem web developers should concern themselves with.

Re: How web bloat impacts users with slow devices

#350
post #316

Earlier quoted context omitted.

>If we're serious about this climate crisis/change business, someone needs to cast a very hard look at google and meta for these sorts of shenanigans By all accounts client devices' energy consumption is a rounding error in terms of contribution to climate change. Going after them to solve climate change makes as much sense as plastic straw or bag bans.

IT is emitting around as much as aviation, and that was a surprise to me, most of it are due to client devices. Don’t have the source at hand at the moment though. And of that, most emissions are upfront until you buy it. Buying a new device because it’s not fast anymore causes emissions, not running it. Think about e-waste as well.

>IT is emitting around as much as aviation

What counts as "IT"? It's most certainly a superset of "client devices", which is what my and the parent comment was talking about.

Post reply on HN