Originally published in Streaver's blog.

Why should we even care about performance?

New machines and phones are more powerful than ever, internet speeds are rising, so, why should we care about delivering smaller bundles and lower load and interactivity times?

If your user-base is in countries with low internet speeds or lower-end devices the answer is simple, you should care because otherwise, you might not be able to even deliver the app to the users for them to make good use of it.

That was easy, now, what if your average user has a high-end phone and lives in a country with high-speed internet? Well, the answer is pretty simple too, just because they have powerful devices it does not mean you should kill their phones with megabytes of data and intense CPU tasks killing their batteries, you should be smart and use power just when you need it (if you can, of course).

The moral of the story is that to be a good developer you should also be mindful on all aspects, not only those that the end user see. You must care about performance independently of who is using the app, which device loads it or the time you have to wait for it to be ready.

Believe it or not, if you travel often you will experience that kind of problems more often than you think.

APIs for adaptability

Modern browsers like Chrome, Firefox, Safari, Edge, and others support some web APIs to help us adapt your apps to the user's capabilities, you can ask for Network information with the NetworkInformation API, this will even fire events when the internet speed changes to allow you to deliver very dynamic user experiences! That API also provides information about if the user has a "data saver" mode enabled, so it will allow you to be respectful of the user preferences.

The HardwareConcurrency API allows us to take advantage (or not) of multiple CPU cores, you can deliver very different experiences based on this number, for example, you can increase performance by increasing the number of Web Workers that take care of heavy loads on your app.

Talking about performance, we must mention the Performance API and the DeviceMemory API which provides important information about memory availability on the device. Just like the HardwareConcurrency API, you can use the APIs to deliver different experiences for different users, for example, you could do pagination in smaller chunks if the user will not support rendering heavy pages.

And lastly, the DateSaver API which allows you to be respectful of the user preferences and save data by loading different experiences based on this flag. I personally use this feature a lot, when I travel my internet provider is not very friendly with data caps and costs, so I love if web apps respect this preference instead of assuming I have unlimited data and just download all the things!

Some of the mentioned APIs are experimental and might not be available on all platforms. But don't worry you can check the availability with https://caniuse.com.

react-adaptive-hooks

This month Addy Osmani twitted about a new library created to take advantage of the previous mentioned APIs by using some very simple React Hooks.

The hooks provided are four, each one of them allows you to target different characteristics of the user's device and/or preferences:

import { useNetworkStatus } from 'react-adaptive-hooks/network';
import { useSaveData } from 'react-adaptive-hooks/save-data';
import { useHardwareConcurrency } from 'react-adaptive-hooks/hardware-concurrency';
import { useMemoryStatus } from 'react-adaptive-hooks/memory';

If you combine them you can come up with really interesting "patterns" that allow your apps to be faster or more respectful of user's resources. The react-adaptive-hooks repository includes a demos section which demonstrates some simple (but powerful) uses of the hooks. In the next section, I will briefly describe some "advanced" uses of the APIs.

Advanced uses of adaptability

Asking the user

As simple as it sounds (and depending on the type of application) you could let the user decide which version of the app they want to use, it could be a user preference! You can have a default based on the device capabilities, and let it up to the user from there.

An example of this could be a game, the user could decide to improve different aspects of the game, as an example, the user can choose different settings based on what experience they want to achieve. A lightweight experience but very fast level loading times for when they are abroad or have data caps active, or a heavy version for when they came back from their trip or when the new billing cycle starts and the data caps are not there anymore.

Parallel processing

Imagine you have an app with image processing capabilities, like squoosh.app which allows you to process and optimize images online. You could implement a feature of bulk processing of images, you just let the user select a bunch of images and you spawn new Web Workers based on the number of CPU cores you have to process them, moreover, you can monitor the memory usage/availability and adapt your algorithms to provide the user with a nice experience allowing them to get what they need in a reasonable amount of time.

Landing pages and conversion funnels

It is a fact that many companies might not have the resources to get into this type of fine-tuning practice on every single page, but maybe you can use the adaptability APIs in very specific places to provide the average usage paths with better performance. As an example, you could optimize the landing page, with this you engage the users right away, and while they are reading your landing page details you can slowly load the rest of the app in the background.

After you have the landing you can focus on the rest of the conversion funnels of the app ensuring the users have nicer experiences throughout your site's funnel.

Conclusions

Performance is not just a whim, it affects your business, it can have an impact on sales or on user reviews, but it takes time and money to get it right.

I am confident to say with 100% certainty that it does not matter for which company or project you work, you will have limited resources, it could be 1K or 1M dollar budget, but you have a limit. So, for this kind of performance problems, which are never-ending problems that can affect every single part of the application, the important thing is choosing the right battle.

Now that you know about these APIs for adaptability you can choose the battle you want to fight with the right tool.

I know that this was not a "silver bullet" post, but the idea behind it was to tickle your brain into thinking how or where you can apply these techniques, I hope it served its purpose.

Happy performance tunning! 🚀