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:

Code
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:

Code
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:

  1. The browser sends an HTTP request.

  2. The server or an intermediary identifies resources that are likely to be needed.

  3. The server sends an HTTP 103 response containing preliminary headers.

  4. The browser may begin loading the hinted resources.

  5. The server finishes processing the request.

  6. The server sends the final response, such as HTTP 200 OK.

  7. 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

Code
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.

Early Hints commonly uses the HTTP Link header to describe resources that the browser can prepare to load.

For example:

Code
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:

Code
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:

Code
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:

Code
/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:

Code
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.

Code
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.

Code
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.