31 ms·
For years website size was an acceptable proxy for user experience, but that's really not true today. Web browsers are much more complex about what they downloa
by billyhoffman 5y ago
For years website size was an acceptable proxy for user experience, but that's really not true today. Web browsers are much more complex about what they download, when, and how that impacts the user experience. Looking at page weight and say "that's bad" is too coarse of a perspective.
Is a page downloading a 600KB "main.min.css" that's blocking the rendering path? yeah, that's bad, especially when only 60% of the rules are used on your most common pages. Downloading 1-2 MB of blocking JS, also a bad experience.
Lazy loading a hero video while also using a "poster" attribute as a placeholder? :shrug: Asyncing in 800KB of 3rd party tags after onload that don't cause reflows or impact the Time-To-Interactive/Total-block-time? :shrug:
Even those 2 bad examples can be made better or worse. 600KB for a CDN? better. 600KB from the origin? worse. 600KB from a totally new hostname? bad. 600KB from a hostname you already have an active HTTPS connection to? better.
Not all resource weight is equal. You can't even say all weight for the same resource type (CSS, Images, Font, JS, JSON, etc) is equal. It depends when and for what purpose a heavy resource is requested. And yes, this still applies even for mobile connections that can suck, be slow, and have high latency.
Of course, there are still operational cost aspects here for the bloated sites. Bloated images on your CDN? Misconfiguring it so it's not using Brotli? Yeah, you can cut significant spend by applying the appropriate optimizations for sure.
To be clear: I hate bloated websites.
- dgb23 5y agoAlso evaluating and profiling all of these things and more has become much more convenient and accessible. Personally I tend to avoid third party frontend libraries where feasible for example, but we still need JS to give immediate feedback and to make bespoke designs work. But we found that reasonably bundled JS is almost never the problem. It’s almost always images, especially user generated ones. JS/CSS/rendering code that is unoptimized and uses the wrong approach can hurt too (often unrelated to actual size). And of course lack of caching. But all of those things have solid solutions that really pay off. There’s simply websites that have a ton of content or designs that you as the dev cannot control. But during concept/feedback/consulting you have to give those things some weight and try your best when things are decided. Edit: Myself and I bet most other devs hate bloated websites the most, even when we implement them. Because we suffer the most from performance and unnecessary complexity during development and testing. Especially when we need to turn off all of the goodies that make the website fast. Reminds me of another thing. Compatibility through code generation (babel) is one of the biggest offenders for JS bloat, especially when you need legacy support like IE11.
- wwweston 5y ago> It’s almost always images, especially user generated ones. After recently doing a lot of work on a system that takes user-originated images for the first time in a while, this has started to become my go-to check. I shouldn't have been surprised at how common it is, but I was and I hope from now on I'm thinking about optimization as soon as user-provided media comes up. I also think the tooling-takeover on the front end has had a real effect; it automates away decisions at development time in situations where you usually have ideal connectivity. Then when you're doing QA and realize that the site's heavier/slower than will work for some user-device profiles, you face sunk costs for decisions you didn't even really make so much as implicitly invoke. Possibly getting better as tooling gets less naive and more sophisticated about shaking out unused code, but I worry there's also a Jevons paradox that can come into play (your tooling is good at automatically optimizing out stuff you don't use? You might automatically use more of other stuff!).
- dgb23 5y agoThank you for pointing out the Jevons paradox. There is definitely a ton of that going on in web dev!
- zerkten 5y ago>> For years website size was an acceptable proxy for user experience, but that's really not true today. Web browsers are much more complex about what they download, when, and how that impacts the user experience. Looking at page weight and say "that's bad" is too coarse of a perspective. Has it really changed? Yes, browser perf was an issue then, but perhaps browsers have optimized away other issues. It is unclear to me if anything has improved over time for the large segment of users with limited or expensive bandwidth. This was a very large segment affected by bloated sites when the problem started being highlighted in articles like this one. Have bandwidth and latency issues been resolved for many people who had significant issues in 2015? I'm guessing 4G and the like have been able to penetrate areas fairly quickly, but I've not looked at global data on this topic for a very long time.
- giantrobot 5y ago> I'm guessing 4G and the like have been able to penetrate areas fairly quickly, but I've not looked at global data on this topic for a very long time. Just having 4G available doesn't mean much if the cells are congested, the networks have poor backhaul capacity, or just in a bad radio environment. There can also be a lot of jitter in latency even if there's decent bandwidth. A bunch of scripts can load fine but then grabbing that one necessary resource hangs and the whole page hangs. There's so many stupid interactivity blockers with big JavaScript pages that are made worse by poor network connectivity. Stuff like infinite scroll or blocking page visibility until an ad is visible breaks in jarring ways. High average speed is nice but cellular connectivity has issues in good conditions and a lot of unpredictability. Huge numbers of web users are on cellular data only (or shit public WiFi). I find too many websites ignore these users with fragile designs because of a preponderance of "works on my machine".