Product Decisions This Supports
- Performance work as a first-class roadmap item. This package gives the team request-level profiling (call graphs, wall time, CPU, memory) inside a Laravel app without standing up external APM infrastructure. It directly supports decisions like "do we invest a sprint in query optimization / caching / N+1 cleanup before the next traffic push?"
- Build vs. buy for observability. A credible lightweight, self-hosted alternative to Datadog/New Relic/Blackfire for pre-production tuning. Useful as the cheap first step before committing to a paid APM contract.
- Pre-launch and incident-adjacent capacity planning. Profiling hot endpoints in staging tells you whether a feature is safe to ship to a launch or a marketing spike — a concrete input to go/no-go calls.
- Scoping performance acceptance criteria. Engineering can attach "p95 under X ms in the profiler" to epics rather than vague "make it faster" tickets.
- Targeted, low-cost adoption. Because profiling is middleware-driven and config-scoped, the PM can approve enabling it for a bounded slice of routes (a single feature area or a handful of endpoints) rather than a platform-wide rollout, keeping blast radius and cost of the bet small.
- Tooling consolidation. If the org already pays for an APM, this is a prototyping/verification aid, not a replacement — that's a portfolio decision worth stating explicitly rather than letting two tools overlap by accident.
When to Consider This Package
Good fit when:
- The app is Laravel (now including 13.x) and the team wants profiling without new vendor contracts, agents, or data-residency review.
- Engineers are comfortable reading call graphs and interpreting inclusive/exclusive wall time, CPU, and memory metrics.
- Profiling data can be confined to local, staging, or a canary environment — the typical and correct deployment shape.
- You want to profile selectively. The v1.3.0 "skip URLs by needle" option is the notable addition here: it lets you exclude health checks, webhooks, static asset routes, and other noisy or high-frequency endpoints by substring match, so the collected profiles stay signal-rich and storage stays bounded. Worth treating as a config-hygiene feature, not a headline capability.
- You need a zero-to-first-profile path measured in minutes, not a procurement cycle.
Look elsewhere when:
- You need production-grade, always-on observability with alerting, SLOs, distributed tracing, or retention guarantees — this is a developer profiling tool, not an APM.
- The stack is polyglot or heavily service-oriented; per-request PHP profiling won't give you cross-service traces.
- Nobody owns acting on the profiles. Profiling output that no one triages is pure overhead — the extension and storage cost with none of the payoff.
- You require vendor support SLAs, security review artifacts, or long-term maintenance commitments. This is a community package maintained by a small group of contributors; the Laravel 13 compatibility commit in this release came via an automated shift tool, which is a reasonable signal of health but also a reminder that maintenance is best-effort.
- Data-handling constraints forbid writing profile payloads (which can include request metadata) to your database or disk.
Adoption guardrails worth agreeing on up front: keep it disabled by default in production, gate it behind config/env, restrict the viewer route, and set a retention/cleanup expectation for stored profiles before enabling it anywhere shared.
How to Pitch It (Stakeholders)
For executives (one paragraph): We can add request-level performance profiling to our Laravel app at effectively zero licensing cost, using a community package that hooks into the framework's middleware and records where each request spends its time and memory. The new release keeps us current with Laravel 13 and lets us exclude noisy URLs from collection, so the data stays focused. The business case is straightforward: it shortens the loop between "the app feels slow" and "here is the exact function to fix," which reduces the engineering cost of the performance work already on our roadmap and can defer a five- or six-figure APM contract until we actually need always-on production monitoring. The trade-off is that it is a developer tool with community support, not a supported monitoring platform, so we'd scope it to development and staging and name an owner for triaging results.
For engineering: This is XHProf via middleware — enable it per environment, scope the routes you care about, and use the v1.3.0 needle-based skip list to keep health checks, webhooks, and other high-frequency endpoints out of the dataset. Treat the stored profiles as short-lived diagnostic artifacts with a cleanup policy, not as a metrics store. It complements, and does not replace, whatever we use for production alerting.
Recommended next step: a time-boxed pilot — enable it in staging on one or two known-slow flows, have the owning team produce a short findings write-up, and decide from that evidence whether to keep it as standing dev tooling or retire it.