Use tools to measure performance

Sam Dutton

There are several core objectives for building a performant, resilient site with low data cost.

For each objective, you need an audit.

There is a wide range of tools and techniques for auditing websites:

• System tools
• Built-in browser tools
• Browser extensions
• Online test applications
• Emulation tools
• Analytics
• Metrics provided by servers and business systems
• Screen and video recording
• Manual tests

Below you'll learn which approach is relevant for each type of audit.

Record resource requests: number, size, type and timing

A good place to start when auditing a site is to check pages with your browser's network tools. If you're not sure how to do this, work through the Chrome DevTools network panel Get Started Guide. Similar tools are available for Firefox, Safari, Internet Explorer and Edge.

Remember to keep a record of results before you make changes. For network requests, that can be as simple as a screenshot — you can also save profile data as a JSON file. There's more information below about how to save and share test results.

Before you begin auditing network usage, make sure to disable the browser cache to ensure you get accurate statistics for first-load performance. If you already do caching via a service worker, clear Cache API storage. You may want to use an Incognito (Private) window, so that you don't have to worry about disabling the browser cache or removing previously cached entries.

Here are some core features and metrics you should check with browser tools:

• Load performance: Lighthouse provides a summary of load metrics. Addy Osmani has written a great summary of key user moments for page load.
• Timeline events for loading and parsing resources, and memory usage. If you want to go deeper, run memory and JavaScript profiling.
• Total page weight and number of files.
• Number and weight of JavaScript files.
• Any particularly large individual JavaScript files (over, say, 100KB).
• Unused JavaScript. You can check using the Chrome coverage tool.
• Total number and weight of image files.
• Any particularly large individual image files.
• Image formats: are there PNGs that could be JPEGs or SVGs? Is WebP used with fallbacks?
• Whether responsive image techniques (such as srcset) are used.
• HTML file size.
• Total number and weight of CSS files.
• Unused CSS. (In Chrome, use the coverage panel.)
• Check for problematic usage of other assets such as Web Fonts (including icon fonts).
• Check the DevTools timeline for anything that blocks page load.

If you're working from fast wifi or a fast cellular connection, test with low bandwidth and high latency emulation. Remember to test on mobile as well as desktop — some sites use UA sniffing to deliver different assets and layouts for different devices. You may need to test on actual hardware using remote debugging, not just with device simulation.

Check memory and CPU load

Before you make changes, keep a record of memory and CPU usage.

In Chrome you can access the Task Manager from the Window menu. This is a simple way to check a web page's requirements.

Test first and subsequent load performance

Lighthouse, WebPagetest and Pagespeed Insights are useful for analyzing speed, data cost and resource usage. WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.

Save the results

• WebPagetest: test results each have their own URL.
• Pagespeed Insights: the online Pagespeed Insights tool now includes Chrome User Experience report data highlighting real-world performance stats.
• Lighthouse: save reports from the Chrome DevTools Audit panel by clicking on the download button:

  

Test for core Progressive Web App requirements

Lighthouse helps you test security, functionality, accessibility, performance and search engine performance. In particular, Lighthouse checks if your site successfully implements PWA features such as service workers and a Web App manifest.

Lighthouse also tests whether your site can provide an acceptable offline experience.

You can download a Lighthouse report as JSON or, if you're using the Lighthouse Chrome Extension, share the report as a GitHub Gist: click on the share button, select Open in Viewer, then click on the share button again in the new window and Save as Gist.

Use analytics, event tracking and business metrics to track real-world performance

If you can, keep a record of analytics data before you implement changes: bounce rates, time on page, exit pages: whatever's relevant to your business requirements.

If possible, record business and technical metrics that might be affected, so you can compare results after making changes. For example: an e-commerce site might track orders-per-minute or record stats for stress and endurance testing. Back-end storage costs, CPU requirements, serving costs and resilience are likely to improve if you cut page weight and resource requests.

If analytics aren't implemented, now is the time! Business metrics and analytics are the final arbiter of whether or not your site is working. If appropriate, incorporate event tracking for user actions such as button clicks and video plays. You may also want to implement goal flow analysis: the paths by which your users navigate towards 'conversions'.

You can keep an eye on Google Analytics Site Speed to check how performance metrics correlate with business metrics. For example: 'how fast did the homepage load?' compared to 'did entry via the home page result in a sale?'

Google Analytics uses data from the Navigation Timing API.

You may want to record data using one of the JavaScript performance APIs or your own metrics, for example:

    const subscribeBtn = document.querySelector('#subscribe');

    subscribeBtn.addEventListener('click', (event) => {
     // Event listener logic goes here...

     const lag = performance.now() - event.timeStamp;
     if (lag > 100) {
      ga('send', 'event', {
       eventCategory: 'Performance Metric'
       eventAction: 'input-latency',
       eventLabel: '#subscribe:click',
       eventValue: Math.round(lag),
       nonInteraction: true,
      });
     }
    });

You can also use ReportingObserver to check for browser deprecation and intervention warnings. This is one of many APIs for getting real-world, live measurements from actual users.

Real-world experience: screen and video recording

Make a video recording of page load on mobile and desktop. This works even better at high frame rates and if you add a timer display.

You may also want to save screencasts. There are many screencast recording apps for Android, iOS, and desktop platforms (and scripts to do the same).

Video-recording page load works much like the filmstrip view in WebPagetest or Capture Screenshots in Chrome DevTools. You get a real-world record of page component load speed: what's fast and what's slow. Save video recordings and screencasts to compare against later improvements.

A side-by-side before-and-after comparison can be a great way to demonstrate improvements!

What else?

If relevant, get a Web Bloat Score. This is a fun test, but it can also be a compelling way to demonstrate code bloat — or to show you've made improvements.

What Does My Site Cost?, shown below, gives a rough guide to the financial cost of loading your site in different regions.

Many other standalone and online tools are available: take a look at perf.rocks/tools.