When a browser requests a web page, it usually waits for the server to begin returning the final response before it can discover and load many of the page's resources. These resources may include stylesheets, JavaScript files, fonts, and images required to render the page.
On a fast server, this delay may be barely noticeable. However, applications with database queries, server-side rendering, authentication checks, or complex backend processing can take longer to produce the final HTML response.
HTTP 103 Early Hints helps reduce this waiting time. It allows a server to send preliminary response headers containing resource-loading hints before the final response is ready. The browser can use these hints to start fetching selected resources while the server continues processing the request.
This article explains how HTTP 103 Early Hints works, how to configure it, and how to determine whether it improves page-loading performance.
What Is HTTP 103 Early Hints?
HTTP 103 Early Hints is an informational HTTP status code defined to allow a server to communicate preliminary information before sending its final response.
For example, a server might need 400 milliseconds to generate a page. Without Early Hints, the browser may have to wait for the response headers before discovering the stylesheet referenced in the HTML.
With Early Hints, the server can send an initial response like this:
HTTP/1.1 103 Early Hints
Link: </assets/site.css>; rel=preload; as=style
Link: </assets/app.js>; rel=preload; as=script
The browser may begin fetching the specified resources before the server finishes generating the page.
After processing is complete, the server sends the final response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
The final response contains the HTML document.
The key idea is that resource discovery and page generation can happen concurrently instead of strictly one after the other.
Why Early Hints Matters
Consider a server-rendered application that performs several operations before returning HTML:
Validating a user's session.
Loading information from a database.
Preparing personalized page content.
Rendering templates on the server.
During this processing time, the browser may not know which resources it needs.
If the server already knows that the page will require a common stylesheet or application script, it can send an Early Hints response with appropriate resource hints.
This allows the browser to use otherwise idle time to start downloading those resources.
Early Hints is especially useful when server response generation takes a meaningful amount of time and the hinted resources are needed immediately after the final response arrives.
How HTTP 103 Early Hints Works
Early Hints introduces an additional step into the response process.
The general flow is:
The browser sends an HTTP request.
The server or an intermediary identifies resources that are likely to be needed.
The server sends an HTTP 103 response containing preliminary headers.
The browser may begin loading the hinted resources.
The server finishes processing the request.
The server sends the final response, such as HTTP 200 OK.
The browser processes the final HTML and continues rendering the page.
The preliminary response does not replace the final response. It provides information that can help the browser prepare for it.
Example Request and Response Flow
Browser
|
| GET /dashboard
|
v
Web Server
|
| 103 Early Hints
| Link: </assets/dashboard.css>; rel=preload; as=style
|
+------------------------------+
| |
v v
Browser starts Server loads data
downloading CSS and renders HTML
| |
+--------------+---------------+
|
v
200 OK with HTML
|
v
Browser renders page
The browser and server perform useful work concurrently.
However, the browser is not required to act on every Early Hints response. Its behavior depends on the hint, browser implementation, connection conditions, and other factors.
Understanding the Link Header
Early Hints commonly uses the HTTP Link header to describe resources that the browser can prepare to load.
For example:
HTTP/1.1 103 Early Hints
Link: </assets/main.css>; rel=preload; as=style
This header tells the browser that the stylesheet is a resource worth preloading.
The header contains several parts:
Component | Meaning |
|---|
</assets/main.css>
| The resource URL |
rel=preload
| Indicates that the resource should be fetched with high priority when appropriate |
as=style
| Identifies the resource type |
The as value matters because browsers use resource type information when deciding how to fetch, prioritize, and apply resources.
For a JavaScript file, the header might look like this:
Link: </assets/main.js>; rel=preload; as=script
For a font file, the resource type is font. Fonts may also require a crossorigin attribute or equivalent header parameter, depending on how the font is served and fetched.
For example:
Link: </assets/site-font.woff2>; rel=preload; as=font; crossorigin
Font preloading should be configured carefully because a mismatch between the preload request and the eventual font request can cause an unnecessary second download.
Only preload resources that the page is expected to use soon. Excessive preloading can compete with more important resources and increase network congestion.
HTTP 103 Early Hints vs. HTTP 200 OK
These status codes serve different purposes.
Feature | HTTP 103 Early Hints | HTTP 200 OK |
|---|
Response type | Informational response | Successful final response |
Main purpose | Provide preliminary information | Return the requested representation |
Contains final HTML | Not normally | Usually, for an HTML page |
Can help start resource loading | Yes, through suitable hints | Yes, through HTML and response headers |
Ends the request-response exchange | No | Yes, for the final response |
A server may send a 103 response and then return a 200 response. It can also send other informational responses where appropriate.
The important distinction is that the browser must still receive the final response to obtain the requested page.
Configuring Early Hints in a Web Application
Early Hints requires support in the server or an intermediary that can send informational responses before the final response.
Adding a Link header to an ordinary HTTP 200 response does not make it an Early Hints response. It is simply a resource hint delivered with the final response.
The implementation depends on the web server, reverse proxy, CDN, application framework, and HTTP protocol configuration.
Step 1: Identify Critical Resources
Start by examining which resources are needed to render the initial viewport.
For example, a server-rendered dashboard may require:
/assets/dashboard.css
/assets/dashboard.js
/assets/logo.svg
Not all three resources necessarily need preloading. The stylesheet may be critical, while the script may be unnecessary for the initial visual rendering.
Use browser performance tools to identify resources that are discovered late or contribute to rendering delays.
Step 2: Send Hints Before the Final Response
A server or supported intermediary can send a 103 response with the appropriate headers.
Conceptually, the response looks like this:
HTTP/1.1 103 Early Hints
Link: </assets/dashboard.css>; rel=preload; as=style
The server then continues its work and sends the final HTML response when ready.
The exact configuration syntax depends on the server or platform. Do not assume that every framework exposes a direct API for sending informational responses. Some environments handle Early Hints at the reverse-proxy or CDN layer instead.
Step 3: Verify the Response Sequence
Use browser developer tools or an HTTP diagnostic client to verify that the server actually sends a 103 response before the final response.
Check that:
The status code is 103.
The Link header contains the intended resource.
The final response follows correctly.
The hinted resource is fetched as expected.
No unnecessary duplicate resource downloads occur.
Also verify behavior through the production network path. A reverse proxy, load balancer, or CDN may change how informational responses are handled.
Step 4: Measure Performance
Compare the page before and after enabling Early Hints.
Useful measurements include:
Time to First Byte (TTFB).
Largest Contentful Paint (LCP).
First Contentful Paint (FCP).
Resource request start times.
Duplicate downloads.
Network usage and cache behavior.
Early Hints may improve rendering without substantially changing the time at which the final HTML response begins. For this reason, measure the complete loading experience rather than relying on TTFB alone.
Choosing Which Resources to Preload
The effectiveness of Early Hints depends heavily on resource selection.
Preload Critical Stylesheets
Stylesheets can block rendering while the browser waits for the CSS needed to display the page.
If the server knows that a particular stylesheet will be used, an Early Hints response can allow the browser to start downloading it before the HTML arrives.
HTTP/1.1 103 Early Hints
Link: </assets/critical.css>; rel=preload; as=style
Use the same URL in the final HTML so the browser can reuse the downloaded resource.
Preload Important Fonts Carefully
A page may need a specific font to render its main heading or primary content.
HTTP/1.1 103 Early Hints
Link: </assets/heading.woff2>; rel=preload; as=font; crossorigin
Preloading fonts that are not used immediately can waste bandwidth. Only preload fonts that are likely to contribute to the initial render.
Avoid Preloading Everything
It may seem useful to preload every stylesheet, script, image, and font. In practice, this can make performance worse.
Each preload competes for network resources. If too many low-priority resources start downloading early, the browser may have fewer resources available for the content that matters most.
Choose resources based on actual loading behavior and validate the results through performance measurements.
HTTP 103 Early Hints vs. Resource Hints in HTML
Browsers already support resource hints in HTML, including preload and preconnect.
The difference is when the browser receives the information.
Approach | When the browser receives the hint | Main benefit |
|---|
Early Hints | Before the final response is ready | Allows resource loading to start during server processing |
HTML preload | After the browser receives and parses enough HTML or related headers | Helps load important resources before normal discovery |
HTML preconnect | When the browser encounters the hint | Can establish a connection to another origin earlier |
Early Hints is particularly useful when the server needs significant time to generate the HTML and can identify important resources in advance.
If the final HTML arrives quickly, or if the browser already discovers critical resources early, the additional benefit may be small.
Common Mistakes to Avoid
Mistake | Why it causes problems | Better approach |
|---|
Treating a 200 response with a Link header as Early Hints | The hint arrives with the final response instead of before it | Verify that the server sends an actual 103 response |
Preloading too many resources | Critical resources compete for bandwidth | Preload only resources needed early |
Sending incorrect resource types | The browser may prioritize or process the resource incorrectly | Use the correct as value |
Preloading fonts without matching request settings | The browser may download a font more than once | Match the final font request, including cross-origin behavior |
Assuming every browser acts on every hint | Browser behavior and support vary | Test the target browsers and production environment |
Ignoring CDN and proxy behavior | Informational responses may not pass through as expected | Verify the complete request-response path |
Measuring only TTFB | Rendering may improve even when TTFB does not | Compare user-centric rendering metrics and resource timing |
Best Practices for Production Applications
Start With Performance Measurements
Use browser performance traces to identify resources that are discovered too late. Early Hints should solve a measured problem rather than be enabled without a clear objective.
Send Hints as Early as Possible
The benefit comes from starting resource loading while the server is still processing the request. Sending the hint immediately before the final response provides little opportunity for parallel work.
Keep Hints Accurate
Only advertise resources that are appropriate for the requested page. If different routes use different stylesheets or scripts, generate hints according to the route rather than sending the same list for every response.
Consider Caching
A resource that is already available in the browser cache may not need to be downloaded again. Evaluate cache behavior when measuring Early Hints performance.
Test Under Realistic Network Conditions
The benefit can vary with latency, bandwidth, server processing time, and resource size. Test under conditions representative of your users rather than relying only on a fast local connection.
Retain a Correct Final Response
Early Hints is supplementary. The final response must still provide the requested content and the necessary resource references. The application should remain functional when the browser ignores the hints.
Advantages and Disadvantages
Advantages
Allows critical resource loading to begin before the final HTML response is ready.
Enables the browser and server to perform useful work concurrently.
Can improve rendering performance on pages with slow server-side processing.
Works with existing resource hints such as preload.
Can be implemented at the server or intermediary layer without changing the entire frontend architecture.
Disadvantages
Requires support in the server or intermediary infrastructure.
Benefits depend on the browser, network conditions, and resource-loading behavior.
Incorrect hints can waste bandwidth or cause duplicate downloads.
Adds configuration and testing requirements across proxies, CDNs, and application servers.
Does not eliminate the need to optimize server response time or the final HTML.
Summary
HTTP 103 Early Hints allows a server to send preliminary resource-loading information before returning the final response. By using Link headers with suitable resource hints, an application can help the browser start downloading critical assets while server-side processing continues.
To use Early Hints effectively, identify resources that are needed early, send accurate hints before the final response, and verify that the entire production network path supports the intended behavior. Measure rendering metrics such as Largest Contentful Paint and inspect resource timing to confirm that the change improves the user experience.
Early Hints is not a replacement for optimizing backend processing, caching, or resource delivery. It is an additional performance technique that reduces unnecessary waiting when the server knows what the browser will need before the page is ready.
Join the conversation! Your thoughts help the community grow.