PageSpeed Insights is a Google project that has drastically evolved over the past few years. As stated, "PageSpeed Insights (PSI) reports on the performance of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved". It might not be obvious, but this tool does so much more than stated. PageSpeed Insights provides a REST API in addition to the GUI. Now more than ever, we can benefit from PSI in light of Google's announcement to update its search algorithm to prioritize page experience. PSI provides lab data for SEO, performance, accessibility, best practices and PWA via Lighthouse and Web Vitals field metrics from Google's CrUX API.
Lighthouse and Web Vitals via PageSpeed Insights API
Under the hood the PageSpeed Insights API runs Lighthouse for lab data and fetches Web Vitals field data via CrUX API. The response will look something like the below.
{
"kind": string,
"captchaResult": string,
"id": string,
"loadingExperience": {
object (PagespeedApiLoadingExperienceV5)
},
"originLoadingExperience": {
object (PagespeedApiLoadingExperienceV5)
},
"analysisUTCTimestamp": string,
"lighthouseResult": {
object (LighthouseResultV5)
},
"version": {
object (PagespeedVersion)
}
}lighthouseResult is similar to what you would see in the Lighthouse result payload as lhr. loadingExperience represents metrics of end users' page loading experience while originLoadingExperience represents metrics of the aggregated page loading experience of the origin.
Monitoring Page Experience with PageSpeed Insights API
Foo now uses PageSpeed Insights API as its source for running Lighthouse to monitor website quality and page experience. We can monitor changes in website performance, SEO, accessibility, best practice and PWA as we were previously (with Lighthouse directly). Our motivation for making this change came from challenging intermittent Lighthouse PROTOCOL_TIMEOUT issues affecting paid subscribers and IP blocking. After some time wrestling the problems and attempting to remedy with a more resource intense infrastructure, and a variety of OS flavors - we landed on this solution. We now run Lighthouse via PageSpeed Insights API as the ideal solution but still run Lighthouse directly when URLs require options like extraHeaders. We still experience a low number of timeouts with PSI, but run Lighthouse directly as part of our retry logic and with this new recipe of running Lighthouse - we're now free of issues!
We maintain an NPM package called Lighthouse Persist which extends Lighthouse to provide simple configuration to upload Lighthouse reports to AWS S3. We added an option for utilizing the same package to run Lighthouse via PageSpeed Insights API. The nice part about this is that you can seamlessly run Lighthouse directly or via PSI with the same interface and output. We run Lighthouse Persist in our production environment nearly 10,000 times a day!
Benefits of Running Lighthouse via PageSpeed Insights API
We chose to utilize the PSI API to run Lighthouse as a solution to the issues described above. There are many other benefits that helped us make this decision.
- Offload resource consumption to Google 🙌! If you haven't noticed Lighthouse memory and CPU consumption is expensive. The PageSpeed Insights API does impose rate limiting however. It seems that you can request an increase in limits, however the UI is a bit limited in this area at the moment. I would expect this to change soon 🤞
- Get consistent results by running Lighthouse in a stable, consistent environment.
- Get additional data like
loadingExperienceandoriginLoadingExperiencefrom the CrUX API (under the hood).