Thursday, 17 January, 2019 UTC
Summary
As one advances through a Software Development career, concerns beyond simply 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 utilizing minimal resources.
Ordinarily, this would be quite a herculean task as one cannot simply 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.
This article is a follow up on this article and you might need to read that article to easily understand some of the proposed solutions here.
Requirements
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 simply 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 simply 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.
Getting Started
Follow the steps below:
- Launch a new Chrome tab in Incognito mode (Control+Shift+N).
- Type https://scotch.io 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).
- 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.
Load PerformanceA bottleneck, in Software Engineering, describes a situation where the capacity of an application is limited by a single component. Just as the neck of a bottle tends to slow down the overall water-flow of the bottle.
In this section, we will look at some ways to optimize for better load performance.
The Audit
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 etc.
In the Audits tab of the Chrome dev tools, let’s configure the auditing tool. We have the following settings presented before us:
Device
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.
Audits
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.
Throttling
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.
Clear Storage
This enables us 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 sit back for about 10 - 30 seconds 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:
In the opportunities section, we see a list of specific steps to take in order to improve the site’s load performance:
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!:
Optimization solutions
In this section, we will now explore the report further to identify performance bottlenecks on the webpage as well as highlight possible solutions.
Metrics section
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 as shown below.
Note: You can get more information about each highlighted metrics by hovering over it.
Solution
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. Learn more here.
Speed Index
This shows how quickly page content is visibly populated. This takes about 7.2 seconds as shown on the performance tab:
Solution
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 (i.e the CPU is idle enough to handle user input e.g clicks, swipe etc). From the audit, this takes approximately 6.5 seconds. It is always a win to reduce this value to the barest minimum:
Solution
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.
Solution
To fix this, we’d need to defer or remove unnecessary JavaScript work that occurs during page load. This can typically be achieved by sending only the code that a user needs through code splitting and lazy loading, compression, minification, removing unused code and caching. You can learn more here.
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 i.e 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 to as laggy. You can learn more about this here.
Solution
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.
Opportunities section
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.
Solution
We can inform the browser of our intentions to use such resources by adding a
relattribute to link tags as shown below:<link rel="preconnect" href="https://scotchresources.com">ConclusionNote: On secure connections, this could still take some time, hence must be utilized 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."
Give your own websites a try and let us know what you've found!
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.