Exploring 103 Early Hints Beyond Server Push | Fastly

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.

The experiment

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.”

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. 

Sending 103 Early Hints with Fastly

To enable 103 Early Hints on your site, use the experimental h2.early_hints function in VCL, like this:

sub vcl_recv {
 if (req.url ~ "^/fiddle/") {
   h2.early_hints("link: </images/progress.svg>; rel=preload", "link: </images/icons/server.svg>; rel=preload", "link: </images/icons/arrow.svg>; rel=preload");
 }
}

That sends hints for the three SVG images in response to all HTTP/2 requests whose URL matches the regular expression ^/fiddle/.

Is it safe?

Sending the 103 Early Hints status code from your site should be safe; as recommended in the RFC, Fastly only sends it on HTTP/2 connections, and modern HTTP/2 clients should just ignore it. It’s currently running on the Fastly Fiddle tool with no problems reported.

As with any protocol-level changes, a few clients might have an issue, but in our testing found only  very old, beta HTTP/2 clients might have a problem with 103 Early Hints. We’ve also set up a test page that sends 103 Early Hints, so you can test different clients to see if they’ll break when receiving a non-final 103 status code. If you find a client that does break, please report it using the link there.

Worth noting: In using this feature, Fastly doesn't retain any new information, unless you report a problem with the form.

Help the web out

Many people think Early Hints can help web performance in certain situations, but we won’t know until we get data about it, and without that data, browsers won’t support it. If your site has content like that described above, please consider joining the experiment!

If you’d like to know more, please get in touch with me at mnot@fastly.com.