PageSpeed Insights Is Now Powered by Lighthouse: How to Read the New Audit?

December 17, 2018 by Alice Orru

Share the post

• Share on Facebook
• Share on Twitter

Comment 9

Last November, Google released v5 of its PageSpeed Insights API, which now implements Lighthouse technology and integrates field data provided by the Chrome User Experience Report (CrUX).

This new version got a mixed response from the public: while some people started to see PSI scores skyrocketing, others plunged in despair looking how their scores dropped 😱

If you follow our blog since the beginning, you know that we believe that a reliable web performance optimization score shouldn’t depend on PageSpeed Insights only.
But since Google’s tools are among the most used when it comes to running a performance audit, let’s see together what changed with the new PageSpeed Insights, and which key points you should always keep in mind when pondering its recommendations.

Getting to Know Google Lighthouse

Until now, Google was relying on several performance tools to assess the performance of websites, such as PageSpeed Insights, WebPageTest, Test My Site, Chrome Developer Tools and Lighthouse.

The main problem of employing different performance tools is that they produce various recommendations, piling up confusion to the Web Performance Optimization process which is not always straightforward to get to grips.
That’s why, according to Google, it was time to make things easier and allow developers to obtain the same performance recommendations everywhere, no matter which Google tool they decided to use.
Now that Lighthouse powers PageSpeed Insights, you should obtain the same result whether you choose to get your performance recommendations from the web, the command line, or Chrome DevTools.

Keeping in mind this context it’s worth noting that, with this new tool, Google is targeting a very specific type of users: developers and tech-savvy people that already have a good knowledge of web performance best practices and solutions.

At the same time, if we focus on the WordPress ecosystem, we’re observing a remarkable interest by Google in fine-tuning Lighthouse recommendations and making them more approachable for WordPress developers and site owners.

From Alberto Medina (Developer Advocate at Google):

We are considering the development of a project called WordPress-localized Advice Packs for Lighthouse, with the goal of providing WordPress-specific guidance using Lighthouse. With it, WordPress developers and site owners will get the results from Lighthouse audits tailored to the realities of the WordPress platform.

Now, before stepping into the details of the new PageSpeed Insight API, let’s clarify what Google Lighthouse is.

What Is Google Lighthouse?

Lighthouse is the technology at the core of this v5 PSI update. According to Google definition:

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, and more.
You can run Lighthouse in Chrome DevTools, from the command line, or as a Node module. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.

Lighthouse code is available on the public Google Chrome GitHub repo.

Why Is This PageSpeed Insights Update a Game-Changer?

From now on, the new PageSpeed Insights requires all of us to adjust the way we read performance scores and interpret Web Performance Optimization audits.

When you measure a page with PageSpeed Insights, the result includes both lab and field data about that page. This is how Google explains the difference between lab and field data:

Lab data is useful for debugging performance issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks.
Field data is useful for capturing true, real-world user experience – but has a more limited set of metrics.

Lab data on PSI is based on different metrics:

• First Contentful Paint
• First Meaningful Paint
• Speed Index
• First CPU Idle
• Time to Interactive
• Estimated Input Latency
  

Each of these metrics gets a score and the (in)famous PSI icon: green check when the grade is good (90+), orange circle for the average grade, and a red triangle for the lowest grade.

Field data, on the other hand, is based on a set of historical stats about how a specific page has performed ”in the real world”: it considers anonymized performance data from real users who visited the page from different devices and network conditions.
This data is stored on the Chrome User Experience Report dataset and is depicted in the user interface as a classification of speed: a green bar for fast pages, an orange bar for average pages, and a red bar for slow pages.

It’s important to note that not all sites may have enough field data available for display.

Why You Should Read PSI Scores in a Different Way

In simple terms, while lab data simulates the performance of a page on a fixed set of conditions (device and network), field data collects an average of the real-world performance.

Now that all PSI results are based on Lighthouse, we have to interpret results differently, and for a simple reason: Lighthouse simulates a page load on mobile networks and mid-tier devices.

This is the real revolution of the new PageSpeed Insight version!

Every time you read a PSI report, you have to remember that the first screen presented is the mobile performance: it describes how your website performs under a mobile connection and, furthermore, on a mid-range device.

3 Key Points to Remember When You Run a PageSpeed Test

Now that you know that mobile is prioritized by Google and its Lighthouse tool, let’s see three key points to keep in mind when running a PageSpeed Insight test with the new API:

1. PSI Tests Are Conducted Using a Throttled 3G Connection

