Laravel Performance Testing Laravel Package

Product Decisions This Supports

• Performance as a release gate: Lets the team encode p95 response-time, query-count, and memory budgets as executable assertions in the existing Laravel test suite, turning "the app feels slow" into a pass/fail check on every pull request.
• Roadmap sequencing and tech-debt prioritization: Gives objective before/after numbers when evaluating a refactor, a query optimization, or a framework/PHP upgrade, so work is scheduled on evidence rather than anecdote.
• Build vs. buy for load/performance tooling: An in-framework package removes the need to stand up and maintain a separate load-testing stack (k6, Gatling, JMeter) for routine regression checks — the buy decision is a Composer dependency instead of an infrastructure project.
• SLO/SLA definition: Forces the product to state concrete latency and resource targets per critical journey (checkout, login, search), which is a product decision that engineering alone usually makes by default.
• Upgrade readiness: v1.3.3 explicitly fixes a PHP 8.4+ deprecation in the server health check and tests on PHP 8.5, which de-risks the platform-upgrade workstream on the roadmap and keeps this dependency out of the "blockers for PHP 8.5" list.
• Release confidence for stakeholders: A green performance suite is cheap, legible evidence for a go/no-go conversation that doesn't require a dedicated performance engineer.

When to Consider This Package

Consider it when:

• The product is a Laravel application and the team already runs PHPUnit/Pest in CI — the marginal cost of adoption is a dependency and a handful of test cases, not a new toolchain.
• You need regression detection (did this change make a known endpoint slower?) rather than capacity planning or stress testing.
• The team is small and won't staff a dedicated performance/observability effort; keeping performance assertions next to feature tests reduces context-switching and ownership ambiguity.
• You want performance budgets enforced on the critical path (a few high-value endpoints), not blanket coverage of every route.
• Runtime environment is PHP 8.4/8.5 or you are planning that upgrade — this release keeps the package compatible and deprecation-clean.

Look elsewhere when:

• You need true concurrent load generation, ramp-up scenarios, or distributed traffic (k6, Gatling, Locust, Artillery). In-process test-time assertions do not model real concurrency or network behavior.
• You need browser-level or front-end metrics (Core Web Vitals, TTFB from real users) — that's RUM/APM territory (Sentry, New Relic, Datadog, Laravel Pulse plus a real-user monitoring tool).
• You need continuous production profiling or tracing, not pre-merge checks.
• The team has no CI discipline or no agreed performance targets — the package will produce numbers nobody acts on, and will be the first thing disabled when a build goes red for unrelated reasons.
• Non-Laravel or polyglot estates where a language-agnostic load tool already exists and is owned by a platform team.

How to Pitch It (Stakeholders)

For executives: This is low-cost insurance against the most common way web products lose revenue — a page that quietly gets slower release after release until customers leave. It adds no new infrastructure and no new vendor; it lets our existing automated test suite fail the build when a critical user journey exceeds an agreed speed budget. Cost is a Composer dependency and a few days of engineer time to define the budgets; the payoff is that performance regressions are caught before customers see them rather than after an incident review. The v1.3.3 release also confirms the package is actively maintained and already forward-compatible with PHP 8.5, so it will not become an obstacle to our platform upgrade.

For engineering: It is a PHPUnit/Pest-native performance testing toolkit for Laravel — declare response-time, query-count, and memory expectations alongside your feature tests and let CI enforce them. No sidecar, no container, no separate DSL to learn. v1.3.3 is a maintenance patch: it fixes a PHP 8.4+ deprecation in the server health check and adds PHP 8.5 to the test matrix. No API changes, no breaking changes, no action required beyond a routine composer update. Pin the version, add budgets for two or three revenue-critical endpoints first, and keep the assertions coarse enough that they flag real regressions rather than machine-to-machine noise.