With HTTP/2 server push removed from browsers, how would you decide between HTTP 103 Early Hints, Link: rel=preload on the final response, inlining critical CSS, and doing nothing, for delivering render-blocking resources on a high-traffic site?

## Frame the decision as a critical-path budget Every technique here buys back a specific segment of time. Name the segments before choosing: 1. **Connection setup** to your origin and to third parties (DNS + TCP/QUIC + TLS). 2. **Origin think-time**: request received → first byte of HTML produced. 3. **HTML transfer**. 4. **Discovery**: the browser parses HTML, finds `/app.css`, and only then requests it — one extra round trip, plus the queueing behind whatever else is in flight. 5. **Subresource transfer**. Measure them in field data (real-user monitoring) split by device class and network, not in a lab on a warm cache. Then pick per segment. ## Option by option **103 Early Hints.** Buys segment 4 *and* overlaps it with segment 2. This is the only tool that starts subresource fetches before the HTML exists, so its ceiling equals your origin think-time. Requirements: an application framework that can flush an early response, every intermediary forwarding 1xx (buffering proxies and some WAFs drop it), and a hint list generated from the same build artifact as the page so hashed filenames never go stale. Browsers honour it for top-level navigations and for preload/preconnect hints. Wrong hints cost a full wasted fetch each, so keep the list to render-blocking assets. **`Link: rel=preload` on the final response (or `<link rel=preload>` in the head).** Buys part of segment 4 only — the browser still waits for the HTML, but it no longer waits to *parse* to the reference. Valuable when a critical asset is referenced late in the document, imported from inside a JS module graph, or discovered only at runtime (a font referenced by CSS is the classic case: two levels of discovery). Cost is near zero, correctness risk is low, and it works everywhere. This is the sane default. **`rel=preconnect`.** Buys segment 1 for third parties. Best risk profile of anything here: a wrong guess costs one idle socket, a right guess saves a full handshake, often 100–300 ms on mobile. Limit to two or three origins; each one holds resources. **Inlining critical CSS (or a small critical JS shim).** Buys segments 4 and 5 entirely — zero round trips. Costs are real: the bytes are re-sent on every HTML response (uncacheable), the HTML grows so the first congestion window may no longer hold it, and you now maintain a critical-CSS extraction step that silently rots. Justified when the critical set is genuinely small (single-digit KB) and stable, and especially on landing pages where the HTML is already uncacheable. **Do nothing.** The correct answer more often than teams expect. If the origin returns in 20 ms from cache, the connection is fast, and there are two render-blocking assets, all of these techniques compete for single-digit milliseconds. The higher-leverage moves are usually: cache the HTML at the edge, cut the number of render-blocking resources, remove blocking third-party scripts, and stop shipping unused CSS/JS. ## Priorities as the connecting thread Whichever you choose, the connection is shared. Signal urgency with the `Priority` request header (RFC 9218: `u=0..7`, lower is more urgent; `i` for incremental) so the render-blocking assets outrank below-the-fold images. And remember the ceiling: once bytes are committed to a kernel socket buffer or a CDN buffer, no scheduler can reorder them — very large HTTP/2 flow-control windows or aggressive proxy buffering quietly nullify prioritization. Preloading twenty things at once also *creates* the contention that priorities then have to resolve; hinting fewer, better resources beats hinting more with careful priorities. ## Organizational and operational tradeoffs - **Who owns hint correctness?** Early Hints and preload lists are a build-time output. If they live in a proxy configuration edited by a different team from the one that renames the assets, they will break at the next deploy. Generate them from the manifest, and alert on 404s for preloaded URLs. - **Personalization and experiments.** If the critical asset set varies per user segment, a fixed hint list is wrong for a share of traffic. Either derive hints per variant or hint only the invariant subset. - **Blast radius and rollback.** These changes affect every page view. Ship behind a flag, ramp by percentage, and watch Largest Contentful Paint and error rates rather than counting hints emitted. - **Bandwidth cost.** On mobile, wasted preloads are paid by the user; on your side they are egress. A 5% wrong-hint rate on a large site is a real bill. ## The one-paragraph answer Instrument the critical path; pick the technique that attacks the largest segment; prefer the option whose failure mode is cheapest (preconnect, then preload, then Early Hints, then inlining); tie hint generation to the build so it cannot drift; and be willing to conclude that the right move is to reduce the number of critical resources rather than to deliver them cleverly.