July 2, 2019 (Updated: November 11, 2020)
It’s no secret that speed has become a crucial factor in increasing revenue and lowering abandonment rates. Now that Google uses Core Web Vitals as a ranking factor, many organisations have become laser-focused on performance. In this article, we uncover how PageSpeed calculates it’s critical speed score.
Over the last couple of years, Google have made significant changes to their search indexing and ranking algorithms:
From this, we’re able to state two truths:
Faster sites don’t just improve user experience; recent data shows that improving site speed also reduces operating costs. Like us, our users place alot of value in speed — that’s why we’ve decided to take site speed into account in our search rankings.Google
To understand how these changes affect us from a performance perspective, we need to grasp the underlying technology. PageSpeed 5.0 is a complete overhaul of previous editions. It’s now being powered by Lighthouse and CrUX (Chrome User Experience Report).
This upgrade also brings a new scoring algorithm that makes it far more challenging to receive a high PageSpeed score.
Before 5.0, PageSpeed ran a series of heuristics against a given page. If the page has large, uncompressed images, PageSpeed would suggest image compression. No Cache-Headers missing? Add them.
These heuristics were coupled with a set of guidelines that would likely result in better performance if followed, but were merely superficial and didn’t actually analyse the load and render experience that real visitors face.
In PageSpeed 5.0, pages are loaded in a real Chrome browser that is controlled by Lighthouse. Lighthouse records metrics from the browser and calculates an overall performance score. Guidelines for improvement are suggested based on how specific metrics score.
Like PageSpeed, Lighthouse also has a performance score. In PageSpeed 5.0, the performance score is taken from Lighthouse directly. PageSpeed’s speed score is now the same as Lighthouse Performance Score.
Now that we know where the PageSpeed score comes from, let’s dive into how it’s calculated, and how we can make meaningful improvements.
Lighthouse is an open source project run by a dedicated team from Google Chrome. Over the past couple of years, it has become the go-to free performance analysis tool.
If you’re interested in a high-level overview of Lighthouse architecture, read this guide from the official repository.
During performance tests, Lighthouse records many metrics focused on what a user sees and experiences.
There are 6 metrics used to create the overall performance score. They are:
Lighthouse applies a 0 – 100 scoring model to each of these metrics. This process works by obtaining mobile 75th and 95th percentiles from HTTP Archive, then applying a log normal function.
Following the algorithm and reference data used to calculate Time to Interactive, we can see that if a page managed to become "interactive" in 2.1 seconds, the Time to Interactive metric score would be 92/100.
Once each metric is scored, it’s assigned a weighting which is used as a modifier in calculating the overall performance score. The weightings are as follows:
|Time to Interactive (TTI)||33.3%|
|First Contentful Paint||20.0%|
|First CPU Idle||13.3%|
|First Meaningful Paint||6.7%|
|Estimated Input Latency||0.0%|
These weightings refer to the impact of each metric in regards to mobile user experience.
Time to Interactive (TTI) is the most heavily weighted metric, therefore you’ll need a speedy TTI measurement to receive a high score.
At a high level, there are two significant factors that hugely influence TTI:
Our Time to Interactive guide explains how TTI works in great detail, but if you’re looking for some quick no-research wins, we’d suggest:
Effective measures for reducing the amount of script from your pages:
To successfully uncover significant differences in user experience, we suggest using a performance monitoring system (like Calibre!) that allows for testing a minimum of two devices; a fast desktop and a low-mid range mobile phone.
That way, you’ll have the data for both the best and worst case of what your customers experience. It’s time to come to terms that your customers aren’t using the same powerful hardware as you.
An excellent substitute for using a real device is to use Chrome DevTools hardware emulation mode. We’ve written an extensive performance profiling guide to help you get started with runtime performance.
Speed Index, First Contentful Paint and First Meaningful Paint are all browser-paint based metrics. They’re influenced by similar factors and can often be improved at the same time.
It’s objectively easier to improve these metrics as they are calculated by how quickly a page renders. Following the Lighthouse Performance audit rules closely will result in these metrics improving.
If you aren’t already preloading your fonts or optimising for critical requests, that is an excellent place to start a performance journey. Our article, The Critical Request, explains in great detail how the browser fetches and renders critical resources used to render your pages.
Google's newly updated search console, Lighthouse and PageSpeed Insights are a great way to get initial visibility into the performance of your pages but fall short for teams who need to continuously track and improve the performance of their pages.
Continuous performance monitoring is essential to ensuring speed improvements last, and teams get instantly notified when regressions happen. Manual testing introduces unexpected variability in results and makes testing from different regions as well as on various devices nearly impossible without a dedicated lab environment.
Speed has become a crucial factor for SEO rankings, especially now that nearly 50% of Web traffic comes from mobile devices.
To avoid losing positioning, ensure you're using an up-to-date performance suite to track key pages (pssst, we built Calibre to be your performance companion. It has Lighthouse built-in. Hundreds of teams from around the globe are using it every day).
Join thousands of subscribers keeping up-to-date with web performance news and advice.
Engineering Manager at Google Chrome