July 17, 2019
Web is so much more than pretty pages
When we think about how a user will interact with our product I feel like sometimes we focus more on the visual part of the experience when there is so much more to it that is left without that much attention from us, web developers. In this post, we’ll explore some aspects that are crucial to the user experience that deserve more attention than they’re usually given.
User has a device with an internet connection that they will use to access your application and interact with it.
Now, the last part that involves interaction is, I think, currently in pretty good shape. We have design systems,
UI/UX Designers, best practices, etc. We’ve come far in this aspect of web development comparing to
But in other parts? I think we can and must do better.
Let’s see how other parts impact user experience and what we can do about it.
The world is mobile. Mobile devices overtook desktop and they’re not going anywhere. What does that mean for us? It means that we are dealing with low-power processors with a limited amount of RAM and GPU power.
In a mobile world internet connection can be slow and unreliable. It means that downloading resources takes more times and can fail.
So what can we do about it
We have to care. Care about all the users that don’t have a brand new fruity laptop with a gigabit connection. Considering all the factors listed above, I think we need to focus on performance and size of our applications.
Making users wait for our 10MB of node_modules in a single bundle is not acceptable.
Ship only what is needed
How exactly? The good starting point is checking the dependencies you bundle. Make sure you’re not sending duplicated dependencies. Webpack bundle analyzer is your friend. Check your lockfile (yarn.lock npm-lock.json) to find what versions of the dependencies you have installed.
Next, check out what you are shipping. Maybe you don’t need that huge library if you only use it once or twice. Check if it supports code splitting. Potential candidates are libraries like lodash or moment. Consider using more modular alternatives like date-fns
It is our moral obligation to deliver resources that users need. Check every request your app does. We can not afford to send the junk.
Code split aggressively
Code split your app. It has never been easier to code split your code. Import modules dynamicaly if you don’t need them immedeately. Using React? Great! Code-splitting feature is present in the form of React.lazy function.
Measure code coverage
How to verify that you are shipping only what needed? A good metric is how much code is used during the page load.
Head over to the Coverage tab in the Chrome DevTools and press reload. It will tell you how much of your JS/CSS was used and will highlight unused code in the
But keep in mind that it’s probably not reasonable to expect 100% code coverage just after loading page.
Measure in-app performance
Get to know Performance tab in DevTools well, it will help you to understand what happens in your app under the hood. Make sure that you don’t have long unneces sary tasks. If you can, defer them with idle callbacks.
Select CPU throttling and click around your app and measure if any interaction takes more than 100 milliseconds. Found laggy spot? Trace it and cut away all the code that is not needed immedeately after an interaction.
Learn how caching works. Check if any request can be cached. Can you affect headers for that response? Can you cache it in js? Do it. It is our job to make sure every request we are doing is actually needed.
Some closing thoughts
In our neverending journey of delivering more and more features, we can sometimes forget about something as essential as the performance and size of our apps. This lack of attention can lead to big, slow and barely usable apps even if they have pretty buttons.
Blog by Oleksandr Dubenko