How Developers Measure and Optimize Web Performance
This post is meant to sensitize us on the importance of the performance of our web apps. If you are like me, when you started in software development, your initial concern was getting your code to run and for the application to go live. Later, you start to grapple with delivering the best user experience to users. This then leads you to start thinking of performance.
In this article, I attempt to share how to measure the performance of our application using an open-source tool known as Lighthouse. There are other tools in the market but this one is easily accessible as it ships with the Chrome browser. I will also share some practices that can help you improve the performance of your app. I will also attempt to explain some technical concepts that will be useful to us as developers.
What exactly is web performance?
The honest truth is that web performance is both subjective and objective. As a user, it is subjective. From a user’s point of view, web performance is about how fast a user perceives the site to be. That is, the user’s perception of whether the time it takes between the time s/he requests the content and the time until s/he feels the content requested is available and usable feels slow or fast.
Objectively, it is the measurable time, in milliseconds, it takes for the web page or web application to be downloaded, painted in the user’s web browser, and become responsive and interactive. That is, the objective time of when a request for content is made until the requested content is displayed on the user’s browser.
What is web performance optimization?
Web performance optimization is simply all the steps you will take as a developer to increase the subjective and objective web performance.
Why are we discussing performance and optimization?
It is important to discuss performance and optimization because of how fast or slow our app impacts our end users. And as developers, we are solving problems for our users. If we are not able to satisfy our users, we will lose money and product would suffer.
It is also important to factor in performance during development because our app will be used under different network conditions and on different devices with different capabilities.
This data shows us that there is a 2–5x difference in time to parse/compile code between the fastest phones on the market and average phones. This implies that while you develop with fast 4G on your MacBook or DellInspiro, your user might use your app on a 3G network with a device with a slow GPU. How do you accommodate that? That’s why you need to factor in performance while developing your apps.
How do we measure performance?
In order to develop with performance in mind, we need to be able to measure performance. How do we do that?
To show you how lighthouse works, I will demo it with a personal project. This app is live here:
Follow the following steps:
1. Launch a new Chrome tab in Incognito mode (Control+Shift+N). This is so that your chrome extensions (if you have any) do not interfere with the audits.
2. Type (or any app whose performance you want to measure) into the address bar and open up the Chrome developer tools using either of these commands: Command+Option+I (Mac) or Control+Shift+I (Windows, Linux).
3. You can open the developer tools section to the right as shown in the image below for convenience.
4. Switch over to the Audits tab. The Audits tab uses LightHouse. So with this, we will measure the performance of the app. Lighthouse will also provide insights on how we can improve performance.
Image showing the audits tab in Chrome Dev Tools[/caption]
For this audit, you can configure Lighthouse however you wish. In this instance, we want to audit the site for performance on a mobile device. We also want to simulate a slow 4G network and 4x CPU slowdown( That is, your current device performance slowed down by a factor of 4).
These metrics shown above are used to specifically measure how performant our app is. You can click on the learn more link on each to read more on each metric(I would not want to do that in this article so this doesn’t get too long).
By using the Audits Tab, we can know how performant our app is.
So how do we optimize the performance?
We can optimize the performance of our app at load time or runtime. In this article, I will be looking at load time.
As a developer, what I can do now to improve performance?
Write mobile-first CSS
This will give the browsers of smaller devices less work to do as the browser only needs to the calculations for their screen sizes.
Today, most web applications are built using frameworks/libraries such as React, Vue, Angular, etc. These libraries use tools such as Webpack or Browserify to bundle your application code. Bundling is simply the process of following imported files and merging them into a single file: a “bundle”. The idea of code splitting is to serve only the code needed for the routes or components or user actions that a user requests for per time(lazy loading) instead of serving all the application code at the same time. (eager loading).
How do you implement code splitting?/Code Splitting in details
Here is a simple example of the use of the dynamic imports syntax taken from the React documentation:
So, what the above means, is that the code the publications page will only be loaded when the user navigates to the route, ‘/publications’. Until the user navigates to this route, the code for the publications page is not loaded onto the browser.
Something similar is done in Angular’s routing as well. Below is an example from the Angular documentation:
In summary, when you code split based on routes, you serve only the chunks your users need per route.
See more on code splitting/Lazy loading in React here.
See more on code splitting/Lazy loading in Vue here.
See more on code splitting/Lazy loading in Angular here.
That’s quite a lot to take in.
So, now that we have looked at some code, what factors do we know that can affect the performance of our apps.
Device GPU of users.
The performance of our apps would always have a subjective feel to it. This is because it is an experience that no one metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as “fast” or “slow.”
In testing, we must pay attention to the little wins that cumulatively increase application speed and result in a better experience for the end-user.