Guide · performance and QA
Lighthouse and PageSpeed Insights vs website QA: what each one tests
Lighthouse and PageSpeed Insights tell you how a page loads and whether it follows a set of best practices. They do not tell you whether a visitor can sign up. This guide separates what these Google tools measure from what website QA testing covers, so you can run both and read each result for what it is.
Facts checked
What each tool is
| Tool | What it does | How you run it |
|---|---|---|
| Lighthouse | An open-source, automated tool that audits a page for performance, accessibility, SEO and more, and generates a report. It can run on any public page or one that requires authentication | In Chrome DevTools, from the command line, as a Node module, or from a web UI |
| PageSpeed Insights | Reports on the experience of one URL on mobile and desktop, with lab data from Lighthouse and field data from the Chrome User Experience Report | Enter a URL on the PageSpeed Insights site |
| Lighthouse CI | A suite of tools for running, saving, retrieving and asserting against Lighthouse results, with a report on every pull request and performance budgets on scripts and images | In CI, for example a GitHub Actions workflow that runs lhci autorun |
What they measure
Lighthouse analyses a URL in a simulated environment across four categories: Performance, Accessibility, Best Practices and SEO. PageSpeed Insights adds field data: real-user measurements over the previous 28 days, summarised at the 75th percentile, for the Core Web Vitals (Interaction to Next Paint, Largest Contentful Paint and Cumulative Layout Shift).
Google’s documentation is plain about the limits. Lab data is useful for debugging but may not capture real-world bottlenecks; field data has a more limited set of metrics; and real-user data is unavailable for pages that are not public and crawlable or that lack enough samples.
What they leave to you
- Whether a journey works. A standard run loads a URL and audits it. Lighthouse has a user-flow API that measures performance and best practices along a scripted journey, but you write the script, and it does not decide whether the outcome was right.
- Accessibility checks that need a person. Lighthouse’s documentation lists manual accessibility checks, such as whether the page has a logical tab order and whether user focus is trapped.
- Stable single numbers. Lab scores can change between runs without any change to the page, so budgets are usually asserted over several runs.
- Pages other than the one you entered. PageSpeed Insights analyses a single URL at a time.
What website QA covers instead
Website QA testing works through a flow in a real browser, checks layout at desktop, phone and narrow widths, runs accessibility rules and records page errors, then reports evidence with steps to reproduce. See the website QA testing checklist.
Using them together
- Run PageSpeed Insights on your key public URLs to see field data where there is enough of it.
- Add Lighthouse CI with a performance budget if you want a performance regression to fail a pull request.
- Run website QA on each release for journeys, layout, accessibility and errors; see Run website QA on every deploy.
To choose broader browser, scanner and monitoring coverage, see the guide to web application testing software.
Common questions
Is a good Lighthouse score enough to launch?
It tells you about load performance and some best practices on the URLs you audited. It does not show that signup, forms or checkout work, and its accessibility audit leaves some checks to a person. Treat it as one input.
Does Sybqa give a Lighthouse or Core Web Vitals score?
No. Route-level Lighthouse reports are listed as not available in the Sybqa console. Use Lighthouse or PageSpeed Insights for performance scoring.
Sources
Related
Try Sybqa on your site
Paste a link, review the plan, and read the evidence report. The free plan gives 10 runs a month without AI review after you sign up.