Live data from Hacker News

How web bloat impacts users with slow devices

danluu.com

361–370 of 613 posts

Re: How web bloat impacts users with slow devices

#361

I've always wondered why people removed parts of the page when they were scrolled out. Like, don't you think the browser would already optimize for that? And even if it's not stored in the DOM, it's still being stored in the JavaScript's memory. It's frustrating when people try to reimplement optimizations that the browser already does better.

The browser does not in fact optimize that. Yes it's surprising. If you want it to do basic optimizations like not rendering invisible content you need to give it hints via obscure and relatively recent CSS rules nobody ever heard of.

Re: How web bloat impacts users with slow devices

#362

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.

You are right.

I browse the web on Firefox with uBlock Origin, 3rd party cookies disabled, and so on.

So I am missing the bloat most people talk about.

But still apps like Clickup are really slow. It's just bad software.

Re: How web bloat impacts users with slow devices

#363

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)…

> 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. It's also an infinitely worse user experience and prevents you from holding your place in whatever is being scrolled. Are there advantages? Why is infinite scroll used in any context?

1 batch of content = 1 batch of add space = more money.

Each next page click is a moment for you to reflect and notice the waste of time. Simple as that.

Re: How web bloat impacts users with slow devices

#364

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)…

> 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. It's also an infinitely worse user experience and prevents you from holding your place in whatever is being scrolled. Are there advantages? Why is infinite scroll used in any context?

Personally I prefer infinite scroll, versus the alternative of finding the "next page" button at the bottom, waiting for the content to load (preloading could help here) and sometimes navigating to the beginning of actual beginning of the content I was viewing. I even used a browser extension that matched "next" buttons from pages and loaded the next page content automatically, but the extension (can't recall its name) is not available anymore.

Granted there are some downsides, such as having the browser keep extra-long pages in its memory, but overall I prefer working infinite scroll mechanisms over paged ones. As far as I see, the ability to remember the current location in the page could be easily implemented by modifying page anchor and parameters accordingly, though personally I've rarely needed it.

Perhaps if there was a standard way (so in the HTML spec) to implement infinite scrolling, it would work correctly in all cases and possibly even allow user to select a paged variant according to their preference.

Not all the paged views work correctly either. In particular systems that show threaded discussions can behave strangely when you select the next page. Worst offender is Slashdot.

Re: How web bloat impacts users with slow devices

#365
post #8

As someone with recent experience using a relatively slow Android phone, it can be absolutely brutal to load some web pages, even ones that only appear to be serving text and images (and a load of trackers/ads presumably). The network is never the bottleneck here. This problem is compounded by several factors. One is that older/slower phones cannot always use fully-featured browsers such as Firefox for mobile. The ap…

> In these situations, companies frequently try to force an app down your throat instead. And who knows how much space that will take up on a space-limited device or how poorly it will run.

And honestly, that app is going to be a browser shell with a (partially) offline copy of the website in it, 9 times out of 10...

Re: How web bloat impacts users with slow devices

#366
My own recent experience with this - i run a small sass web app and about a year ago i decided to partner with advertising company to help with the grow.

Part of the plan was that they will remake our static homepage in Wordpress bc it will be easier to manage it for them and also easier to add a blog, which was part of the new plan. I know Wordpress is slow and i would say unnecessary also but i said yes bc i did not want to micromanage them.

A year later we parted our ways and i was left with WP where the page load was abysmal(3-5 seconds) and about 10Mb of bs. There was something called "Oxy" or "Oxy builder" which would add a tons of style,js and clutter to the markup and kind of SPA page load style but horribly failing.

So now i migrated the site to Jekyll, got rid of all the bs and it's back fast. And for me also again possible to really improve.

So for my businesses i'm not touching WP ever again and that will be a huge bloat reduction in itself

Re: How web bloat impacts users with slow devices

#367
post #354
post #342

Earlier quoted context omitted.

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…

It usually requires less time, not more, to create a slim and efficient page.

but can it do feature x that generates more $$$ ?

Re: How web bloat impacts users with slow devices

#368

My own recent experience with this - i run a small sass web app and about a year ago i decided to partner with advertising company to help with the grow. Part of the plan was that they will remake our static homepage in Wordpress bc it will be easier to manage it for them and also easier to add a blog, which was part of the new plan. I know Wordpress is slow and i would say unnecessary also but i said yes bc i did no…

Seems like your issues were not with WP itself, but with whatever plugins and themes were added to it. Avoiding WP entirely for this is like avoiding a programming language because the 1 developer you had experience with sucked at it. WP itself can be very fast, as is evident by a ton of high profile sites running it (CSS-Tricks, TechCrunch, New York Times, Time Magazine, etc). I'm not a fan of WP myself, but that's just because I don't like how its built and how it entirely avoids modern programming standards, not because it is slow, which it most definitely doesn't have to be.

Re: How web bloat impacts users with slow devices

#370
post #339

Earlier quoted context omitted.

"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.

Performance is a feature and management often doesn't care to optimize for it. If the market valued performance more then we would probably see competitive services which optimize for performance, but we generally don't. I'm sure there's plenty of developers that could deliver improved performance, it's just a matter of tradeoffs.

Maybe the people who care this much about performance should start competing services or a consulting firm which optimizes for that. Better yet, they could devote their efforts to helping create educational content and improved frameworks or tooling which yields more performant apps.

Post reply on HN