4 ms·
Also evaluating and profiling all of these things and more has become much more convenient and accessible. Personally I tend to avoid third party frontend libr
by dgb23 5y ago
Also 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!