Laravel Server Timing Laravel Package

Product Decisions This Supports

• A defensible "not yet" on a paid APM contract. beyondcode/laravel-server-timing emits W3C-standard Server-Timing headers from a Laravel app, so engineers can attribute request latency — bootstrap, middleware, database, cache, view render, and custom checkpoints — directly in Chrome DevTools' Performance panel. That is a build-vs-buy decision that costs a composer require rather than a procurement cycle, and it buys real evidence while a Datadog/New Relic commitment stays deferred. Frame it as deferring the APM purchase, not cancelling it.
• Turning "the app feels slow" into sprint-sized work. A PM needs latency broken into named subsystems, not a single TTFB number. Engineers can attach a per-request waterfall to a ticket, which converts a vague performance complaint into an attributable, estimable item with a clear owner and a verifiable before/after.
• Gating rollouts on evidence rather than intuition. Measure a caching layer, a queue offload, or a query fix in staging or pre-prod and confirm the optimization actually landed. Cheap, reversible, and it gives the roadmap a measurable performance story without a vendor invoice.
• A platform/DX win that costs feature teams nothing. Low-risk, developer-loved, zero user-facing surface, no migration, no data model. Good filler for a platform roadmap quarter where you want visible engineering wins without pulling capacity off product work.
• Roadmap signal from 1.7.0. The entire release is Laravel 13.x compatibility (PR #42) — no features, no API changes. Read it as stable and low-churn: actively maintained against the support matrix, safe to keep, but not a platform to build differentiated capability on. It is also the version that unblocks teams planning the Laravel 13 upgrade, so it belongs on that upgrade's dependency checklist.
• Explicitly not a product-analytics input. Nothing here feeds funnels, experiments, or end-user behavior metrics. Keep it out of any customer-telemetry roadmap conversation — conflating internal request profiling with product instrumentation is the most likely way this package gets mispositioned and over-invested in.

When to Consider This Package

Adopt when:

• The stack is Laravel and engineers already live in browser DevTools — onboarding is effectively zero.
• You have no APM, or you have APM but want a no-config local/pre-prod view for triage and reproduction without log spelunking.
• You need timing visible in the browser against a specific environment, not in a dashboard someone has to go find.
• Privacy, data-residency, or procurement constraints make third-party request telemetry a hard sell: headers stay in the response, nothing leaves your infrastructure.
• Dependency budget is tight — one small package, narrow surface area (a middleware plus a facade), conventional service provider registration, no PHP extensions, no sidecar, no Node toolchain.
• You are planning or executing a Laravel 13 upgrade; 1.7.0 is the version that resolves against that pin.

Look elsewhere when:

• You need alerting, SLOs, distributed tracing, sampling, retention, or cross-request aggregation. Server-Timing is per-request and browser-visible; it is not an observability platform, and substituting it for one will fail at the first on-call rotation.
• The consumer is not a browser you control: native mobile clients, third-party API consumers, and CLI or scheduled jobs will never see these headers — that is a coverage blind spot, not an edge case.
• You need historical baselines or trend analysis ("p95 checkout latency this quarter"). Headers disappear when the tab closes.
• The surface is security- or compliance-sensitive and internal timing detail — query counts, route/controller names, custom milestone labels — cannot be exposed to clients, or you have no reliable environment or auth gate to prevent it.
• The team has standardized on OpenTelemetry or already runs Telescope/A PM heavily. The overlap is real; pick one timing convention rather than maintain two parallel stories.

Adoption criteria before merging: middleware registered only outside production or behind an auth/flag gate; a small, named, low-cardinality milestone set agreed up front and capped to avoid header bloat; the package version constraint verified against current Laravel and PHP pins; and a named owner for the Laravel-major bump cadence. Two known failure modes to plan around — a missing or misordered middleware is a silent no-op with no error (absence reads as "no timing problem" rather than "instrumentation missing"), and enabling it in production without a gate is an information-disclosure risk.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed diagnostic utility that shows our engineers, on any page load, how long each part of a request took — database, cache, template rendering, any custom step — inside the browser they already use. No license fee, no vendor contract, no data leaving our systems, no user-facing change. It is a fast, low-risk way to make measurable progress on performance while we deliberately defer a paid monitoring vendor. The 1.7.0 release is purely a compatibility update for the next major Laravel version: no new features, no breaking changes. That is exactly the signal we want from a small utility — actively maintained and making no demands on us.

For engineering: 1.7.0 is a single change — Laravel 13.x support via an upstream PR. No API changes, no deprecations, no migration work; it is a safe bump that also clears the path to the next framework major. Install is one composer require, middleware registration (it is not auto-registered — the service provider is, the middleware is not), and an optional config publish; expect to spend your real effort on discipline, not integration. Instrument a deliberately small set of milestones — total request, DB, cache, view render, plus one or two domain spans — and register the middleware only outside production or behind a flag, since headers are client-visible and can leak internal structure. Watch for the silent no-op: wrong position in the stack means no headers and no error. Rollback is config removal plus a composer remove — stateless and header-only, with no migrations or backfill. The highest-leverage move is baking registration and the environment gate into the shared application skeleton, which converts an ad-hoc install into a known-good default. Treat it as a developer-facing convenience that complements APM rather than replacing it, and if we standardize on OpenTelemetry long term, plan to consolidate rather than run both indefinitely.