How web bloat impacts users with slow devices:

https://danluu.com/slow-device/

How web bloat impacts users with slow devices

@danluu People have no idea how much I appreciate a bare page like this, even on a fast machine and connection. I open something and it’s just there. I can adjust the window width if I want. No distractions. Full focus on the actual content on both ends. I don’t care that it doesn’t follow the latest fashion.

@jonathanavt @danluu I totally agree that page bloat is a problem. However, publishing things as a brutalist mess does not help communicating it.

A few KB of CSS can improve that dramatically: Using the system font stack, limiting the content size to a comfortable width would already be enough.

@fleg @danluu I don’t have a problem with a bit of CSS. The overall balance is just ridiculously out of whack.
@jonathanavt @danluu 💯!
I would happily trade the current CSS- and (especially) JavaScript-bloaty internet for brutalist Times New Roman.

@danluu You may also be interested in this series that I've been producing ~annually to help webdevs level-set:

https://infrequently.org/series/performance-inequality/

The latest post is here:

https://infrequently.org/2024/01/performance-inequality-gap-2024/

The Performance Inequality Gap - Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Infrequently Noted
@slightlyoff @danluu I hesitate to even ask this question because it betrays the depths of the problem, but: who is doing this _right_? If I want to vote with my keyboard and go work for a company that does truly care about this stuff, how would I even go about finding them these days? Where are people going if they want to spend their time sharpening their craft?
@sangster @slightlyoff @danluu check out https://climateaction.tech and their slack. There are a few jobs going there.
Home - ClimateAction.Tech

The climate crisis is happening all around us. As tech workers, we can use our skills to take and accelerate climate action.

ClimateAction.Tech

@slightlyoff This is a great series, thanks for pointing me to it!

I added a couple of references to this in the post and I'm looking forward to your next entry in the series.

@danluu Cheers! I'm a fan of your input latency work, and if you want to collaborate on any of this, LMK.
@slightlyoff That would be great! You definitely know way more about this area than I do and I'd love to work with you on something. I'm not sure what, but we can probably figure something out :-)

@danluu Just a heads-up, the link highlighted in the screenshot below seems to be broken.

It links to https://danluu.com/jeff-atwood-trashes-qualcomm-engineering.png, which yields a 404 on my end.

@danluu: You should become a member of the #250kBClub: https://250kb.club/

