Last week, Google Chrome with version 103, added support for HTTP 103 (Early Hints)! Yep, they did time the release very well. In this post, we'll learn more about what is it and it's implications for the web.
What is it?
Early Hints is a recent addition to the HTTP Informational response(1xx) status codes. Information response codes are temporary status codes used to inform the client about the status of the request, while the server is processing the request to send the final response code(2xx-5xx).
Early Hints is specifically used to pass information on the resources that may be preloaded by the client. The client will eventually need these resources when it renders the final response from the server.
Early Hints are like the "<link rel="preload" />" tags on the HTML response, but happens to do the job way earlier in the HTTP life cycle.
In other words, Early Hints facilitates the browser to do effective parallelization of resource fetching by providing the hint early on, indirectly leading to a better user experience.
How does it work?
From the above explanation, we understood that Early Hints mainly helps in effective utilization of the waiting time. We can visually see this from the interactive illustration below on how it can impact the user experience in terms of the Largest Contentful Paint metric.
Here is the structure of a typical Early Hints response:
HTTP/1.1 103 Early HintsLink: </style.css>; rel=preload; as=styleLink: </script.js>; rel=preload; as=script
The value of
Link header takes the
href of the resource that is to be preloaded, followed by the necessary attributes (as supported by the
separated by a semicolon.
<link rel="preload" href="/style.css" as="style" /> in the HTML response would translate to
Link: </style.css>; rel=preload; as=style in
the Early Hints response.
The Early Hints standard as of now has support for all the functions possible with the http
<link rel="preload" /> tag with support for preloading
fonts, etc by providing the corresponding
as attribute. And a single http 103 response can contain multiple
headers allowing as many resources to be preloaded.
If you are really interested in knowing the nitty-gritty details, you can check out the Early Hints specification here.
Early hints cannot be sent as a reply to an HTTP/1.1 client, as it might consider the
Link header as a part of the body and might request them with the same
connection, leading to cross-origin information disclosure vulnerability.
The Early Hints is still on the very early stages of the implementation. So, it is right now only supported by Chrome.
Ideal Placement - CDN Edge Servers
Another take away from the above the illustration: The earlier the server sends the hints, the higher is the impact on the page render performance.
So, one of the best places to send the hints for a request is the CDN edge server that stay very close to the client and can send a hint response as soon as the client requests a page. The client can load the preload resources while the CDN proxies the request on to the origin servers and returns the response.
With the recent increase in the adoption of the Server Side Generation(SSG) for the webpages, the CDN Edge servers adds more potential to the Early Hints. During the build, the SSG tool could could emit a manifest of sorts that can be used by the compatible edge servers to map the preload resources to use in their Early Hints response.
Or the Edge servers can analyze and gather some heuristics on the traffic and send the hints based on that. Cloudflare has beta support feature for Early Hints that does something similar.
This is only the start and there is a huge potential to Early Hints in the future! 🚀