How web bloat impacts users with slow devices:
How web bloat impacts users with slow devices:
@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.
@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/
@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 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.)
@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 quick typo notice:
@whitekiba @danluu currently replying from an android device with 1GB of RAM.
very usable.
@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 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
@[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.
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
@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.
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
@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 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 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.
@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.