Opentelemetry Propagation Server Timing Laravel Package

Product Decisions This Supports

• Observability roadmap: Decides whether to add browser-visible backend timing via the standard Server-Timing response header, connecting Laravel request traces to what users see in Chrome DevTools and RUM tooling.
• Build vs. buy vs. adopt: This is a thin, standards-based propagator. Building an equivalent in-house is low effort but non-differentiating; adopting it avoids custom header/trace-correlation code and keeps you aligned with the OpenTelemetry ecosystem.
• Frontend/backend correlation: Supports decisions about whether product and support teams need trace IDs and server timings exposed in responses to diagnose slow pages end-to-end, rather than treating frontend and backend latency as separate problems.
• SLI/SLO and performance-budget work: Enables latency attribution — is the delay in Laravel/API, network, or browser rendering — which informs where to invest engineering effort.
• API product decisions: Determines whether Server-Timing should be exposed on customer-facing APIs as a debuggability feature, or restricted to internal/partner endpoints due to information-leakage concerns.
• Use cases: Debugging slow Laravel endpoints from the browser; linking frontend spans to backend traces; support triage; validating performance improvements after optimization work.

When to Consider This Package

• You already run the OpenTelemetry PHP SDK in a Laravel app and use W3C traceparent propagation.
• You want lightweight, standards-based backend timing visible in browser tooling without committing to a full RUM vendor.
• You need to correlate frontend and backend traces and are comfortable extending existing OTel instrumentation.
• Your team accepts contrib/experimental maturity — this package has 1 star, 0 dependents, and is a read-only contrib module. Treat it as a validation candidate, not a platform dependency.
• You want a standard header instead of inventing custom X-* timing headers.
• Look elsewhere if: you are not already on OpenTelemetry; you need vendor-supported SLAs; you need full RUM/session replay; you require mature adoption signals before production use; or you cannot safely expose timing data on public responses.
• Laravel-specific fit: evaluate as middleware/service-provider wiring around the OTel propagator, and test under Octane and your existing request lifecycle before broad rollout.

How to Pitch It (Stakeholders)

Executive summary: This is a low-cost, standards-based observability enhancement that connects backend Laravel traces to browser-visible timing. It helps teams answer “why is the page slow?” faster, shortens mean time to resolution, and makes performance conversations concrete by attributing latency to server vs. client. It builds on our existing OpenTelemetry investment with a small surface area and no application-logic changes.

Engineering summary: A Composer package that registers an OpenTelemetry propagator to enrich the Server-Timing response header. It should slot into existing OTel PHP configuration and Laravel middleware with minimal code, can be feature-flagged, and is easy to remove. Caveat: it is a low-adoption contrib module, so recommend a time-boxed pilot with security review of exposed timing data before production adoption.