Choosing a CI and launch QA workflow
Launch Ready and Lighthouse CI: choose the right QA workflow
Lighthouse CI runs configured Lighthouse audits in a repository's CI build. Launch Ready reviews a reachable staging or live site across launch-readiness categories. Use Lighthouse CI for build-level audit assertions; add a separate staging scan when you need broader site QA and an explicitly configured check before production promotion.
Last reviewed
Compare the workflows
| Dimension | Lighthouse CI | Launch Ready |
|---|---|---|
| Setup | Add a Lighthouse CI config and run its CLI from an existing CI system. The documented setup expects Git-managed code and a production-like build served locally, or a static site. | Create a project and scan a reachable site in the app, or use the public scan/read API from a pipeline. An API key is required for the API workflow. |
| Audits and assertions | Collect Lighthouse results for configured URLs or built pages. Configure assertions for selected audit scores or values; a failing assertion can fail the CI job. Lighthouse includes performance, accessibility, SEO, and other page-audit categories. | Scan for findings across technical, SEO/indexability, analytics, content, forms, performance, accessibility, and compliance signals. Coverage depends on reachable pages, rendering, scan limits, and effective plan entitlements. |
| Crawl and forms | Collection follows configured URLs or the built files you ask it to discover; it is not presented as a broad technical SEO crawler. The reviewed documentation describes page audits, not form submission, checkout completion, or delivery verification. | Provides cross-category site findings, subject to crawl coverage and plan limits. Form checks inspect captured markup; they do not submit forms or verify delivery. |
| Reports and monitoring | CI can upload reports. Temporary public storage makes reports visible to anyone with the URL and does not provide history or build comparisons. The optional self-hosted LHCI Server stores history and shows trends/build comparisons; by default, anyone with HTTP access can view and create data. Repeated CI runs are not an uptime monitor. | Findings and reports support team review and client handoff. Scheduled scans are discrete re-scans, not continuous monitoring; current hosted schedules, delivery, and entitlements must be verified separately. |
| Deployment workflow | Run during CI and configure assertions/status checks to fail a build or hold a protected branch. CI or deployment rules must define which later steps depend on that result. | The staging gate example deploys staging first, waits for a completed scan and strict coverage policy, then makes the production job depend on gate success. A scan started after production is already deployed cannot retroactively block that deployment. |
Keep specialist SEO research tools when you need broad keyword, backlink, or competitive analysis. Neither a Lighthouse score nor a launch-readiness scan is a certification or automatic release approval.
When Lighthouse CI alone is enough
Lighthouse CI may be all you need when the site already has a CI build, the team wants repeatable page-audit thresholds on selected URLs or build output, and failed assertions should stop that CI check. Keep the scope narrow if page performance, accessibility, and configured audit regressions are the only questions the release needs to answer.
A separate site-wide launch review is not necessary just to rerun those same Lighthouse checks. Choose a broader QA workflow only when you also need cross-category crawl findings, a reviewable launch report, or a staging validation policy outside the Lighthouse assertions.
Official Lighthouse CI getting-started guide · Collection and assertion configuration · Lighthouse audit scope
Use both when you need a staging check before promotion
Keep Lighthouse CI in the code build for selected page-audit assertions. If you also need broader validation, run Launch Ready against the staging deployment and make the production-promotion job depend on that completed check. This is a separately configured pipeline gate, not an automatic Launch Ready approval.
Tested staging scan gate
The example starts a scan through the existing API, polls the report using the API's suggested interval, and fails closed on errors, timeouts, unknown or incomplete results, unexcused blockers, or capped coverage. It passes only when readiness is ready, all eight categories are measured, every discovered page is checked and rendered, and Lighthouse has run. The workflow promotes only after the gate job succeeds; use a protected production environment for human approval where required.
The example requires an API key stored as a repository or environment secret and an HTTPS staging/preview URL reachable by the scanner. Free workspaces can scan one bound custom domain, and its first binding needs explicit confirmation. Full-category and page coverage depend on plan and scan entitlements, so the strict policy may require paid or Full Scan coverage. The example uses scan/read API endpoints; it does not require the Agency-only deploy hook.
API guide and GitHub Actions workflow · Staging gate implementation · Fixture-backed gate tests · Merged implementation and validation record
PR #197 records 17 focused tests passing, plus targeted ESLint and TypeScript checks. These are fixture-backed local tests, not hosted production acceptance.
Choose report storage deliberately
Lighthouse CI's getting-started example uploads to temporary public storage; anyone with a report URL can view it. For historical reports and comparisons, the optional LHCI Server is self-hosted, and its default access model allows anyone with HTTP access to view and create data. Secure the server and storage before uploading private or customer information.
Temporary public storage warning · LHCI Server history and access model · Fictional Launch Ready report
Limits and evidence
- Lighthouse CI collects configured Lighthouse page audits. The reviewed official sources do not establish form submission, checkout, or delivery verification; those capabilities are unknown here.
- Launch Ready checks captured form markup, not form submission or delivery. Scan coverage varies with reachable pages, rendering, entitlements, and the active plan.
- The staging gate enforces its policy only when a customer wires it into the deployment workflow and makes production promotion depend on success. A post-production scan does not block the deployment that has already happened.
- The merged example and its local tests do not establish current production entitlements, hosted worker behavior, or hosted deployment acceptance.
Launch Ready API reference · How Launch Ready scans · Compare website QA and SEO tools · Plan information
Lighthouse CI sources and Launch Ready implementation evidence reviewed 25 Oct 2026. Product features, plan access, and official documentation can change; verify current details before making a purchase or release decision.