1. Introduction to Software Performance
Today we're talking about is his experience optimizing the front-end for the user. Software performance is a measure of how well your application is running, performing its task, and using system resources. On the front end, software performance includes how users feel about the application. Passive performance is a subjective measure of how well the user thinks the application is performing. It can be indirectly measured through bounce rates, which indicate if users are dropping off after a few seconds. To improve passive performance, you can reduce the time between user entry and website loading by using a shared cache.
Hello, everyone, and thank you for coming to my presentation. Today we're talking about is his experience optimizing the front-end for the user.
My name is Chinayan Onwebu. I am a senior software engineer at HubSpot. What is software performance? We all know what software performance is, or at least we have an idea. This is basically a measure of how well your application is running, how well it's performing its task, and how well it's using the system resources that are available to it.
On the front end, however, software performance is all this, plus how users feel 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 front end is running for the user, we measure performance of the front end 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 users feel about your application. There are ways to measure it indirectly. First, you can use bounce rates. If you get 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. But usually, it's a sign of poor performance. Users think that your application is performing poorly. Research has shown that users will abandon a website between three and five seconds after waiting for the website to If your application does not show content in the first five seconds, there is a very high chance that you are going to lose a lot of users.
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. We want to use a shared cache, for example. A shared cache is a cache that is shared between users.
2. Improving Software Performance
If one user visits a page already cached, a second user will retrieve the cache. Using HTTP2 can massively improve performance, especially for resource-heavy websites. Preloading important requests and using a CDN like Cloudflare can also enhance performance. Server-side rendering allows users to see content immediately, improving passive performance. Avoid blocking the user by using tricks like avoiding CPU-intensive tasks on the frontend and loading resources gradually.
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 have 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. 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 these are passive your website, how they perceive the application and one of those is to avoid blocking the user.
3. Optimizing Frontend Performance
When performing CPU intensive tasks on the frontend, avoid blocking the main thread. Load only necessary resources at the beginning to prevent rendering blocking. Use progress bars instead of spinners to provide users with a sense of progress. Implement optimistic patterns to mark tasks as completed before they finish. Avoid blocking users by allowing them to continue using the application while waiting for tasks to complete. Consider the changing expectations of users throughout their interaction with the application.
So, if you are performing some CPU intensive tasks on the frontend, let's say 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 good 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 script 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 explain 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's 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 parts 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're 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 at 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.
