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

221–230 of 613 posts

Re: How web bloat impacts users with slow devices

#221

Post by publius_0xf3 »

He mentions Substack, which is maybe the most egregious example of bloat I regularly encounter. Like I cannot open Scott Alexander's blog on my phone because it comes to a crawl.

But the Substack devs are aware of this. [They know it's a problem](https://old.reddit.com/r/slatestarcodex/comments/16xsr8w/sub...).

>I'm much more of a backend person, so take this with somewhat of a grain of salt, but I believe the issue is with how we're using react. It's not necessarily the amount of content, but something about the number of components we use does not play nicely with rendering content at ACX scale.

>As for why it takes up CPU after rendering, my understanding is that since each of the components is monitoring state changes to figure out how to re-render, it continues to eat up CPU.

They know—but they do nothing to fix it. It's just an impossibility, rendering all those comments.

Re: How web bloat impacts users with slow devices

#222

Post by Izkata »

AlienRobot wrote: post #72

I'm glad people remember what WW in WWW means. :) It makes me very sad to see that reddit's new design is so heavy it can't even be accessed by part of the world. It's like parts of the internet are closing theirs doors just so they can have more sliding effects that nobody wants. Or maybe I'm just a weird one who prefers my browser to do a full load when I click a link. Btw there was a time everyone kept talking abo…

> I'm glad people remember what WW in WWW means. :)

Welcome to the Wide Web, where bloat is the norm.

Re: How web bloat impacts users with slow devices

#223

Post by teg4n_ »

hexage1814 wrote: post #162

>Many pages actually remove the parts of the page you scrolled past as you scroll There is a special place in hell for every web developer who does that.

It’s a performance optimization for rendering a large amount of html. If the DOM had all the items in memory it would perform much worse. Thankfully browsers are working on a feature where you can keep the markup in the DOM for things like CTRL-F without hurting performance.

Granted the main reason such a technique is needed is designs that avoid pagination.

Re: How web bloat impacts users with slow devices

#224

Post by Sn0wCoder »

jwells89 wrote: post #214
freedomben wrote: post #208

Earlier quoted context omitted.

Problem is, "infinite scroll" often is infinite, meaning it will load an ass load of data in the background and take up a ton of memory, and the user may never even end up looking at that data. I really hate the load on scroll (especially Google Drive's implementation which is absolute trash, and half the time I'll scroll too fast and it will just miss a bunch of files and I'll have to refresh the page and try again)…

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 we can build a feature rich table that is more performant than the PrimeNG one that I know looks amazing but is the cause of many headaches.

NOTE: its not Angular or PrimeNG specifically that make the tables slow/hogs, but the amount of DOM elements inside and some of the implementation details that I disagree with (functions that are called withing the HTML being evaluated every tick). Would be great to see if this idea of a ‘recycler widget’ can help us. Cheers.

Re: How web bloat impacts users with slow devices

#225

Post by JJMcJ »

rmbyrro wrote: post #216
paledot wrote: post #190

Earlier quoted context omitted.

(But don't under any circumstances break the four other trackers already running on the site.)

You mean the four new ones they added last week alone, right?

Newpaper sites are notorious for this.

Re: How web bloat impacts users with slow devices

#226

Post by skydhash »

mardifoufs wrote: post #203
chmod775 wrote: post #150

Earlier quoted context omitted.

I went with the other techie solution: resizing my browser window.

How do you do that on mobile?

Who read article like this on mobile? In a pinch, I'd just activate Reader Mode (Safari, iOS), or more likely save it for reading on a bigger screen (tablet, laptop,…)

Re: How web bloat impacts users with slow devices

#227

Post by lazypenguin »

maxloh wrote: post #81

YouTube is one of the slowest websites I have ever used. It takes several seconds to load, even with moderate hardware and fast internet connections.

YouTube doesn’t feel zippy as a website but the reliable and speed of videos have been very good for me. I remember the days when buffering videos was hell.

Re: How web bloat impacts users with slow devices

#228

Post by Gibbon1 »

mastazi wrote: post #178

> While reviews note that you can run PUBG and other 3D games with decent performance on a Tecno Spark 8C, this doesn't mean that the device is fast enough to read posts on modern text-centric social media platforms or modern text-centric web forums. While 40fps is achievable in PUBG, we can easily see less than 0.4fps when scrolling on these sites. Remember this the next time marketing asks the frontend team to impl…

Firing up my neoliberal brain.

We should just tax ad and spying on users bandwidth and front/backend end resource use.

Re: How web bloat impacts users with slow devices

#229

Post by LoganDark »

golergka wrote: post #172
yawaramin wrote: post #171

Earlier quoted context omitted.

> The only thing that might is a wholesale different client architecture that sacrifices features and polish to provide the slimmest code possible. That is, an alternate "lite/basic" mode. Unfortunately, this style of approach has rarely proved successful But it is gaining popularity with the unexpected rise of htmx and its 'simpler is better even if it's slightly worse' philosophy.

Isn't that 'worse is better' philosophy?

I think it's rather a "performance is more important than functionality" philosophy.

Re: How web bloat impacts users with slow devices

#230

Post by antisthenes »

genewitch wrote: post #153
Retr0id wrote: post #119

Earlier quoted context omitted.

I have no idea if it still works, but the "h264ify" browser extension used to be great for working around this issue (by forcing youtube to serve h264) https://github.com/erkserkserks/h264ify

i did a full apt dist-upgrade to try and get the h264ify plugin to install and if i remember correctly i never was able to get it to install. I upgraded from "chromium" to "chromium-browser" and set all the compositing and other settings recommended for the RPI. and to reply to another sibling, "yt-dlp" isn't workable, this is for a senior citizen that does small motor repairs. I got an HP elitedesk that's a few year…

RPI 3 for a senior citizen seems like a poor solution in the first place.

I would have opted for a small business-pc that is x86 based and 3-4 years old.

Post reply on HN