Hello everyone and thank you for coming to my presentation. Today we are talking about performance user experience, optimizing the frontend for the user. My name is Chinaya Onwebu. I am a senior software engineer at HubSpot.
What is software performance? We all know what software performance is, at least we have an idea. This is basically a measure of how well your application is running, how well it is performing its task and how well it is using the system resources that are available to it.
On the frontend, however, software performance is all this plus how the user feels about the application. So if the user doesn't feel good about the application, no matter how fast your application actually is, your application is not performing well.
Because the frontend is racing for the user, we measure performance of the frontend in relation to the user. So we call this passive performance. This is a subjective measure of how well your application is performing, how well the user thinks your application is performing.
Passive performance is very difficult to measure. You cannot measure it directly. There is no way to tell how a user feels about your application. There are ways to measure it indirectly. First is you can use bounce rates. If you are getting a lot of bounces, you are getting a lot of users that are dropping off after the first few seconds on your website. It's usually a sign that your application is not performing very well. Users think that your application is slow. Maybe the pages are not loading. Of course, it could also be some other problem. Maybe it's not the content that they are expecting. That usually is a sign of poor performance or users think that your application is performing poorly.
Research has shown that users will abandon a website between 3 and 5 seconds after waiting for the website to load. So if your application does not show content in the first 5 seconds, there is a very high chance that you are going to lose a lot of users.
So how do we actually improve the passive performance of our application?
You can always improve passive performance by improving actual performance. First of all, you want to reduce the amount of time between when the user enters your website, presses enter, and when your website actually loads. So we want to use a shared cache, for example. A shared cache is a cache that is shared between users. So if one user visits a page and this page is already cached, a second user visits the same page, the second user will retrieve a cache of this page. You can also use HTTP2. HTTP2 will massively improve your performance. This is especially true if your website loads a lot of resources. This includes websites that serve a lot of images, for example, or websites that load a lot of scripts, a lot of css. HTTP2 will make loading resources in parallel to be much, much faster than HTTP1.
You can also preload important requests. There are several ways to do this. Preloading important requests will make your website or your application feel snappier to the user. Using a CDN will solve a host of issues on your application right out of the box. Using cloudflare, for example, will give you shared cache without you having to do anything. It will also give you HTTP2 without you having to do anything.
Finally, you can use server-side rendering. Server-side rendering makes sure that when the page loads, the user sees content immediately. So the user doesn't have to wait for all the javascript to load before they can see the content of your website. So using server-side rendering, users can already see the content, and then you can inject the script, hydrate the page later for user interaction. Then you can also improve passive performance directly by doing some tricks. These tricks do not change anything in your website. They do not change how your website actually performs, but they kind of change how the user perceives your website, how they perceive the application to be performing. And one of those is to avoid blocking the user. So if you are performing some CPU-intensive tasks on the front end, unless you are rendering images, you should avoid blocking the main thread.
Always use worker thread for any task that will take more than a few milliseconds. The gold standard is 16 milliseconds. If it's going to take more than 16 milliseconds, you should move it to a separate thread. You should not block rendering. Blocking rendering is very, very easy to do and very difficult to avoid. But one simple rule to avoid blocking rendering is to only load the resources that you need at the beginning and then load the rest later. So in webpack, for example, you can split your scripts into chunks, and then you can load only the important chunks first and then load the other chunks later or as they are needed. This way, you will not block the rendering of the page. You only request what is required at the beginning. You can also avoid using spinners and use skeletons instead. Spinners make users think that your website is slow. It is psychological. They do not know what they are waiting for. They just know that they are waiting for something. When it's possible, try to use progress bar instead of just a spinner. Progress tells the user the actual progress of what they are waiting for so that they are not just left in the dark. Use optimistic patterns. There are a lot of resources online that explains what this means. When you use optimistic patterns, you mark a task as completed before it's actually completed. And only when it fails, you actually tell the user that this has failed. Gmail is a very good example of this. When you send a message, Gmail actually tells you that the message has been sent before the mail has been sent. It makes you feel as if Gmail is instant, but it is not. Don't block the user. This is a very common mistake.
What does it mean to block the user? If for example a user submits a form on your application and then you show a full screen please wait spinner, telling the user to wait until the form is submitted before they can continue. This breaks the
user experience and this makes the user feel that your application is slower than it actually is. Instead of doing this, you can show a notification or you can allow the user to use other paths of the application while waiting for this form to submit. Finally, you should note and keep it in mind that the user expectation changes often while they are on your application. The expectation of a user that just arrived on your application is very different from the expectation of a user that is on the checkout page. New users are less patient than users that are already committed to whatever you have to offer. So you should keep this in mind and this will help you. Thank you very much for attending and hope to see you again next time.
