HTTP Client Hints 介紹
最近幾年各種 Web 技術一直在爆炸式發展,每天都有大量新東西涌現出來。針對這個現象,業內兩位大佬最近先后發文表達了自己的觀點: Stop pushing the web forward 、 Is the web platform getting too big? 。其實很早之前我就意識到以我目前的精力,吃透所有 Web 新技術幾乎是不可能完成的任務,我關注新技術的側重點放在了性能優化上。
今天我要向大家介紹的技術是:HTTP Client Hints,也與性能優化有關。利用這項技術,HTTP 客戶端(通常可以認為是瀏覽器)能夠主動將一些特性告訴服務端,以便服務端更有針對性地輸出內容。這項技術由我們熟知的 Ilya Grigorik 提出,目前還處在較為早期的階段,較為正式的描述文檔可以在 這里找到 。目前 Chrome 46 (beta) 已支持它,IE 和 Firefox 則還在考慮中。
其實之前瀏覽器已經將很多自身特性放在 HTTP 請求中,例如下面這些頭部字段:
- User-Agent:提供瀏覽器類型及版本、操作系統及版本、瀏覽器內核等信息;
- Accept:表明瀏覽器支持哪些 MIME type(例如 Chrome 通過 Accept 表明自己支持 image/webp 圖片格式);
- Accept-Encoding:表明本瀏覽器支持哪些內容編碼方式(例如:gzip、deflate、sdch);
- Accept-Language:表明本瀏覽器支持那些語言;
通過以上這些頭部字段,我們已經可以針對不同客戶端輸出不同內容。例如本博客對支持 Webp 格式的瀏覽器會使用 Webp 來減少圖片大小;本博客還會通過 User-Agent 針對 IE 老版本禁用 localStorage 緩存策略。
但是有一些瀏覽器特性,我們無法直接獲取,如屏幕分辨率、設備像素比(devicePixelRatio)、用戶帶寬等。而在移動 Web 中,為了盡可能節省用戶流量,需要輸出尺寸最合適的圖片資源。為了解決這個問題,常見的方案有:1)使用 JS 獲取這些特性,動態拼接圖片 URL;2)使用 HTML 中的 sizes 和 srcset 屬性、picture 標簽或 CSS 中的 image-set 屬性來實現響應式圖片。方案 1 很簡單,這里略過;方案 2 網上有很多相關文章,不熟悉的同學可以自行搜索「響應式圖片」了解下。
這里看一個使用方案 2 中提到的 picture、sizes 和 srcset 實現的響應式圖片代碼( via ):
<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 --> <img src="/image/thing.jpg" width="50%"> </picture>
這段冗長的代碼只是為了實現一張響應式圖片,盡管有一些夸張,實際使用時一般不會寫這么全,但從中可以得到一個結論:在客戶端實現的策略越多,HTML 體積就越大越冗余,可維護性和可讀性就越差。
而使用了 HTTP Client Hints 之后,瀏覽器在頁面發起子資源請求時,會通過新增的一系列頭部字段帶上分辨率、設備像素比、圖片寬度等信息,使得各種復雜的策略可以挪到服務端去實現了。下面來看一看具體細節:
首先,有了支持 HTTP Client Hints 的瀏覽器之后,頁面上還需要顯式啟用它。這是因為不是所有服務端都實現了響應式輸出策略,每次都發送這些新增的頭部可能會造成浪費。
與往常一樣,這個功能也可以通過 HTTP 響應頭和 meta 標簽兩種方式開啟并配置:
Accept-CH: DPR, Width, Viewport-Width
或:
<meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width">
在啟用了 HTTP Client Hints 的頁面中,所有子資源請求(無論什么類型,無論什么方式創建),都會攜帶 Accept-CH
屬性中所指明的頭部,例如:
Accept: image/webp,image/*,*/*;q=0.8 Accept-Encoding: gzip, deflate, sdch Accept-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.2 Connection: keep-alive DPR: 2 Host: qgy18.imququ.com User-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.36 Viewport-Width: 1280 Width: 128
有了這些頭部,圖片服務器可以知道客戶端的 devicePixelRatio 是 2、圖片寬度是 128px、支持 Webp 格式,所以輸出 256px 的雙倍 Webp 圖最合適。但是瀏覽器怎么知道這個圖片需要作為雙倍圖來使用呢(也就是說還是顯示為 128px)?這就需要在響應頭中增加下面這個字段作為 DPR 的回應:
Content-DPR: 2
需要注意的是,請求頭中的 Width 字段,是根據 img 標簽上的 sizes 屬性算出來的。如果圖片沒有指定 sizes,或者圖片請求是通過 JS 創建的,瀏覽器無法得知 Width,也就不會攜帶這個頭部。
實際上,除了 DPR、Viewport-Width 和 Width 之外,文檔還規定了兩個字段,但是經過我的測試 Chrome 46 并沒有支持它們,這里簡單介紹下:
- Downlink:用來指示當前網絡的下行鏈路帶寬,單位是 Mbps;
- Save-Data:用來指示當前瀏覽器是否工作在省流模式之下,取值為 1 或 0;
可以看出這兩個屬性,也是為了盡可能給用戶節省帶寬而設計的。可以預見,后續還會有更多字段加到 HTTP Client Hints 協議中來。隨著 HTTP/2 的普及,頭部壓縮使得增加幾個頭部字段帶來的開銷變得很小了。
值得注意的是,使用了 HTTP Client Hints 之后,服務端針對同一個 URL 可能會輸出不同的內容,所以無論是中間節點,還是瀏覽器,在實現響應 Cache 時必須小心,需要針對不同的情況緩存多份內容。這需要用到 HTTP/1 中的 Vary
響應頭,例如:
Vary: DPR, Width, Downlink
表明如果需要緩存這個響應,在生成緩存 Key 的時候需要將請求頭中的 DPR、Width 和 Downlink 的值計算進去。
好了,HTTP Client Hints 技術就介紹到這里。很欣慰地看到,大部分 Web 新技術都是在給 HTML、CSS 和 JavaScript 增加功能和特性,而這項技術卻是把之前復雜的代碼和邏輯往后移,讓我們的 HTML 代碼能夠輕裝上陣。一些開源圖片處理系統已經開始支持這個新特性了,國外的一些 CDN 托管服務肯定也在蠢蠢欲動,我十分期待它的未來。