As one advances through a Software Development career, concerns beyond writing code that works arise. In the world of web development, it becomes pertinent to not only build functional software but to also make them highly performant such that they are able to seamlessly deliver the desired experience while using minimal resources.
Ordinarily, this would be quite a large task as one can’t make projections about the resource consumption properties of an application without tools to simulate and measure various parameters.
In this article, we will go through an in-depth consideration of one of such tools; The Chrome Developer Tools. Specifically, we will examine the handiness of the Audits and Performance tab in evaluating web applications and discovering performance problems where they exist.
In order to make this a practical examination, we will be testing various techniques to seek out performance issues on Scotch.io and also resolve them.
To follow along with this tutorial, you need to have the Google Chrome browser installed on your computer and the scotch.io website opened in Incognito mode so as to be able to make references and try things out. We will be working in Incognito mode to ensure that the browser is in a clean state and our measurements are not influenced by the “noise” from installed extensions.
What is Performance?
As expressed on Wikipedia, web performance describes the speed with which web pages are downloaded and displayed on the user’s web browser.
When improving the performance of a website/web application, there are two main aspects of consideration:
- Load Performance
- Run-time Performance
We will pay more attention to Load Performance in this article. Load Performance refers to the performance of the page when it is loading. Our major objective is to identify performance issues that affect application speed and overall user experience.
Follow the steps below:
- Launch a new Chrome tab in Incognito mode (
- Type https://scotch.io into the address bar and open up the Chrome developer tools using either of these commands:
- Dock the developer tools section to the right as shown in the image below for convenience.
- Switch over to the Audits tab as this is the first area of concern. With the help of this tool, we will create a baseline to measure subsequent application changes as well as receive insights on what changes will improve our application.
The Audits tab may be hidden behind the More Panels arrow button.
Bear in mind that our primary objective here is to identify performance bottlenecks on Scotch and optimize for better performance.
A bottleneck, in Software Engineering, describes a situation where the capacity of an application is limited by a single component.
In this section, we will look at some ways to optimize for better load performance.
In performing the audit, we will make use of a tool called Lighthouse, which is an open-source automated tool for improving the quality of any web page in the areas of performance, accessibility, progressive web features, and more.
In the Audits tab of the Chrome dev tools, let’s configure the auditing tool. We have the following settings presented before us:
This gives us the option of toggling the user agent between Mobile & Desktop options. More than half of web traffic as of the third quarter of 2018 is generated by Mobile devices, thus we will be auditing Scotch.io on Mobile.
This setting allows us to select what quality of the application we are interested in evaluating and improving. In this case, performance is our only concern, so we can untick every other option.
This option enables us to simulate the conditions of browsing on a mobile device. We will be using the Simulated Fast 3G, 4x CPU Slowdown option. This will actually not throttle during the audit, however, it will help in calculating how long the page will take to load under mobile conditions.
This enables us to clear all cached data & resources for the tested page in order to audit how first-time visitors experience the site, so check this option if it isn’t already checked.
After configuring the audit as specified above, click on Run audits and wait while it prepares a detailed report of the site’s performance.
Analyzing the Audit Report
On completion of the audit, the report should look like this:
The number in a circle at the top right indicates the overall performance score of the site on a scale of 1–100. We currently have a 55, which indicates that there is a chance for improvement in line with the suggestions provided to get a higher score, thus getting better performance. Let’s break the report into sections and analyze them individually.
In the Metrics section, we find quantitative insight into various aspects of the site’s performance:
Directly below the Metrics section is a group of screenshots that show the various UI states of the page from the point of the initial query until when it loads completely:
The Diagnostics section gives us additional performance information usually indicating the factors that determine a web page’s load time:
Finally, the Passed audits section highlights the performance checks that were passed by the web page, hooray!:
In this section, we will now explore the report further to identify performance bottlenecks on the webpage as well as highlight possible solutions.
In this section, 5 performance issues were highlighted, let’s explore possible fixes:
First Meaningful Paint
The first meaningful paint tells us when the primary content of the page becomes visually available. According to the audit, it takes about 3.4 seconds before we see the main content. This can be confirmed by clicking on the View Trace button. This will take us to the Performance tab where we can go through the various UI states during the load period to confirm what happens at each specific time.
Notice that it is at this time that the page content becomes visible.
In order to improve this, we must optimize the critical rendering path of the page/overall application. This means that we prioritize the display of content as desired by the user in order to create a better experience and improve performance. This can be done by reducing the number of critical resources, the critical path length, the number of critical bytes.
This shows how quickly page content is visibly populated. This takes about 7.2 seconds as shown on the performance tab:
One way to fix this, like in the previously examined metric, is to optimize the critical rendering path. A second way is to optimize content efficiency. This involves manually getting rid of unnecessary downloads, optimizing transfer encoding through compression, and caching whenever possible to prevent re-downloads of unchanging resources.
First CPU Idle
Also known as First Interactive, this tells us when the page becomes minimally interactive (the CPU is idle enough to handle user input, like clicks, swipe, and so on). From the audit, this takes approximately 6.5 seconds. It is always a win to reduce this value to the barest minimum:
To solve this, we need to take the same steps as with the Speed Index.
Time to Interactive
This is the time it takes for the page to become fully interactive. Our audit reveals a whopping 6.9 seconds on this metric. Interactivity in this context describes the point where:
- The page has displayed useful content.
- Event handlers are registered for most visible elements on the page.
- The page responds to user interactions within 50 milliseconds.
Estimated Input Latency
This describes the responsiveness of an application to user input. The audit records approximately 170 milliseconds on this metric. Applications generally have 100 milliseconds to respond to a user input, however, the target for Lighthouse is 50 milliseconds. The reason for this disparity is that Lighthouse uses a proxy metric, that is the availability of the main thread to evaluate this metric rather than measuring it directly.
Once it takes longer than the specified time, the app may be perceived as laggy. You can learn more about this here.
In order to improve this metric, we could use service workers to perform some computations, thus freeing up the main thread. Another helpful measure is to refactor CSS selectors to ensure they perform fewer calculations.
As highlighted in the opportunities section we can improve performance by:
Avoiding multiple, costly round trips to any origin
Usually, when web pages load, they connect to other origins in order to receive or send data. To improve performance as in this case, it is best to inform the browser to establish a connection to such origins earlier on in the rendering process, thus cutting down on the amount of time spent waiting to resolve DNS lookups, redirects, and several trips back and forth until the client receives a response.
We can inform the browser of our intentions to use such resources by adding a
rel attribute to link tags as shown below:
<link rel="preconnect" href="https://scotchresources.com">
Note: On secure connections, this could still take some time, hence must be used within 10 seconds else the browser automatically closes the connection and all that early connection work goes to waste.
We have now successfully received a performance report on Scotch.io using the Audit tool as well as examined prospective solutions to the identified bottlenecks.
Load is not a single moment in time — 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.”
Performance is like a long train, with multiple separate coaches yet similar and united in purpose. In testing, one must pay attention to the little wins that cumulatively increase application speed and result in a better experience for the end user.
For even further reading, the Web Fundamentals section of the Google Developers site is a great resource.