Laravel Google Lighthouse Laravel Package

Product Decisions This Supports

• Release quality gates. This package turns "is the site fast, accessible, and SEO-sound?" into a numeric, automatable signal inside the Laravel app. That makes it possible to define a PM-owned release criterion — e.g. "performance ≥ 80 and accessibility ≥ 90 on the four key templates before deploy" — instead of debating quality subjectively in review. The score-threshold feature is the actual product lever; the audits are just the input.
• Accessibility and compliance prioritization. Accessibility is a legal/commercial exposure area (ADA, EAA, procurement questionnaires). Running audits on a schedule produces a defensible baseline and a trend line that supports "fund remediation this quarter vs. next" with evidence rather than anecdote.
• SEO and Core Web Vitals triage. Because it reports performance, accessibility, best practices, and SEO separately, it lets you route findings to the right owner (frontend perf vs. content/SEO vs. platform) instead of filing generic "site is slow" tickets.
• Build vs. buy vs. wire-up. The realistic decision is rarely "build a Lighthouse runner from scratch." It is: (a) adopt this PHP wrapper so audits live in the app/scheduler, (b) use Lighthouse CI or the PageSpeed Insights API in the pipeline, or (c) buy a monitoring SaaS with dashboards and alerting. This package is the cheapest option for (a) and a poor substitute for (c) — it returns scores and raw JSON, not history, alerting, or reporting UI.
• Roadmap sequencing. Because auditing depends on a headless Chrome runtime, adopting it is partly an infrastructure roadmap decision: it presumes CI runners or a worker image that can host Chrome. That couples the "add quality gates" initiative to the "harden CI/build images" initiative, which is worth sequencing deliberately.
• Use cases worth scoping: pre-release smoke audits of marketing/landing pages; regression detection after redesigns or dependency bumps; agency-style per-client page reports; seeding an internal quality dashboard; a scheduled audit of a handful of high-value URLs.
• The ownership decision the PM actually owns. The repository is archived with a last release in August 2023 and a very small community footprint. Adopting it means adopting maintenance: either you fork it under MIT and own it, or you accept it as frozen at today's Lighthouse output and plan an exit. That is a resourcing decision, not an engineering detail, and it should be made explicitly before it reaches a roadmap commitment.

When to Consider This Package

Consider it when:

• You run Laravel and want audits triggered from inside the app — a scheduled command or a fluent call after deploy — rather than only from a separate CI pipeline. That is the specific gap it fills.
• You need a small number of targeted URLs audited, not site-wide crawling. Think homepage, key landing pages, checkout entry — a handful of business-critical templates.
• You want raw JSON and scores, not a product. If the deliverable is "a number in a build log" or "a JSON artifact we parse ourselves," the thin-wrapper shape is a feature.
• Your CI or worker environment can host headless Chrome (or you are willing to build that). This is the most common real blocker and worth validating first.
• You can pin the dependency, fork it, and accept ownership. MIT licensing makes that legally straightforward; the archived status makes it practically necessary.
• The blast radius is contained. Internal tooling, a non-blocking advisory check, or a reporting job that failing does not break the product.

Look elsewhere when:

• "Archived and unmaintained" is disqualifying for your organization. Many enterprises' dependency governance will reject a 5-star, archived package on principle. Don't fight that if you don't have to — accept the decision and move to an alternative.
• You need dashboards, historical trends, alerting, budget-over-time comparisons, or multi-page crawling at scale. Lighthouse CI, PageSpeed Insights API, or a commercial monitoring vendor cover this; this package does not, and extending it into that is a product you would then have to own.
• You need current Lighthouse behavior. A 2023 wrapper will lag upstream Lighthouse/Chrome changes in categories, audit names, and score weighting — the numbers can drift without any code change on your side, which quietly undermines any threshold you set.
• You cannot run Node/Chrome in the deployment or build environment, or doing so is expensive relative to the value of the check.
• The audit result would be a hard release gate. Blocking deploys on a frozen, single-maintainer dependency with no security responsiveness history is a poor risk trade. Advisory-only, or a gate implemented through a maintained runner, is the safer pattern.
• You are on a Laravel major the package was never validated against (anything after Laravel 10, and realistically anything after its 2023 support window). Expect to patch the service provider or Composer constraints yourself.

Evidence caveat: the repository is archived, has a very small user base, and its last release predates current Laravel and Lighthouse versions. Package scope is documented and plausible; maintenance health, test coverage, and forward compatibility are not. Treat everything above as criteria to validate in a short spike — particularly "can we run Chrome in our CI?" and "do the scores still match what Lighthouse reports today?"

How to Pitch It (Stakeholders)

For executives: This is a small, cheap capability, not a strategic platform bet. It lets us convert three things we currently argue about — page speed, accessibility, and SEO hygiene — into numbers we can check automatically before a release ships. The commercial value is in accessibility and SEO exposure and in shipping faster pages, not in the package itself. The honest caveat is that the project is archived and effectively unmaintained, so adopting it means either a modest one-time fork-and-own cost or treating it as an interim check with a planned replacement. My recommendation is a short, timeboxed spike with the explicit question "does this or a maintained alternative get us the same signal for less total ownership?" — not a multi-quarter commitment, and not a hard release gate until we've seen it run reliably for a few weeks.

For engineering: The pitch is narrow and testable. It's a Laravel wrapper around Google Lighthouse: a fluent API and an Artisan command that audit a URL and return performance, accessibility, best-practices, and SEO scores plus the raw JSON report, with configurable Lighthouse/Chrome options and score thresholds you could wire into CI. The integration cost is not the PHP — it's the runtime: you need headless Chrome available wherever audits execute, plus timeouts, memory limits, and a queue or scheduler so audits don't sit in the request path. Before we commit: confirm the Composer constraints resolve against our Laravel and PHP versions, confirm Lighthouse and Chrome versions we can actually pin (a 2023-era wrapper may not match current audit names or scoring), check the dependency footprint, and decide who owns the fork. It's MIT, so forking is legally clean — budget it as the real adoption cost. If the spike shows we mainly need scheduled audits of a handful of URLs, this is the cheapest path; if we need history, alerting, or crawling, we should compare against Lighthouse CI or the PageSpeed Insights API in the same spike and let the evidence choose.