As web developers, we have an array of tools available to measure the performance of the sites we build. Tools like PageSpeed Insights, YSlow, and Pingdom have been our go-tos for years — yet something has never been quite right. How many times have you seen a site with poor metrics load in what seems like a split-second while sites that play by every single rule can be the opposite? The answer lies in what none of the tools above measure: perception. That’s where Lighthouse comes in.
What is Lighthouse and why is it different?
Lighthouse is a new set of tools that shed a different type of light onto various aspects of a site, with one of those items being performance. Instead of using a rigid set of assumed best practices and seeing which boxes your site marks off, running a performance test in Lighthouse invokes a process that is more akin to the users perception of how quickly content is loading.
While we often spend our days developing on powerful machines and high-bandwidth connections, we can begin to forget how important it is to make sure our sites are performing well on phones and tablets. These devices lack the same processing power and may be on connections with less available bandwidth. When running a test within Lighthouse, the CPU and network connection are throttled which helps remind us how important it is to optimize our sites for all devices.
In addition to performance metrics, Lighthouse also includes tests for Progressive Web Apps, Best Practices, and Accessibility. These are items that are often not covered by other tools yet play an important role in both user experience and SEO.
How to run Lighthouse
As of Chrome version 60, Lighthouse is built into the “audits” panel within the developer tools. Since Lighthouse does not require an external server to run, it’s possible to perform tests in local development environments. This greatly speeds up the process of making performance changes as deploying to a publicly accessible server is no longer necessary.
Additionally, Lighthouse can be installed as an NPM package and run from either the command line or as part of any build process based on Node.js.
How to interpret the performance metrics
While slightly less critical than the first paint, the time it takes a browser to fully load a page is also important. Lighthouse has two metrics for this: First Interactive and Consistently Interactive. On devices with less CPU power the site can potentially feel sluggish to users since the browser is still loading assets while they’ve begun to interact with it. Again, the goal here is to optimize what the browser needs to load and oftentimes the culprit is images. By ensuring that images are properly sized for different types of devices and waiting to load images until they are nearly visible we can reduce the amount of assets required for the page to be completely loaded.
Finally, the Diagnostics section is small, but contains a very useful item called the Critical Request Chains. The Critical Requests Chains item shows you exactly what resources are needed in order to start the first meaningful paint along with their respective sizes. By taking steps to reduce the chain length and also reducing the amount of data that is loaded, your first meaningful paint time will improve.
Is Lighthouse the new standard in performance metrics?
While we haven’t read anything specifically denoting Lighthouse as the new standard in performance metrics, its emphasis on user experience is something that should make it one of your frequently used tools. Over the past few years, Google has put an increasing emphasis on mobile performance, and adjusting your site to reach the highest score possible in Lighthouse will certainly not harm your rankings.
We find that Lighthouse has more merit in its recommendations than other tools do. It doesn’t fixate on elements that we can’t control such as expires headers and redirects on external scripts. Instead, it supplies me with actionable items that end up having a significant impact on site performance.