HTTP protocol is used for a large variety of workloads. While APIs and IoT applications are intriguing, popular, and fun to develop, a significant amount of internet traffic is still directed towards conventional websites, accessed by a standard web browser.
These conventional websites always consist of various resources: images, videos, scripts, and other auxiliary files. Since the invention of the Web, the number of resources per page has steadily increased.
Each resource also necessitates a separate request to be initiated by the browser. To address this, the developer community has developed plenty of methods to improve loading speed, resulting in diverse optimization technologies. HTTP/1.1 introduced keep-alive connections, HTTP/2 further improved this with streams, and HTTP/3 reduced the number of network roundtrips, likely to a minimum. The recently developed standard for Early Hints takes it even further.
Protocol Interaction
When a web page is requested, the server might already know that each client will need a particular set of pictures, scripts, CSS files, and so on. Sometimes, that determination is made before the complete HTML is generated on the backend server or a static HTML is sent over the wire.
For example, when you load nginx.org, the server knows that nginx.org/css/style_en.css will also be loaded.
The Early Hints standard enables the server to send an informational response with HTTP code 103, prompting the browser to start downloading the mentioned files, possibly before fully processing the main page.
The Early Hints response will look like this:
103 Early Hint
Link: </css/style_en.css>; rel=preload; as=styleThe parameters of the response header instruct to use this response as a style.
Another example is designed for websites that require multiple connections to other resources, such as third-party APIs. With a specially crafted 103 response, the browser can be instructed to connect to these other servers before fully processing the initial page, saving a lot of time compared to the longer process of connecting to new servers behind strong encryption.
Such response will look like this:
103 Early Hint
Link: <https://cdn.example.com>; rel=preconnect, <https://cdn.example.com>; rel=preconnect; crossoriginYou can read the full RFC 8297 for Early Hints in An HTTP Status Code for Indicating Hints.
Kazuho Oku, the standard’s author, wrote a few words for NGINX:
I’m delighted to hear that NGINX is testing support for 103 Early Hints. I know that many people run NGINX in front of their web applications, it makes perfect sense to send early hints while the web applications generate the response.
NGINX Development of Early Hints
In March 2025, we introduced an experimental patch for Early Hints. You can find it on our official GitHub repo here. The patch supports adding static definitions of Early Hints as a parameter for the add_header directive and proxying of Early Hints from the backend servers.
Note: To apply this patch, you need to know how to compile NGINX from source and be well-versed in traffic monitoring and measurement. This is intended for advanced users.
Architectural Patterns
Let’s look at three potential methods of using Early Hints in a real-world systems.
First is the simple method of statically defining Early Hints for some or all pages on the server:
In this case, the content of the hints cannot quickly change without reconfiguration. This is usable for the main pages of most websites and for well-established websites with static content.
The second pattern shows that the backend application has no knowledge about Early Hints technology, and the hints are added by the load balancer.
In the third pattern, the hints are added by the backend server, and the load balancer will be used for proxying the hints to the end users.
Each of those architecture patterns has their own advantages and disadvantages. As with any emerging technology, fully utilizing it increases the complexity of your system.
Challenges with Early Hints
Early hints are best designed for the HTTP/2 and HTTP/3 family of protocols. These protocols have the ability to send special frames outside of main traffic processing. In addition, informational responses lay out to these features very well. However, not too many backends support HTTP/2 and HTTP3 out of the box, and these protocols are very complicated for proxying and load balancing. At NGINX, we’re actively working towards supporting Early Hints, but full support for all backend servers and their HTTP protocols is a longer task.
Another aspect of Early Hints is browser support. While browsers are allowed ignore Early Hints, it is ultimately the browser’s responsibility to modify its own behavior based on knowledge of the hints. Browsers can bump their loading priorities, use new network connections, or apply special security restrictions.
Note: We cannot predict how well this support will work in a variety of current and future browsers. We also cannot predict if providing Early Hints before the full page will increase the websites’ security risks.
Early Hints are a new and complicated traffic pattern. Historically a similar feature of “Server Push” was developed with HTTP/2. However, Server Push has not become popular and even though NGINX supports it, it was not embraced by the community. We cannot predict if Early Hints will follow the same fate or not.
Respond with Your Thoughts
The history and development of HTTP protocol include many features that were introduced in theory but did not get significant traction among the broader internet user base. Is this discussion focused on a similar type of feature? Only the future will show.
As valued users of NGINX, you are the drivers of that future. Please let us know on GitHub or the new NGINX Community Forum how Early Hints have worked for you or where you might have found challenges.
