Sites are still loading too slowly. At the most critical moment of the boot process, the feed is often almost completely idle. The new technology proposed by the engineer FastI's Kazuho Oku will help to better use this critical first couple of seconds.

Have you ever downloaded a website on your phone - and looked at a page without text for 10 seconds? No one likes to sit and stare at a blank screen while some unusual font loads. Therefore, it makes sense to transfer the loading of such important things to the earliest possible time. Preload Link rel = preload had to partially solve the problem. The first thing the browser does is to parse the HTTP headers, so this is the perfect place to point to the preloading of a resource that will definitely be needed later.

Internet is slow by default.

Let's see what happens if you don't use preloading. The browser can start downloading resources only after it has discovered that it needs them. This happens most quickly for resources that are in HTML at the time of the initial parsing of the document (for example, <script> , <link rel=stylesheet> and <img> ).

Slower downloads resources that are found after building the render tree (this is where the page slows down because of the font loading, because to understand this, you first need to load the style sheet, parse it, build the CSS object model, and then render tree).
')
Resources that are added to the document using JavaScript loaders that are triggered by events like DOMContentLoaded . If you put it all together, we get a non-optimized and rather meaningless waterfall. Much of the time the channel is idle, and resources are loaded either earlier than necessary, or too late:

Link rel = preload helps a lot

In the past few years, the situation has improved thanks to Link rel = preload . For example:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

Thanks to these directives, the browser can start downloading resources immediately after receiving the headers and before starting the analysis of the HTML body:



This is a significant improvement, especially for large pages and critical resources that would otherwise be discovered late. Especially for fonts, but anything can become a critical resource, for example, a data file needed to load a JavaScript application.

However, we can do more. After all, the browser does not do anything between when it finishes sending the request and when it receives the first bytes of the response (a large green fragment on the initial request is higher).

We engage the time "server reflection" with the help of "early tips"

On the other hand, the server is really busy. It generates a response and determines whether it is successful or not. After accessing the database, API calls, authentication, etc. the server may decide that the correct answer is a 404 error.

Sometimes server thinking time is shorter than network latency. Sometimes much more. But it is important to understand that they do not overlap. While the server is thinking, we are not sending data to the client.

But it is interesting that before generating the answer you already know some styles and fonts that need to be loaded to display the page. After all, error pages usually use the same corporate identity and design as regular pages. It would be great to send these headers Link: rel=preload even before the server . It is for this purpose that the Early Hints standard “ Early Hints ” is conceived, specified in RFC8297 from the HTTP Working Group sponsored by my colleague Kazuho Oku from Fastly. Appreciate the magic of several status lines in one answer :

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

The server can record the first, so-called “informational” response code , as soon as it receives the request, and issue it to the network. Then it will determine the real reaction and its generation. Meanwhile, in the browser you can start preloading much earlier:



Of course, this will require certain changes in browsers, servers and CDN, and some browser developers have expressed reservations about the difficulties of implementation. Therefore, it is still unclear when these headers can be put into operation. You can track progress in public trackers for Chrome and Firefox .

We expect that ultimately you will be able to give Early Hints headlines directly from Fastly, while still sending requests in the standard way. We have not yet decided how to expose the interface through the VCL, so please let us know if you have any suggestions for this!

But what about HTTP / 2 Server Push?

With HTTP / 2 comes a new technology called Server Push, which seems to solve the same problem as Link rel = preload in the Early Hints answer. Although it really works (and you can even quickly generate custom pushy from the edge servers in Fastly), but there is a significant difference in several points:

• The server does not know about the availability of the resource at the client, so it often pushes it unnecessarily. Due to network buffering and latency, the client usually cannot cancel sending before receiving all the content. (Although there is a possible solution to this problem, in the form of the proposed Cache Digest header, on which Kazuho works with Yoav Weiss from Akamai).
• Running resources are bound to a connection, so it is easy to start a resource that the client does not use, as it tries to get it through another connection. Clients may need to use a different connection because the resource is in a different source with a different TLS certificate or because it is retrieved in a different credential mode .
• H2 Push is not very consistently implemented in different browsers. Therefore, it is difficult to predict whether it will work or not in your particular case.

One way or another, Early Hints and Server Push offer different tradeoffs. Early Hints tips provide more efficient use of the network in exchange for additional packet exchange. If you assume a low network latency and a long time to think about the server, then Early Hints is the right solution.

However, this is not always the case. Let's be optimistic and imagine that humans will soon settle on Mars. They will view the web pages with a delay of 20-45 minutes for each packet exchange, so the additional exchange is extremely painful, and the server time is insignificant compared to it. Server Push wins easily here. But if we ever browse the web from Mars, we’ll rather download some kind of data package, something like the web packages now offered and signed exchanges .

Extra Bonus: Accelerated Minimizing Request

Although Early Hints is supposed to be used primarily in the browser, there is an interesting potential benefit for the CDN. When Fastly receives many requests for the same resource, we usually send only one of them to the source, and the rest are put in the waiting queue. This process is known as request collapsing . If the response from the source includes Cache-Control: private , then you should remove all requests from the queue and send them to the source separately, because we cannot use one answer to satisfy several requests.

We cannot make a decision until we receive a response to the first request, but if Early Hints support, if the server issues an Early Hints response with the Cache-Control header, then we know much earlier that the queue cannot be minimized into one request, but instead immediately send to the source all requests from the queue.

Order less critical content with priority prompts

Early prompts are a great way to access some of the most valuable objects in the queue (waterfall): when the network is idle, the user is waiting, there is only one request on the way, and there is nothing on the screen. But as soon as HTML is loaded and the page is analyzed, the number of resources that need to be loaded increases dramatically. Now it is important not to load resources as quickly as possible, but to load them in the correct order. Browsers use a strikingly complex array of heuristics to independently determine the boot priority, but if you want to override them, in the future this can be done with the help of Priority Hints :

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

With this new attribute of importance, developers can control the order of loading resources in the event of competition for the network. Perhaps, low priority resources can be deferred until the processor and the network are released, or depending on the type of device.

Can it be used?

Neither the early prompts nor the priority prompts have yet become the standard. Recently H2O, the HTTP / 2 server used and supported by Fastly, has begun to use Early Hints (see PR 1727 and 1767 ), and there is an intention to implement Priority Hints in Chrome , as well as active tracking of 1xx responses. At the same time, there is no harm in starting to send Early Hints right now - and if you want to get ahead of the trend, go ahead!