Alex Russell made some interesting notes about performance and how it impacts folks on mobile:
[…] CPUs are not improving fast enough to cope with frontend engineers’ rosy resource assumptions. If there is unambiguously good news on the tooling front, multiple popular tools now include options to prevent sending first-party JS in the first place (Next.js, Gatsby), though the JS community remains in stubborn denial about the costs of client-side script. Hopefully, toolchain progress of this sort can provide a more accessible bridge as we transition costs to a reduced-script-emissions world.
A lot of the stuff I read when it comes to performance is focused on America, but what I like about Russell’s take here is that he looks at a host of other countries such as India, too. But how does the rollout of 5G networks impact performance around the world? Well, we should be skeptical of how improved networks impact our work. Alex argues:
5G looks set to continue a bumpy rollout for the next half-decade. Carriers make different frequency band choices in different geographies, and 5G performance is heavily sensitive to mast density, which will add confusion for years to come. Suffice to say, 5G isn’t here yet, even if wealthy users in a few geographies come to think of it as “normal” far ahead of worldwide deployment
This is something I try to keep in mind whenever I’m thinking about performance: how I’m viewing my website is most likely not how other folks are viewing it.
The problem here is using react, it’s strength is also it’s weakness. The VDOM for reactive programming kills low end CPUs even more powerful ones. In some ways react developers admit this by adding workarounds for reducing impact of this. Other toolings such has svelte have no such problems and these sites have blistering performance on mobiles.
Say no to 5G!
Phones are not developing fast enough any more, the diffrence between the next flagship to the current one is hardly noticeable. The question is if the price performance ratio anymore a purchase reason.
Tools that prevent sending first party JS prove that oftentimes, the sent JS should be used for building and has nothing to do on the frontend.
It’s like if you send Sass code and the Sass JS interpreter to the client instead of compiling it beforehand. Works for sure, but what for?
JS sent to the client should always be sent when it can’t be executed on the server.