Using Google Chrome to Tune Your Web App, Part I

Introduction to Auditing with DevTools

In this series, I will try to help new web developers by demystifying the new Audits panel introduced in Chrome 60. Please grab a cup of tea and join me for a ride in Performance Auditing!

What Is a Performance Audit?

I can’t find an acceptable definition of performance audit, or even audit, on the web, so I will have to create my own here.

Performance Audit : noun: An assessment of the appropriateness, functionality, accessibility, and behavior of a thing or part of a thing, usually, but not limited to, software and/or its components, and how these metrics affect the perceived or real speed of the software as a whole.

Let’s break this down for the layperson, into its pieces.

1. Appropriateness  — whether it is appropriate for the context of the software. This is an extremely biased metric, and should be done manually, via code review or user testing.
2. Functionality  — whether the app functions in its expected ways. This metric also includes whether it has any side effects or undesirable functionality. For instance, can a user delete the entire database? This metric can be tested via automated test suites and manually. This is a bit biased, but it should really be used to protect against unwanted destructive behavior.
3. Accessibility  — whether or not people of all physical types can access your content. Can the colorblind see your site and use it well? Can the hearing or visually impaired use your site?
4. Behavior  — the way the site is organized and designed; how it functions and how users interact with it. Does the site function well and can users perform tasks on your site relatively quickly? Do they search around for menus and actions?

DevTools Welcomes a New Member!

Google’s web browser, Chrome, turned 60 this year (in versions, not years)! With this update, Google added Lighthouse directly into its free browser! You can access this amazing auditing tool via the DevTools’ Audits tab with Shift+Ctrl+i. Try it now!

Lighthouse is a fantastic tool for auditing your web site or web app. It has (relatively) clear descriptions of issues scanned for and found, along with links on how to fix those problem areas. There are currently 4 major areas checked and scored, which we will be going over in detail. However, before we begin, we need to figure out a few things first.

Do I NEED an Audit?

This is the very basic question you need to answer before you go any further. The answer to this question is almost always “Yes.” Almost. You really shouldn’t worry about it if you are doing a project for your local crochet club or high-school band. Performance tuning may be more work than it’s worth in this case. However, if you are designing a high-traffic web site or a web app with a complicated backend or frontend, you definitely should focus on your frontend performance, if only to eliminate it as a problem source for slow responsiveness.

TL;DR: The Quickest Quick Start

If you don’t feel like reading any more, or want to jump right in, here is the quickest run-down of Chrome’s new audit tool.

Open the Audits panel and click the button. Next, Select the desired audit from the given list and click the Run Audit button. After a few minutes, the test will complete and you will be given a rundown of all the checks performed. The failing checks will have a red X to the right of the name. To fix this test and find out more, click the expand arrow on the left of the test name, and read the description. Then click on the Learn more link to read even more about the check and why it is important. Follow every link on these pages and you will get an understanding of what you need to do in order to make your site more performant.

The 5000-Foot Overview

Now that you have a basic understanding of how to use the new Audits panel, I will start the hand-holding part of this guide.

Once you open the Audits panel, you will see a button that will allow you to start the audit, by selecting the audits you want to perform. These audits will be given top rank in the results pane. It will take a while to run the audit and your web page may do some weird things, but let it run.

When the audit is done, the Audits panel will fill in with a bunch of data. At the very top of this panel, you will find the scores, from 0–100, of the various audits you selected. After that, each audit is broken down into the individual pieces of that audit. To understand what they are, click on the expand arrows and more information will be presented. Most of these have a Learn more link that will take you to various documentation on that particular test. That documentation will usually have links to even more articles and documentation on how to fix whatever issue is causing the test to fail. You should read all that, but I am here to help you digest it in this series.

What Matters Most

In today’s world of high-speed internet and instant access, it is vitally important to put on the air of speed, even if your app isn’t as speedy as it appears. This metric is often called “first to paint.” The best way to do this is to load what is essential to your app as quickly as possible. I cannot stress this point enough — DO NOT EVER USE A LOADING SCREEN! This can and may fool some auditing tools, but it is never ever a good idea (you can’t fool your users!). If you have parts of your app that take a while to load, load the components individually. For example, if you have a lot of data that needs to load in a list, load each individual item in the list separately, and load only what your user can see right then. If the user then scrolls, load more items. This technique is often called “infinite scroll” and can be implemented on modern browsers using the Intersection Observer API. More about this later, though.

In order to appear speedy, your site needs to load a UI the user can see very quickly. If you want your app to BE fast, you need to focus on a different metric, where the user is able to actually interact with your application. This metric is simply called “first to interactive.” You can use metrics (Google Analytics can do this) to determine what users do most often when they come to your site. Once this is determined, you should focus on the load time for this action or component.

Both of these ideas are present in the idea of a Progressive Web App. Progressive, in this context, refers to the loading of your web page. Progressively load resources as they are needed, not all at once. This usually means you should work primarily in web components, vanilla JS, and decoupled CSS. You should also minify these resources to speed up load time, as they tend to block rendering of your page until they load. I will cover what render-blocking means in more detail in future articles in this series.

More Reading

I hope you now have a basic understanding of how to use Google Chrome’s new Audits panel to make your site more performant. This is only a cursory overview, at best, so please read the other articles in this series to find out more details and caveats to performance-tuning your web apps!

1. Part II of this series, Profiling Progressive Web Apps (coming soon!)
2. Part III of this series, Profiling Web App Performance (coming soon!)
3. Part IV of this series, Profiling Web Accessibility (coming soon!)
4. Part V of this series, Web App Best Practices (coming soon!)

Still More Reading

There are tons of other awesome resources online, including the Mozilla Developer Network documentation for web standards, which is probably the greatest resource for all things Web. Here are a few of my other favorites.

1. Lighthouse Documentation
2. Google Developer Web Fundamentals
3. Google Chrome DevTools Documentation
4. Totally Tooling Tips: Lighthouse (youtube video)

More to come…