103 Early Hints: using server think time to start loading sooner

When a browser requests a page, it often sits idle while the server prepares it: querying the database, rendering templates, calling external services. On a dynamic site this can take hundreds of milliseconds. Yet in many cases the server knows from the very start which resources the page will need: the same stylesheet, the same fonts, the same main script. The 103 Early Hints status code lets it say so immediately, so the browser can use that wait to start downloading.

How it works

103 is an informational response: it does not replace the final response, it precedes it. The exchange goes like this:

1. the browser requests the page;
2. the server, before the HTML is even ready, sends a 103 response with one or more Link headers;
3. the browser reads those headers and starts connections or downloads;
4. when the page is ready, the server sends the final response, for example a 200 with the HTML.

HTTP/1.1 103 Early Hints
Link: </css/style.css>; rel=preload; as=style
Link: <CDN_ORIGIN>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Link: </css/style.css>; rel=preload; as=style
...

When the HTML arrives and the browser discovers the reference to the stylesheet, the file is already partly or fully downloaded. In the best case, the gain equals the server's processing time.

When it pays off

Early Hints delivers the most when there is a significant wait between the request and the first byte of HTML. Typical situations are:

• pages generated dynamically by a CMS or an application, with high TTFB;
• personalized pages that cannot be stored in a shared cache;
• sites behind a CDN, where the edge node close to the user responds immediately with the 103 while waiting for the page from the origin server.

Conversely, if the HTML is already served from a cache in a few milliseconds, the 103 has almost no window to exploit.

What to send

Current browser support covers mainly two kinds of hints:

The golden rule is the same as for preload in HTML: list only truly critical resources used by all or nearly all pages the 103 applies to. Preloading a resource the page will not use wastes bandwidth at exactly the moment it matters most. A common mistake is to send the same resource list for every page on the site, including those built on a different template.

For font preloads, as in HTML, the crossorigin attribute is required, otherwise the downloaded resource is not reused and the font is requested a second time.

Limitations and compatibility

A few constraints to know before turning it on:

• navigations only: the 103 is considered for page requests, not for subresources;
• HTTP/2 and HTTP/3: Chrome, for example, only takes Early Hints into account on HTTP/2 or later connections;
• browser support: browsers that do not handle it ignore the informational response and wait for the final one, so there are no negative effects;
• intermediaries: old proxies or servers may not forward 1xx responses correctly. It is worth checking the whole chain, from origin server to CDN;
• redirects: if the final response is a redirect to another origin, the hints received may be discarded.

How to enable it

There are two main routes:

1. from the CDN: several CDN providers offer Early Hints as a feature you can switch on. The edge node stores the Link headers found in a page's 200 responses and, on subsequent requests, sends them as a 103 while waiting for the origin. This is the simplest way, because the HTML only needs to already include correct Link headers;
2. from the application server: some web servers and frameworks let you explicitly send a 103 before the final response. It gives more control, but requires the stack to support sending informational responses.

Either way, it is good practice to keep the same Link headers in the final response too, so browsers without 103 support still benefit.

Verifying

In the DevTools Network panel, resources started thanks to Early Hints are recognizable because they begin before the HTML arrives, and the initiator column says so. From the command line, curl -v shows the 103 response before the final one, if the server sends it. To assess the real effect, compare LCP and FCP in user data with and without the feature: in my work the benefit showed up mostly on pages with high TTFB, while on pages already served from cache it was negligible.

In short

• 103 Early Hints announces critical resources while the server prepares the page.
• It is most useful with high TTFB and dynamic or personalized pages.
• Send only preconnect and preload for resources the page really uses.
• It works on navigations, over HTTP/2 or later, and browsers without support ignore it.
• Enable it from the CDN or the server and verify in DevTools and in field data.