Understanding Audit Performance Metrics w/ DevTools
Just as the adage goes “measure twice, cut once,” so must we “measure twice and optimize once.” Chrome DevTools is our toolbox, and before we start optimizing, we must first learn how to measure our site’s performance. So let’s start our focus with DevTools’ version of measuring tape, the Audits tab.
Audits
Like measuring tape, the Audits tab is a pretty straightforward tool.
At a glance, you’ll have a good idea of how to use it. The Audits tool is a versatile tool. Other than measuring performance, you can also use this tool to measure your site’s best practices, accessibility, and SEO. Furthermore, you can tweak your audit to simulate a mobile environment. For our purposes, we will only be focusing on the Performance audit. Someday in the future, I will dive into the other audit types in a different post.
Before Running an Audit
Before running the audit, there are a couple of things you should know.
- Make sure you are running the audit on the staging or production URL. The goal is to get as close to a real-world environment. Doing so will give you a more accurate measurement.
- Make sure to run the audit from an incognito window to prevent Chrome extensions from interfering with accurate scoring.
After Running an Audit
On measuring tape, we measure in inches or centimeters, and in Audits, we get a grade between 0 and 100. The higher the rating, the better the performance. It’s also color-coded red, yellow, or green, which gives you a visual representation of how proud or disappointed your parents would be if you had brought home this grade. Like a parent with high standards, if you score anything less than a 90, then you have room for improvement and less than 50, and you will be grounded until your grade improves.
Below the score is where things can start to get a little confusing. It’s broken down into four sections, Metrics, Opportunities, Diagnostics, and Passed Audits. Metrics breaks down the six measurements used to grade you. The Opportunities section gives you suggestions to improve. Diagnostics provides you with additional useful information, but these suggestions don’t necessarily directly impact the performance of your website. Lastly, Passed Audits, gives you peace of mind by letting you know what you’re doing right.
Metrics
The score you got above does not tell the full story. The six measurements found in the Metrics section are used to calculate the score. At first glance, it’s not immediately clear what these mean, so let’s dive in and see what kind of impact they’ll have on your site.
First Contentful Paint (FCP)
FCP metric measures how quickly something gets rendered onto the screen. This parameter measures the initial time from the navigation to the site until the first bits of content appear on the screen. Ultimately this is the time it takes before users could start seeing content on the page.
Content in this context refers to any text including those with pending web fonts, images (including background images), non-white canvas or SVG, that the browser has to render initially. However, this excludes any content in iframes.
How to Improve FCP
To speed up FCP, we need to speed up the download time of the resources or reduce the amount of work done in the javascript, or CSS that could block the browser from rendering content.
- Minimize the number of render-blocking external stylesheets and scripts upon which the page depends. See Render-Blocking CSS and Loading Third-Party JavaScript.
- Use HTTP Caching to speed up repeat visits.
- Minify and compress text-based assets to speed up their download time. See Optimizing Encoding and Transfer Size of Text-Based Assets.
- Optimize JavaScript bootup and reduce JavaScript payloads with tree shaking or code splitting. The goal is to do less JavaScript work on page load.
Source: Google
First Meaningful Paint (FMP)
First Meaningful Paint is the paint that takes place after the most significant visible on-screen layout (aka., above the fold) change has happened, and web fonts have loaded. It measures the time it takes before the most visible parts of the page are onscreen. To lower your FMP score, you’ll want to speed up the time it takes to get most of your content on-screen.
How to Improve FMP
To optimize, you should learn the process the browser uses to get around to rendering things on the screen, known as the Critical Rendering Path. The browser uses this process to convert HMTL, CSS, and Javascript into the pixels we see on screen. It’s a dense topic, so I’ll invite you to learn more. There is a great FREE course on Udacity that goes into this topic into detail. The visualization below should give you a rough idea of an optimized Critical Rendering Path.
Below the Metrics table, you will see a rough rendering timeline.
Quick Tips
- Improving FCP should also help benefit this metric.
- Optimize JavaScript bootup and reduce JavaScript payloads with tree shaking or code splitting. The goal is to do less JavaScript work on page load.
- Minimize the number of render-blocking external stylesheets. See Render-Blocking CSS
- Reduce the load on the DOM by Incrementally Loading HTML.
Speed Index
One of the most straightforward metrics to understand. Speed Index is a measurement of how quickly the contents of a page are visibly populated. From the start to end, it will tell you how fast did your page load.
How to Improve the Speed Index
- Improving FCP and FMP
- Optimize or defer Backend API calls that you make on page load.
- Pay attention to all your file sizes. Try to reduce the file sizes of your HTML, CSS, Javascript, Images, or any other file you might be loading.
First CPU Idle (FCI)
This metric measures how fast it takes before your page is quiet enough to interact. You may have noticed that on some websites, you can start scrolling and clicking around before all the elements have finished loading. Vice versa, you can also have a page that appears to have loaded, but you’re frustratingly clicking around trying to make something happen.
How to Improve (FCI)
Like all the other measurements, this metic benefits from the same optimizations provided above. Use this metric to inform you of how busy your site is before its minimally interactive, and pay special attention to your javascript. The more your CPU is doing, the more likely you are to score poorly here.
Time to Interactive (TTI)
Like the First CPU Idle measurement, this metric measurement goes a bit further by measuring how long takes before a page is fully interactive. Specifically, this means.
- The page has displayed useful content, as measured by the First Contentful Paint metric.
- Event handlers are registered for most visible page elements.
- The page is responsive to user interactions within 50 milliseconds.
It’s possible to optimize content visibility at the expense of interactivity. Use this metric to give you insight into whether the site appears to be ready vs. being useable.
How to Improve TTI
To improve your TTI score, defer or remove unnecessary JavaScript work that occurs during page load. Google has some great resources
- Optimize JavaScript Bootup
- Reduce JavaScript Payloads with Tree Shaking
- Reduce JavaScript Payloads with Code Splitting.
As an added help to debug trouble spots in your javascript, I invite you to check out the User Timing API, which can help you measure your app’s Javascript performance and display the result in your Audit Report.
Max Potential Input Delay.
The FCI and TTI measure how long before your site is minimally or fully interactive. However, this metric will measure how long the delay(aka Input Lag) your user might experience when it attempts to interact with it for the first time. It’s a representation of the potential frustration and pains for your users when interacting with the page. For that reason, this metric is more valuable by measuring what actual users are experiencing. Using real-world data for this metric will be infinitely more useful to you.
How to Improve Max Potential Input Delay.
As with the other interaction metrics, this also benefits from those suggestions. Keep in mind, that Server-side rendered (SSR) JavaScript apps and iframes can cause this metric to perform poorly.
View Trace
As a bonus to all the measurements above, you’ll get a convenient button at the bottom labeled View Trace. Clicking this magical button takes you to the Performance tab. This tab is a tool all on its own, and it contains a plethora of extra data, it displays a raw timeline of events, such as what code was running, which events fired, API calls made, and the site’s frame rate. It even shows you when on the timeline, the FCP and FMP happened. The real power of the Audits will come from understanding this Performance tab, which I will cover in my next post.
Additional Information
If you're using Ruby on Rails or Angular 1.x, the links below will offer you quick solutions, to common optimization problems that will directly impact your Audits Score.
