Speed Up Page Loads with HTTP 103 Early Hints in HTTP/2 (2026)

HTTP 103 Early Hints can make your pages feel instantaneous by sending critical resources before the server even finishes processing the main request.

Let’s see this in action. Imagine a user requests /important-page. Normally, the server would:

1. Receive the request for /important-page.
2. Authenticate the user.
3. Query the database for page content.
4. Render the HTML.
5. Send the HTML response.
6. The browser then parses the HTML, finds <link rel="stylesheet" href="/styles.css"> and <link rel="preload" as="script" href="/app.js">, and requests those.

With 103 Early Hints, the server can do this concurrently:

1. Receive the request for /important-page.
2. Start authentication and database queries.
3. While steps 2 and 3 are happening, send a 103 Early Hints response containing Link headers for /styles.css and /app.js.
4. The browser, upon seeing the 103, immediately starts fetching /styles.css and /app.js.
5. Then, the server finishes processing, renders the HTML, and sends the final 200 OK response.

The user’s browser already has the CSS and JS by the time the main HTML arrives, dramatically reducing the time to first paint and interactivity.

The core problem Early Hints solve is the "request-response-request" chain that delays page loads. The browser has to wait for the server’s full response to know what else it needs, even if the server already knows what’s coming. Early Hints break this dependency by allowing the server to proactively communicate critical resource needs.

To implement this, you need a web server that supports sending 103 Early Hints responses and a client (browser) that understands them. The server configuration typically involves specifying which resources are essential for a given route.

For example, in Nginx, you might configure it like this within your server block:

location /important-page {
    # ... your existing proxy_pass or fastcgi_pass ...

    add_header Link "</styles.css>; rel=preload; as=style", "</app.js>; rel=preload; as=script";
    return 103; # This tells Nginx to send a 103 Early Hints response
}

Here, add_header defines the Link headers that will be sent with the 103 status code. The return 103; directive is the crucial part that tells Nginx to stop processing the request after sending these headers and to not send a final 200 OK response itself; the upstream application (your backend) will eventually send the 200 OK. The rel=preload and as= attributes are standard for indicating that these are resources the browser should fetch and how it should prioritize them.

The beauty is that the 103 Early Hints response is not the final response. It’s an informational interim response. The browser treats the Link headers from a 103 just like it would from a 200 OK response. It can also handle multiple 103 responses, or a 103 followed by a 200 OK. If the server doesn’t send a 103, the browser simply proceeds with the traditional request flow. If the server sends a 103 and then later a 4xx or 5xx error, the browser will likely discard the preloaded resources as they are no longer relevant to the final (error) page.

The Link header is the workhorse here. It’s a standardized way to communicate relationships between documents. In the context of 103, it’s used to declare "here are some resources your browser should start fetching immediately because they are needed for the eventual content of this URL." The as= attribute is vital because it hints to the browser about the resource’s type (script, stylesheet, font, image, etc.), allowing it to prioritize and parse it correctly.

One common pitfall is over-hinting. Sending too many Link headers with a 103 can actually hurt performance by overwhelming the browser with too many concurrent requests, potentially exceeding its connection limits or causing it to waste bandwidth on resources that might not be strictly necessary. The goal is to hint at the most critical assets that unlock the initial render and interactivity – typically the main CSS and JavaScript bundles.

The next step after successfully implementing Early Hints is understanding how they interact with other performance optimization techniques like HTTP/2 Server Push, and how to dynamically generate these hints based on user context or A/B testing.