Chrome and Fastly are currently running an experiment to validate a web performance tool — and we need your help!
Remember all of the hype around Server Push? Since HTTP/2 shipped, it’s become increasingly clear that while the performance problem that it was designed to address is important, Server Push was not the right approach. Instead, the Preload mechanism has become a widely-used replacement that delivers most of the benefits of Server Push without the risk or complexity.
However, there are still situations where Preload doesn't deliver great performance. Andrew Betts, our principal developer advocate, talked about a potential improvement in a blog entry two years ago: the 103 Early Hints HTTP status code, proposed by Fastlyan Kazuho Oku. Unfortunately, that proposal stalled because no browsers implemented Early Hints, so they weren’t useful for most web traffic.
Since then, it’s become clear that preload hints are here to stay; the HTTP Archive’s 2019 Almanac reported that they’re used on 16% of web sites. At the same time, take-up of HTTP/2 Server Push is still around the 0.04% of connections that Chrome reported back in 2017, according to Firefox telemetry.
That makes 103 Early Hints a lot more interesting as a potential performance improvement. However, supporting it is a lot of work for browser vendors, so they want to gather data on how much it improves things before spending the time and engineering resources.
That’s where the experiment comes in.
To get that data, Chrome has started tracking how much time it would have saved if the Early Hints that it receives had been acted upon. It won’t yet follow those hints, so you won’t see any performance improvement.
However, by comparing when the hints are received to when the real responses are received, they can estimate how much performance improvement 103 Early Hints will offer. The Chrome team plans to publish the data in aggregate, so that the community can make a more informed decision about the future of 103 Early Hints.
To gather this data, they need sites to start sending the 103 Early Hints status code. To help them get it, Fastly experimentally supports sending this new status code. So if you’re a Fastly customer, you can participate in the experiment.
In particular, we’re looking for content where the server needs to perform some processing before sending a response, but it’s likely that the response is going to reference additional assets that are automatically loaded (like images, scripts or stylesheets). Sending 103 Early Hints allows the client to use the idle bandwidth to download those assets while the server is “thinking.”
<aside> 📘 server push & 103 early hints
传统的 C/S 交互是，客户端请求一个页面，然后页面中引用了一些资源，然后客户端再请求这些资源。
因为服务端实际上能够预判客户端将会请求一些被引用的资源，server push 使得客户端可以在客户端请起以前，就直接推送这些资源给客户端。
但如果客户端已经缓存了这些资源，server push 就会浪费带宽。所以服务端在推送以前，可以先发送 103 early hints，可以理解为一份资源清单，然后客户端可以自行挑选并行下载这些资源。
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 200 OK
Date: Mon, 1 Jan 2023 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1943
<!doctype html>
<html>
...
</aside>
For example, an embedded Fastly Fiddle generates a POST request when it runs:
Once the POST completes processing, it refers to an SVG image, a data stream, and eventually that loads two more SVGs. By using 103 Early Hints, the browser can start loading all three SVGs right after the POST request is received — before the final response even starts.
It doesn’t have to be a POST, either; if an uncacheable (or hard to cache) GET is sent back to the origin, an edge-generated 103 Early Hints response could remove a substantial amount of delay before the browser starts preloading assets.
If you have a site with content like this, it could benefit from 103 Early Hints, and your participation in the experiment will help gather the data that the community needs to make a decision about this feature.