It’s a bigger problem on mobile, where, depending on the device and network, the cost can be “pretty extreme,” he said.
A gap that hasn’t been shrinking is the difference between high and low-end devices. The low-end market of devices in 2022 is processing, power-wise, similar to an advanced device back in 2014 — so the iPhone 6s is essentially like having a Moto E 30. He saw the impact at eBay since in e-commerce, page loads are critical.
1. Code Splitting/Lazy Loading
Code splitting and lazy loading can significantly help with weight, Carniato said.
“Almost every meta-framework or tool used today almost does this automatically for you at this point at the route level,” he said. “So you should be doing this already.”
One thing to understand about how frameworks hydrate is that anything the server-rendered will need to hydrate as if it was visible on the page, which is why developers show something else and swap it in. It does take some manual doing to make this work, he added, because if something is actually in the surrender DOM and it’s meant to be interactive, it will hydrate.
“Lazy loading doesn’t prevent it. It’s just the way these frameworks work, because they basically need to run the whole app down,” he added.
2. Use a Smaller/Faster Framework (Caveats)
Carniato took an interesting approach to comparing frameworks. He looked at their size when starting out and then as more components are added to the framework. The results were surprising, in that fast frameworks don’t necessarily stay fast.
“Yes, your baseline […] starts smaller, but people actually have to write code,” he said. “So at a certain point, the components make [a] much larger chunk of it.”
Some frameworks start small but as components are added, the frameworks start to approach each other. He used Svelte as an example.
“Svelte starts as the smallest, for example; by the time you get to 80 unique components, it’s actually larger than React and everyone else,” he said. “So most of the frameworks are actually very similar on scale size, and in fact, you can see the top line hopefully, which is at the beginning, which is React — it’s got the same slope.”
3. Progressive Enhancements
However, it’s not necessarily a replacement for other approaches to reducing code, because it creates a very different experience, he said.
So now instead of doing client-side navigation with some affordances, they have to reload the whole page and wait that seven seconds again, he added.
“It’s good, but it’s also not actually a complete win here, it doesn’t replace the problem,” he said.
4. Progressive Hydration
The idea behind progressive hydration is that the page hydrates on demand, as it’s needed, he said. Developers can attach some event handlers to the document ahead of the time when someone clicks on it and then do smart stuff with that. Sometimes it’s called selective hydration, he added.
Dan Abramov drew the above diagram for Carniato that attempts to show what happens if React hadn’t quite hydrated yet and someone clicks on a different branch (maybe not the one that React is currently loading or hydrated yet), then it would be smart enough to bail out of what it was doing and then prioritize that branch of the tree.
“It still had to go parent to child, but you could hydrate the middle instead of going across; and I think for me, nonblocking is very good in the state,” he said. “Sometimes that can also cause the total time to take longer, maybe you’re not going to notice it, but if you have CPU sitting there, chugging in the background, it can impact the experience somewhat.”