Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How web bloat impacts users with slow devices

danluu.com

Post reply on HN
Print view View original

261–270 of 613 posts

Re: How web bloat impacts users with slow devices

#261

Post by avodonosov »

Some years ago I tested real world web sites, turned out only about 30% of the javascript they load was actually invoked by the user's browser (even for sites optimied with Closure Compiler, that has some dead code elimination):

https://github.com/avodonosov/pocl

The unused javascript code can be removed (and loaded on demand). Although I am not sure how valuable that would be for the world. It only saves network traffic, parsing time and some browser memory for compiled code. But js traffic in the Internet is neglidgible comparing to, say, video and images. Will the user experience be signifiqanty better if browser is the saved from the unnesessary js parsing? I don't know of a good way to measure that.

Re: How web bloat impacts users with slow devices

#262

Post by mattl »

ericra wrote: post #256
mattl wrote: post #238

Earlier quoted context omitted.

Can you run all your traffic through a self-hosted pihole to avoid such things?

Certainly an option for me. But not a scalable solution for the large number of non-tech people with older devices.

I’d love something like it for all my older devices where I can set it and forget it.

Re: How web bloat impacts users with slow devices

#263

Post by jwells89 »

Sn0wCoder wrote: post #224
jwells89 wrote: post #214

Earlier quoted context omitted.

In these situations what’s eating up your resources usually isn’t the data being represented but instead the representation. This is why native apps use recycler views for not just infinite scroll, but anything that can display more rows/columns/items/etc than can fit on screen at once. Recycler views only create just enough cells to fill the screen even if you have tens of thousands of items to represent, and when y…

I find this idea interesting ‘These are possible in JavaScript in browsers, but implementation quality varies a lot and many web devs just never bother.’ Do you have any examples that you consider good implementations? I ask because tables seem to be the biggest offenders of slow components in say Angular / PrimeNG. I am going to a legacy app soon that is being updated (Angular but not PrimeNG). Would like to see if…

> its not Angular or PrimeNG specifically that make the tables slow/hogs, but the amount of DOM elements inside

Yep, this happens even with nothing but a 10-line vanilla JS file that adds N more items every time the user scrolls to the bottom of the page. Performance degradation increases with every load due to the growing number of DOM elements which eventually exceeds whatever margin is afforded by the machine the browser is running on, causing chug.

Web is not my specialty so I don’t have specific recommendations, but plenty of results turn up when searching for e.g. “angular recycler” or “react recycler”.

Re: How web bloat impacts users with slow devices

#264

Post by hotdailys »

lmz wrote: post #258
hotdailys wrote: post #251

When websites pack in too many high-res images, videos, and complex scripts, it’s like they’re trying to cram that overstuffed suitcase into a tiny space. Your device is struggling, man. It’s like it’s running a marathon with a backpack full of bricks. So, what happens? Your device slows down to a crawl, pages take forever to load, and sometimes, it just gives up and crashes. It’s like being stuck in traffic when you…

Maybe we'll see the return of the proxy + lightweight browser model like Opera Mini.

And lightweight APPs, one tap to load all...

Re: How web bloat impacts users with slow devices

#266

Post by doubled112 »

II2II wrote: post #235
goalieca wrote: post #102

Earlier quoted context omitted.

> For example, a user with a data plan with a monthly limit in the single-digit GBs, and a RAM/CPU profile resembling a decade-old US flagship I’m in Canada and have a single digit plan and I just upgraded from an almost decade old flagship. Most websites are torture.

I'm in Canada and have a triple-digit plan, in MBs. It's for emergency use only. It would be nice if something as simple as checking on power outages didn't chew up a good portion of the data plan.

I had a 200MB plan for $35/month until early 2022. It was an old Koodo plan.

I never used it. I don't do a lot. WiFi at home, drive to work, WiFi at work, drive to home.

Travelling with the kids I've found the new plan makes life easier.

Re: How web bloat impacts users with slow devices

#267

Post by Escapado »

_heimdall wrote: post #257
steve_taylor wrote: post #207

Earlier quoted context omitted.

These days they coerce the dev team into implementing a tag manager so they can add their filthy trackers without asking the dev team.

The "they" here can't really coerce the dev team unless the dev team is willing to comply. Refusing to implement an unethical feature is always an option, and given that we're often considered engineers it is well within our right to deem something unsafe or against best practices.

I hate all that tracking and marketing bs as much as the next guy but if the marketing team is the main stakeholder and is responsible for the budget that won't work. I also might be a bit biased as a freelancer but every team I worked in so far had other freelancers on it and if we strongly recommend aginst a practice but the client insisted then we basically had the choice to either abandon the project (and therefore our current source of income) or simply do what they say. I would love to be on a position where refusing is an option that would not cost me my gig.

Re: How web bloat impacts users with slow devices

#269

Post by avodonosov »

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 past, the dev could immediately notice the newly introduced bloat and remove it.

A bloat regression testing.

I call this "ecological development".

We should all do this. No need to aim for devices that already have trouble running your app / website. But take a device that works today and test that you do not degrade with respect to this device.

Re: How web bloat impacts users with slow devices

#270

Post by sockbot »

Baguette5242 wrote: post #108
kome wrote: post #93

Earlier quoted context omitted.

My MacBook Air (11-inch, Early 2014) is my only computer. I still don't feel like changing it so far...

Amateur… I am using a 2009 15’ MacBook Pro Unibody, with a swapped SuperDrive to SSD, another main SSD and RAM boosted to 8Gb. OpenCore Legacy to update to a relatively recent version of MacOS. The only thing that is so annoying is the webcam that doesn’t work anymore, and a USB port is dead also. So sad this kind of shenanigans are not possible anymore.

I have one of these with a MacBook Pro 6,2 that I did the same upgrades to. However I finally decided to retire it when 2nd replacement battery swelled and Chrome stopped supporting OSX 13.

It didn't look like a good candidate for OpenCore Legacy because of the dual video cards, but it feels so gross recycling a perfectly working computer.

Post reply on HN