Introduction to HTTP Client Hints

Introduction to HTTP Client Hints

In recent years, various Web technologies have been explosively developing, and many new things have emerged every day. To address this problem, the two bosses in the industry have recently published their views: Stop pushing the web forward, Is the web platform getting too big ?. In fact, I realized that with my current energy, it was almost impossible to thoroughly understand all the new Web technologies. I focused on performance optimization.

The technology I want to introduce to you today is HTTP Client Hints, which is also related to performance optimization. Using this technology, the HTTP client (usually considered as a browser) can actively tell the server about some features so that the server can output content more specifically. This technology was proposed by our well-known Ilya Grigorik and is still in its early stages. More formal descriptions can be found here. Chrome 46 (beta) currently supports it, while IE and Firefox are still under consideration.

In fact, the browser has put many of its own features in the HTTP request, such as the following header fields:

• User-Agent: Provides information such as the browser type and version, operating system and version, and browser kernel;
• Accept: indicates the MIME types supported by the browser (for example, Chrome uses Accept to indicate that it supports image/webp image formats );
• Accept-Encoding: indicates the content Encoding methods supported by the browser (such as gzip, deflate, and sdch );
• Accept-Language: indicates the languages supported by the browser;

With the above header fields, we can output different contents for different clients. For example, this blog uses Webp to reduce the image size for browsers that support Webp format. This blog also uses the User-Agent to disable the localStorage cache policy for older versions of IE.

However, we cannot directly obtain some browser features, such as screen resolution, devicePixelRatio, and user bandwidth. In mobile Web, in order to save user traffic as much as possible, the most appropriate image resources need to be output. To solve this problem, common solutions include: 1) Use JS to obtain these features and dynamically splice image URLs; 2) use the sizes and srcset attributes in HTML, the picture tag, or the image-set attribute in CSS to implement responsive images. Solution 1 is very simple. I skipped it here. solution 2 has many related articles on the Internet. If you are not familiar with it, you can search for "responsive images.

Here, let's take a look at the responsive Image Code (via) implemented by picture, sizes, and srcset mentioned in solution 2 ):

HTML<picture> <!-- serve WebP to Chrome and Opera --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w, /image/thing-800.webp 800w, /image/thing-1200.webp 1200w, /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w" type="image/webp"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w, /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w, /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w" type="image/webp"> <!-- serve JPEGXR to Edge --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.jpgxr 200w, /image/thing-400.jpgxr 400w, /image/thing-800.jpgxr 800w, /image/thing-1200.jpgxr 1200w, /image/thing-1600.jpgxr 1600w, /image/thing-2000.jpgxr 2000w" type="image/vnd.ms-photo"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.jpgxr 200w, /image/thing-crop-400.jpgxr 400w, /image/thing-crop-800.jpgxr 800w, /image/thing-crop-1200.jpgxr 1200w, /image/thing-crop-1600.jpgxr 1600w, /image/thing-crop-2000.jpgxr 2000w" type="image/vnd.ms-photo"> <!-- serve JPEG to others --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w, /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w, /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w, /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w, /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w"> <!-- fallback for browsers that don't support picture --> </picture>

This lengthy code is only used to implement a responsive image. Despite some exaggeration, it is generally not written in practice, but we can draw a conclusion: the more policies implemented on the client, the larger the HTML size, the more redundant the maintainability and readability.

After the HTTP Client Hints is used, when a browser sends a sub-resource request to the page, it adds resolution, device pixel ratio, image width, and other information through a series of new header fields, this allows various complex policies to be implemented on the server. Let's take a look at the details below:

First, you must enable the HTTP Client Hints browser explicitly on the page. This is because not all servers have implemented a responsive output policy, and sending these new headers each time may cause waste.

As usual, this function can be enabled and configured in two ways: HTTP response header and meta tag:

Accept-CH: DPR, Width, Viewport-Width

Or:

<meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width">

On the page where HTTP Client Hints is enabled, all sub-resource requests (no matter what type, no matter how they are created) will carryAccept-CHThe header specified in the property, for example:

BASHAccept: image/webp,image/*,*/*;q=0.8Accept-Encoding: gzip, deflate, sdchAccept-Language: zh-CN,zh;q=0.8,en;q=0.6,en-US;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2,cs;q=0.2,pt;q=0.2,ko;q=0.2Connection: keep-aliveDPR: 2Host: qgy18.imququ.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.13 Safari/537.36Viewport-Width: 1280Width: 128

With these headers, the image server can know that the devicePixelRatio of the client is 2, the image width is PX, And the Webp format is supported. Therefore, it is best to output a PX double Webp image. But how does the browser know that this image needs to be used as a double image (that is, it is displayed as 128px )? In this case, you need to add the following field in the Response Header as the DPR response:

Content-DPR: 2

Note that the Width field in the request header is calculated based on the sizes attribute on the img tag. If sizes is not specified for the image, or the image request is created using JS, the browser cannot know the Width, so it will not carry this header.

In fact, in addition to DPR, Viewport-Width, and Width, the document also specifies two fields, but Chrome 46 does not support them after my test. Here is a brief introduction:

• Downlink: used to indicate the Downlink bandwidth of the current network. The unit is Mbps;
• Save-Data: indicates whether the current browser is working in streaming mode. The value is 1 or 0;

We can see that these two attributes are designed to save the user bandwidth as much as possible. It is foreseeable that more fields will be added to the HTTP Client Hints protocol in the future. With the popularity of HTTP/2, Header Compression reduces the overhead caused by adding several header fields.

It is worth noting that after the HTTP Client Hints is used, the server may output different contents for the same URL. Therefore, whether it is an intermediate node or a browser, you must be careful when implementing the response Cache. You must Cache multiple copies of content in different situations. This requiresVaryResponse Header, for example:

Vary: DPR, Width, Downlink

This indicates that if the response needs to be cached, the DPR, Width, and Downlink values in the Request Header must be calculated when the cache Key is generated.

Now, the HTTP Client Hints technology is introduced here. We are glad to see that most of the new Web technologies are adding functions and features to HTML, CSS, and JavaScript, but this technology moves the complicated code and logic back, let our HTML code be light loaded. Some open-source image processing systems have begun to support this new feature, and some foreign CDN hosting services are certainly starting to move forward. I am very much looking forward to its future.

This article permanently updates the link address: