Laravel Http3Earlyhints Laravel Package

Product Decisions This Supports

• Perceived-performance roadmap (Core Web Vitals): this package emits HTTP 103 Early Hints from the Laravel origin, letting the browser preload CSS/JS/fonts while the app is still rendering. That is a lever on FCP/LCP for server-rendered, asset-heavy pages — not a new user-facing feature, but a measurable "speed" initiative you can scope and defend.
• Build vs. buy on delivery optimisation: the alternative to this package is edge-generated hints (Cloudflare/Fastly/CDN configuration) or hand-rolled middleware. Adopting it is a cheap way to get origin-level hints without platform work — useful when you don't control the CDN tier or need hints for authenticated/dynamic pages that aren't edge-cached.
• Framework upgrade planning: 1.5.3 adds Laravel 13 support. This is the deciding signal that the package tracks the framework upgrade cadence, so it won't become a blocker in your next Laravel upgrade cycle. Treat "supported on our target LTS" as an adoption gate, not a nice-to-have.
• Caching/serialization standards: the serializable_classes addition matters if your platform enforces an allowlist for cache unserialization (a hardening pattern). It means the package can participate in that policy rather than forcing an exception — relevant to security-reviewed stacks.
• Prioritisation input: a low-effort, low-blast-radius performance experiment you can A/B against a control cohort via RUM, rather than a multi-sprint refactor. Good candidate for a "cheap wins" slot in a quarter otherwise dominated by larger bets.

When to Consider This Package

Consider it when all of the following hold:

• Your pages are server-rendered and asset-heavy, with meaningful server think-time before the first byte of HTML — that's the window Early Hints exploits. On a statically generated or heavily edge-cached site, the win is largely already captured elsewhere.
• Your serving path supports 103 (HTTP/2 or HTTP/3, via nginx, Caddy, a CDN/proxy that passes 103 through). Verify this end-to-end before committing; a proxy that swallows 103 makes the package inert.
• You have, or will build, RUM measurement (LCP/FCP segmented by browser). Lab tooling under-represents Early Hints because it depends on real network round-trips.
• You are on, or moving to, a Laravel version the package supports (now including L13), and your stack has no policy conflict with the package's caching/serialization behaviour.

Look elsewhere when:

• You get Early Hints from the edge already — duplicating at origin adds config surface for marginal gain, and can conflict.
• Your bottleneck is JS execution or client-side rendering, not asset discovery; hints won't move the metric you care about.
• You need guaranteed, vendor-backed support or a broad browser-coverage story — Early Hints support is uneven across browsers, so treat it as a progressive enhancement and size expectations accordingly.
• You're unwilling to own a small, single-maintainer dependency: this is an agency-published package with a narrow scope. Pin the version, review the diff on each bump, and keep a fallback of disabling the middleware.

How to Pitch It (Stakeholders)

To executives: "A small, free add-on that lets our servers start sending key assets to the browser a few hundred milliseconds earlier. It's a low-cost experiment on page-speed metrics we already report, with a one-line rollback if it doesn't show up in the data."

To engineering: "It's a Laravel middleware package for HTTP/3 Early Hints. Latest release (1.5.3) adds Laravel 13 compatibility and a serializable_classes option, so it fits our upgrade path and our cache-serialization allowlist. Scope is narrow: it emits 103 preload hints, nothing else. Work is in the plumbing — confirming our proxy passes 103, defining which assets to hint, and instrumenting RUM so we can prove impact. Success is a measured LCP/FCP improvement on the target cohort; kill criteria are no measurable delta after N weeks, or any regression/interference from the extra middleware."

To security/ops: "No new data stores or network egress; it only adds an interim response header on existing requests. The serialization change means it now respects an explicit class allowlist rather than requiring an exemption — we should confirm the config semantics against PR #8 before enabling it."