(Unfortunately the #10kBClub ceased to exist, but your homepage might have been eligible for membership there, too — it had additional prominence requirements, while the 250kBClub just looks at the size and that it's not just a random subpage.)

The 250kb Club

An exclusive membership for web pages presenting themselves in no more than 250kb.

@xtaran @danluu
I want to add some content and still have some ideas for more optimization before I register mine:

https://bebna.de

@danluu For reddit, using old.reddit.com makes the site actually usable.

@danluu couple typos I noticed: “need’t”, “performs poorly for then”, “in Vietnam them”

Also “Appendix: articles on web performance issues” is missing size/Tecno numbers for your site I think.

@danluu misskey and its descendants would get a "DEVICE BLEW UP" rating on this list
@chfour @danluu My network connection is so slow that it blows up in slow motion. Looks really cool ​
That Discourse guy is a classic example of someone designing their product for the world they wished existed instead of the world we actually live in. Devices with Qualcomm SoCs exist in billions, and will keep existing and keep being manufactured and sold for the foreseeable future. No amount of whining will change that. Get over it and optimize for them. People who use these devices won't care about your whining, they'll just consider you an incompetent software developer because your software crashes.
@danluu Do you think Knuth is blaming slow hardware here? To me, it reads like he's really talking about Amdahl's Law, and how hardware designers were too focused on multicore.

@danluu quick typo notice:

  • neilsen instead of nielsen
  • on the abbr immediately following neilsen: ‘pubic source’ instead of ‘public source’ (this one sparked joy!)
@danluu worse when you have #NarrowBand access only...
@danluu The Itel P32 is a 1 GB RAM Smartphone. That's far from usable in 2024. That was pretty low in 2016.
Those tests look like they are create with a view from 10 years ago...

@whitekiba @danluu currently replying from an android device with 1GB of RAM.

very usable.

@danluu @whitekiba you may want to re-read the beginning of the article, as you may have missed important notes there

@whitekiba @danluu until a couple of weeks ago I used an iPhone 8, which is like the Itel P32 from 2017 and has "only" 2 GB of memory. It was far from being unusable, except on websites that didn‘t give a flying fuck about their performance of course.

Also: you probably didn‘t read the article and just looked at the colorful table. Not everyone lives in rich/western countries like we do.

@whitekiba @danluu it is also a device sold in massive volume in the world.

Most of the world run on under 100$ android devices that have seen no massive power upgrade in the last 5 to 10 years.

This device is realistic for the majority of users of the web. See @slightlyoff performance inequality gap serie.

@danluu what I got in response when I quoted parts of your post; as always, for these people ease of maintenance has higher priority than accessibility to pooper users

@danluu I have trouble parsing this sentence:

> "At a first glance, the table seems about in that the sites that feel slow unless you have a super fast device show up as slow in the table (as in, max(LCP*,CPU)) is high on lower-end devices)."

Editing artifact?
The number of parentheses is odd, too.

@danluu “At a first glance, the table seems about in that the sites”—missing word?

“Although MyBB doesn't service up a mobile site”

“If we tap again, we can get the dreaded situation where the first tap registers and then causes the second tap to register after things have started changing, causing us to tap some random target, but if we wait, we realize that the original tap didn't actually register”—grammatical but confusing

@danluu “I got what appeared to be a causal an increase in”
@danluu the Discourse guy really do be adding some spicy discourse
@danluu and that is why my company website is small: it can be used almost any where with little internet connectivity and is still readable even as plain text

@[email protected] congrats on hitting the top of HN!

I am interested in seeing whether @[email protected] would fare better in your testing. We spent quite a bit of time over the years on making it wicked fast, and I personally feel it is a better representation of modern forum software than Discourse, at least on speed and initial payload.

NodeBB (@[email protected])

286 Posts, 79 Following, 875 Followers · 🗨️ Community forums for the modern web | Check us out at https://community.nodebb.org 🌐 Federated as of v4.0.0, thanks to NLNet NGI Zero Core Fund #fedi23 #oss #forums #community #yyz

Fosstodon

@julian @nodebb It's much faster than Discourse, but also slower than all of the php forums tested. Just trying it on the M1 and the Tecno Spark 8C, I get 0.3s/0.4s on the M1 and 3.4s/7.2s on the TS8C.

It's quite usable after the initial load on the TS8C. Clicking on links and loading individual threads is slower than on the php forums, but scrolling, clicking, etc., all work as expected, which can't be said for Discourse or many other "modern" sites.

@julian @nodebb

It's the only site that has an LCP* that's much faster than the LCP (3.4s vs. 7.3s for the TS8C) so there might be a small optimization that could be done that would hugely improve LCP? The content mostly shows up, but then stuff ends up moving around a bit or something?

I didn't try to debug this, but it might be worth looking into seeing if there's an easy way to hugely cut LCP on slow devices since I'm told that this is a ranking signal for Google search.

@[email protected] wow, thanks so much for running your test for me! It means a lot.

Also your note about our abnormally high LCP (sans asterisk) is interesting, considering the tricks that other sites utilize to artificially lower LCP, but which we don't bother with.

Ironically since the LCP* is lower than LCP, it suggests that us fixing this only results in a higher PageSpeed score but might not actually result in net benefit for end users. Ha!... but if there is a content shift, that's definitely a problem that needs to be addressed.

I'm not going to lie and say we don't chase metrics, we totally do... we just try to increase our metrics by actually making the site faster!

@danluu thanks for the deep analysis.

Apart from explicit web bloat regulation, I'm thinking if forbidding search engines to index content that requires JavaScript will cause a significant effect. Not only it will save computational energy on the crawlers, but it will force most sites to degrade properly without JS enabled.

@danluu
Thank you. It appears that Chrome was used across platforms for these tests, but 'Chrome' is not the same across platforms.

As I understand it, Chrome on IOS is running on Webkit. Chrome on MacOS is running on Blink. Chrome on an android device is running on Blink, but might be Chromium on an unlicensed device.
Obviously it would complicate testing, but Firefox runs the Gecko engine, are the results similar?

1/2

@danluu
I don't disagree with the premise, but all that HTML and JavaScript has to be interpreted, so indeed is CPU and RAM bound; how efficient the rendering engine is at that will affect the results, so the engine matters.

2/2

@danluu

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.If your website is 100x slower than PUBG then you may want to reevaluate what you've done ​

@hazelnoot
That quote stood out to me too. I think about why that would be and at least part of it is related to the Knuth quote, the game is heavily using the GPU and parallelization in general while the Discourse JS has a single thread.

Browsers can use some GPU acceleration, including for scroll, maybe there's a problem on this device so it's not being used or Discourse is written in a way that prevents it.
@danluu

@danluu

Google: Are 100% of users on iOS?Discourse: The influential users who spend money tend to be, I’ll tell you that ... Pointless to worry about cpu, it is effectively infinite already on iOS, and even with Qualcomm’s incompetence, will be within 4 more years on their embarrassing SoCs as wellI... I don't even know how to respond ​

@danluu According to geekbench 6, my phone (Moto g(9) play) is notably worse than the Tecno S8C. Yet, I don't experience nearly as atrocious load times on any of those sites. In fact, Twitter and Substack load in a perfectly reasonable time

I have a 30mbps wifi/landline connection. Yet, even when I switch to cell service and prefer 3G connection (which speed tests show gets about 3mbps), the difference is minimal.

What could the difference be? Is there anything I can do to get you more data?

@nickchomey That's interesting. I have an old moto X I could test that I didn't dig up (I thought about it, but I figured the newer Tecno Spark 8C would be in much wider use than a Moto X today).

I feel like I also owned some kind of Moto G phone at some point, although I think I gave it away and don't have it anymore, but I can see about that as well.

@danluu software optimization is simple, you just shift the leadership demographic in tech away from "parents had a vacation house"
@danluu iirc my site uses 80kb
@danluu wow holy shit it's <40kb
@danluu I understand there has to be a limit to the test, but Reddit is an interesting example, as it actually has two versions, old and www, and once again, old is faster.
@hruske @danluu The old one's also way more user-friendly.
@danluu Quite interesting how things compare, I guess it could be useful to have JS sizes vs. image sizes, for example Squarespace being bigger than reddit but managing to load on everything you've tested. (after 16s though, this is seriously bad)
@lanodan @danluu see @slightlyoff Performance Inequality Gap serie. JS is usually far worse because JS needs to be parsed, which ends up being atrociously cpu power hungry.
@danluu Re Discourse: I was fairly active on TheDailyWTF forums in the past – they used some really weird IIS-based forum software that had a ton of bugs, but we learned to live with them. Then they switched to Discourse, as one of the early adopters, and I somehow lost interest completely shortly afterwards.
I see Discourse (and NodeBB, which has almost identical interface) used on a ton of sites nowadays, but somehow the UX doesn't work for me.
@danluu it's not just slow devices, I've got a fairphone 4 and it still struggles with some sites, it's ridiculous
@danluu I literally just added a loading div to my game because it grew from 200kB to 500kB :)

@danluu I really enjoyed this post. Thank you for putting it together.

I think you might find the new zig standard library documentation web app interesting, since I made the controversial decision to have it fetch all the source code up front and then do all the content rendering locally. In theory, this is CPU intensive but in practice... even those old phones have really fast CPUs!

https://ziglang.org/documentation/master/std/

I'm curious how it fares with those old phones you have.

Zig Documentation

@andrewrk On the Tecno Spark 8C, this uses a fair amount of CPU up front (4.7s), but interaction is (relative to other sites using the same device) decently quick when you tap any target or scroll one of the pages if you scroll a page that has enough content to scroll (I didn't test the Itel P32 because the battery is basically dead and it needs to charge for a long time to be usable and I don't generally keep it charged)

I think that's really interesting. I'll add a bit about this in the post.