This will probably matter if your visitors are using low-speed 3G networks. As you may know, the average download speed on mobile is constantly increasing: our mobile networks are more and more powerful, and they can run four times faster than the speed of a 3G connection.
This parameter is not so relevant if your audience is based on countries where 3G mobile networks are getting surpassed by faster connections.

2. The Testing Server Location Used by PSI Reports Is Unknown

This is a major point!
Suppose your server is in Atlanta, closest to your target audience, while the test server used by PageSpeed Insights is, let’s say, in Los Angeles.
You’ll get results that don’t represent a real-world scenario in which a visitor located in Atlanta would experience lower loading time, being geographically closer to your server.
That’s why we always suggest completing your performance audit using tools like Pingdom and GTMetrix, which allow you to choose different server locations (for GTMetrix, you need to create an account to access the server locations list).

3. The Mobile Device (Or the Emulator of Mobile Device) Used by PSI Is a Mid-Tier Moto G4

Mobile devices vary significantly in processing power/characteristics, and this can have a huge impact on page load time.
The latest technology smartphone would take significantly less time to load a page compared, under the same network conditions, to one that is even just a couple of years older.

How to Tackle the New PageSpeed Recommendations?

Along with the mentioned technology update behind PageSpeed algorithm, it’s worth mentioning a few new recommendations that are making many of our customers scratch their head and ask ”Can WP Rocket fix this?”

Let’s see them together:

Defer Unused CSS

The PageSpeed notice describes this recommendation as follows:

Remove unused rules from stylesheets to reduce unnecessary bytes consumed by network activity.

When you’re using pre-built WordPress themes and plugins, they will typically contain more code than is necessary for each page: this happens because the author cannot predict how the final users will build their site.
For example, the homepage might have grids showing the latest posts, while internal pages might not contain them. But homepage and internal pages often have the same stylesheet.
This means that CSS for a different page will have to be loaded on the homepage and vice versa.

Can WP Rocket Fix the Note About ”Defer Unused CSS”?

No. To truly satisfy this recommendation you would need to custom-code your site, instead of using pre-built WordPress theme and plugins.

Minimize Main-Thread Work

A good explanation of this recommendation can be found in this guide by Addy Osmani, engineering manager at Google: JavaScript Start-up Optimization.

What PageSpeed is saying when it shows you the note about minimizing main-thread work, is that your site is heavily relying on JavaScript.

JavaScript has a high cost: it impacts your site in terms of downloading and execution, because the slower the user connection, the longer the download of the page will be.
But another heavy cost of JavaScript to take into consideration is the time needed to parse/compile the code, after its download: the more JavaScript you send, the longer the parse/compile process, the longer your users will have to wait to start interacting with your site, especially from mobile.

Can WP Rocket Fix the Bote About ”Minimize Main-Thread Work”?

No. To improve this note, you’ll have to reduce the use your site is making of JavaScript and is sending to the browser.

Reduce JavaScript Execution Time

This recommendation is strictly related to the previous one and, again, JavaScript is on trial 😉

PageSpeed is reminding you once again that your site should use less JavaScript to improve the execution time of the pages.
Every time you see this note, ask yourself ”Am I really sending down too much JavaScript?”.
The answer will likely be ”Yes!”

There are many ways to reduce the use of JavaScript, and this is not the best place to explore those infinite possibilities, but a good starting point could be the resources listed in You Might Not Need JavaScript.

Can WP Rocket Fix the Note About ”Reduce JavaScript Execution Time”?

No. WP Rocket has no control over the amount of JavaScript your website is sending; you should intervene on the code and reduce the cost of JS.

The common denominator of these three new recommendations is they all require advanced optimization, confirming what we mentioned earlier: the real target of PageSpeed Insights in this context are experts who can dip their fingers into custom code.

Wrapping up

At WP Rocket, we are receiving several messages from worried customers who saw their mobile PageSpeed scores drop overnight.
If you’re one of them, remember that to understand the new PageSpeed Insights results you have to consider the different nature of Lighthouse.

The use of a default throttled 3G connection, of a mid-tier mobile device and the fact that server location is not specified, are the blind spots of the new PageSpeed Insight tool: taking its results with this additional context in mind is the best way to make the most of its suggestions.

Complement its reports with those of other performance measurement tools like Pingdom and GTMetrix, and you’ll get the most precise and close-to-reality picture of your website performance!

—

Featured image by Anand Dandekar from Pexels

About Alice Orru

Alice is a content writer with strong experience in international customer service and empathic communication. She is an active member of the WordPress community: she loves translating WordPress into Italian and speaking at WordCamps. You can follow @Alice_Ridice on Twitter.