Performance testing with Google PageSpeed Insights

Pulse calls the Google PageSpeed Insights API and parses the result into something you can read at a glance: an overall performance score, the Core Web Vitals, and the individual audits that moved the number.

Source

Google PageSpeed Insights

Default strategy

Mobile

Timeout

90 seconds

Needs a server API key

Yes

Where Google has enough real-world traffic for your URL, the field data is returned alongside the lab run. That distinction matters — the lab score is one simulated load on one throttled connection, while the field data is what your actual visitors experienced over the last month. They frequently disagree, and when they do the field data is the one worth acting on.

A raw Lighthouse report lists dozens of audits, most of which do not matter for your site. The result is filtered to the ones with a measurable saving and sorted by it, so the top of the list is the work worth doing first rather than the work that happens to sort alphabetically.

Run against a page before and after a change and the two results sit next to each other in the run history. That is usually a more useful comparison than any single absolute score.

• The URL must be publicly reachable. Google’s servers do the loading, so a staging site behind a VPN, basic auth or an IP allowlist cannot be tested this way.
• Runs take time. Ten to forty-five seconds is normal, because a real browser is loading your page somewhere else.
• It needs an API key on the server. Without PAGESPEED_API_KEY configured, the check reports itself as unavailable with that reason in the tool list — rather than appearing to work and failing with an unexplained error when you run it.
• Mobile and desktop are separate runs. They throttle differently and score differently; testing one tells you nothing reliable about the other.