- How do I install and register fetzi/server-timing in a Laravel app?
- Install it with Composer (composer require fetzi/server-timing), then wire it into the request lifecycle. The package is PSR-oriented, so Laravel integration is either an adapter that ships with it or a roughly 40-line custom middleware that resolves the timers from the container and appends the Server-Timing header to the response. On Laravel 11 and 12 you register the middleware in bootstrap/app.php; on Laravel 10 and earlier it goes in app/Http/Kernel.php. Check the repository first to confirm whether a service provider and middleware are already included before writing your own.
- Does fetzi/server-timing support Laravel 10, 11, and 12?
- Laravel 10, 11, and 12 on PHP 8.1+ are a natural fit, and the package adds no database, queue, or infrastructure dependency. However, Laravel's middleware contract is not PSR-15, so any Laravel adapter is framework-specific and version-sensitive. Verify the composer.json PHP and PSR constraints against your runtime before adopting, and add a feature test that asserts the header is present so framework upgrades surface regressions immediately.
- How do I measure a specific block of code, and which metrics are captured automatically?
- The package is built around named timers that you start and stop around the code you care about, and it serializes them into the W3C Server-Timing header. It is an instrumentation layer, not a profiler, so do not assume database query time or outbound HTTP latency is captured out of the box; confirm in the source whether any automatic spans exist or whether every metric is user-defined. If you need query timing, wrap the calls you care about with your own timers rather than expecting framework-level hooks.
- Is it safe to enable Server-Timing headers in production?
- The main risk is information disclosure: metric names and durations can leak internal structure such as table names, downstream service names, and query counts to any client, including unauthenticated ones. Gate emission by environment and ideally scope it to specific routes, or require an opt-in request header such as X-Server-Timing: 1. Also verify that the header is emitted on exception and 5xx responses, since that is exactly when you most want the timing breakdown.
- Where do I see the Server-Timing data in Chrome DevTools?
- Browsers surface the header in the DevTools Performance and Network timing panels, and you can read it from JavaScript through the PerformanceServerTiming API. Cross-origin responses only expose the timings if the Timing-Allow-Origin header is set, so an API serving a separate frontend origin will need that. Keep in mind the data is a per-request latency breakdown only, not an aggregated view.
- Does fetzi/server-timing work correctly under Laravel Octane or Swoole?
- This is the single most important thing to verify before adopting: timers must be bound per request rather than held as shared state on a long-lived worker. With Octane, RoadRunner, or Swoole, a container-scoped singleton that accumulates timings will leak metrics between requests. If the package's timer registry is not request-scoped, resolve it as a scoped binding or instantiate it per request in your middleware.
- What is the performance overhead and header size impact?
- Each metric adds roughly 20 to 60 bytes to the response header, so 30 metrics on every response of a high-RPS JSON endpoint is measurable and can interact with proxy header buffer limits. The collection overhead itself is negligible since it is just timers around existing code. Consider limiting the emitted metrics to an allow-list, or emitting the header only for non-production environments and internal traffic.
- Do cached responses carry stale Server-Timing values?
- Yes, if the header is generated before your response cache middleware stores the response, every subsequent cache hit replays timings from the original request. Place the Server-Timing middleware after the cache layer in the stack, or skip emission entirely on cache hits. Test this explicitly, since the bug is invisible in development where the cache is usually disabled.
- Is Server-Timing a replacement for OpenTelemetry, Laravel Telescope, or an APM?
- No. There is no aggregation, no percentile math, no cross-request storage, and no alerting, so it cannot substitute for a tracer or observability platform. Its value is developer experience: letting an engineer see where an 800ms request went without leaving the browser. If you already plan to adopt OpenTelemetry, decide up front whether this is a stopgap or a permanent DevTools affordance, because running both gives you two inconsistent sources of timing truth.
- Is fetzi/server-timing actively maintained, and what happens if it is abandoned?
- It is a small, single-maintainer MIT package with a modest star count, so treat the bus factor as real and check the release cadence and issue-response history over the last 12 months before committing. The mitigating factor is surface area: the library only collects timers and serializes a header, so it is trivially forkable or vendorable if maintenance stops. Pin the version rather than floating it, and keep the integration to one middleware line so removal is a deletion rather than a migration.