Prompt and context
The origin can emit 103 with Link before the final response, but production traffic still crosses a TLS terminator, load balancer, reverse proxy, and CDN. Design an end-to-end compatibility matrix, canary switch, transparent fallback, and observability plan that proves the 1xx response reaches supported browsers.
What the interviewer tests
Strong answers distinguish interim from final responses, select high-confidence resources, discuss HTTP/2, HTTP/3, proxies, and CDNs, and provide transparent fallback when 103 is ignored. They also cover incorrect hints, cache and cross-origin risks, and measurements of real user benefit.
Questions to clarify
- How early and how confidently can the server know the resource set?
- Do the client, TLS terminator, reverse proxy, and CDN preserve 1xx responses?
- Are resources versioned, and is cross-origin
preconnectnecessary? - Is the target LCP, the post-TTFB gap, or earlier CSS and font discovery?
- How are errors, cache hits, and clients without 103 observed and handled?
30-second answer
Before the final response, I would send 103 with a small set of high-confidence Link hints, then send the normal final response. Resources use versioned URLs and cross-origin connections are limited to trusted domains. Ignoring 103 must leave the page correct because the final HTML still references resources. I would compare supported and unsupported paths using traces and RUM for LCP, discovery time, duplicate bytes, and errors before expanding coverage.
Step-by-step deep answer
Step 1: Understand the timing
103 is an informational interim response and must be followed by a final response. It can carry hints such as Link: </app.css>; rel=preload; as=style while the server is working. Whether a client acts on them depends on the protocol stack, browser, and policy; business correctness must not depend on them.
Step 2: Select resources
Hint only resources that are almost certain, reasonably sized, and stable: critical CSS, fonts, or a preconnect. Avoid low-probability images, personalized scripts, and permission-dependent assets that waste bandwidth or prefetch the wrong thing.
HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8Step 3: Verify intermediaries and fallback
Test the actual load balancer, TLS termination, CDN, and browser path for forwarding or consuming 103. A client that ignores it must still receive ordinary references in the final response; never make a page depend on an interim message.
Step 4: Bound cache and security effects
Hints must match the current request context. Use content-hashed URLs and correct Cache-Control; never build arbitrary Link values from user input. Cross-origin preconnect reveals connection intent and consumes resources, so allow only trusted origins and needed parameters.
Step 5: Avoid wrong preloads
If authentication, experiments, or geography change the resource set, wait for higher confidence or omit the hint. If the final response no longer references a hinted resource, the browser may have wasted a download; measure that cost.
Step 6: Observe and roll back
Log whether 103 was sent, the final status, discovery time, cache hit, duplicate bytes, and differences by proxy. Gate rollout by route or traffic with a feature flag. Disable hints if bandwidth, errors, or user metrics worsen; final HTML remains unchanged.
Trade-offs and boundaries
103 versus preload links
103 moves a hint earlier, while the ordinary HTML link remains the final authoritative reference. They must agree to avoid duplicate downloads or priority conflicts. Hints do not replace CSP, integrity, or permission policy.
Protocol versions and intermediaries
RFC 8297 defines the semantics, but a proxy chain may drop 1xx responses. Measure the real HTTP/2, HTTP/3, CDN, and client combinations and retain a no-103 baseline.
Rollout plan and evidence
Staged release
Start with static CSS on one route, verify the final response and references, then expand to fonts or safe preconnects. Keep a kill switch and compare first visits, cached visits, and slow networks separately.
Metrics and acceptance
Track LCP, resource discovery time, duplicate bytes, cache hit rate, 4xx/5xx, and bandwidth. Reconcile browser tools, edge logs, and RUM; server send logs alone cannot prove client behavior.
Common mistakes and follow-ups
Mistake: treating 103 as final success
Business state, caching, and errors use the final response; losing 103 must not fail the request.
Mistake: hinting every resource
Low-confidence assets waste bandwidth and connections. Prefer a small stable critical set.
Mistake: testing only a direct local path
Production CDNs, proxies, and TLS termination can change 1xx behavior; test end to end.
Follow-up: what if 103 is unsupported?
Rely on ordinary final-HTML references and existing caching. Correctness remains; only potential performance gain is lost.
Follow-up: how do you prove it is worth keeping?
Run a split experiment for LCP, discovery, duplicate bytes, errors, and bandwidth, segmented by cache and network conditions.