移動Web加速技術月報第3期

爲推動Web技術的發展，Brilliant Open Web 團隊特推出每個月一期的《移動Web加速技術月報》，該月報將整理較流行的移動Web加速技術，並跟進各項技術的進展和發展方向，以期幫助開發者瞭解或選用相關的技術，把握技術發展趨勢。歡迎關注【OpenWeb開發者】公衆號並回復「加羣」，一塊兒探討相關技術。

做者 | Brilliant Open Web 團隊breezet、chengang、shdong 編輯 | 尾尾

1、內容回顧

在上一期的月報中，咱們爲你們介紹了Web頁面中如何使用預取和預渲染來進行頁面加速，同時也指出了目前瀏覽器提供的預取和預渲染方法所存在的問題以及改進優化的思路。

本期，咱們將再次聚焦到一期討論的瀏覽器緩存、頁面雲端緩存等技術上，詳細展開討論各類頁面緩存技術能達到的效果以及所存在的一些問題。

2、相關技術介紹：雲端頁面緩存策略漫談

近幾年，不管是內容分發平臺仍是瀏覽器廠商都會經過雲端的頁面CDN Cache服務，爲用戶訪問Web頁面提供更快的頁面訪問。

經過更優質的CDN Cache，內容分發平臺或瀏覽器廠商經過中間代理的方式，讓用戶享受了更優質的頁面速度瀏覽體驗。因爲各公司提供的頁面緩存服務在對緩存的處理策略上不盡相同，也致使站點在提供Web服務時，不清楚應該如何配置才能被正確緩存而且對本身業務無其餘負面影響。

本章節會詳細講述其中存在的問題，綜合百度在此方面的處理方案給出建議的通用標準實現。

1. 概述

內容分發平臺或瀏覽器對Web頁面進行服務端的緩存，主要的目的是由於不少的站點服務自己並無提供較好的網絡環境和服務快速響應，經過將此類站點的頁面緩存在CDN Cache等網絡中（頁面代理緩存），能夠是用戶訪問此類站點時享受到極快的頁面加載。

可是，目前雲端緩存的規範是不明確，具體表現爲業界已經默認的規範不屬於任何組織（如x-forward-for），部分規範是瀏覽器提供商（chrome，Firefox）等提出的，並未徹底推動到標準中(如標識預加載的x-moz)，從而致使頁面開發者在本身的頁面可能被緩存的狀況下，沒法正確的保障本身被緩存頁面的用戶體驗以及功能。

本文將從如下幾個方面在總結內容分發平臺或瀏覽器在代理緩存服務策略上的問題和解決方案：

1. Web site option for proxy cache server（web站點針對雲端緩存的配置）
2. Web site access info collection when page cached by proxy server（web站點針對雲端緩存的統計方法）

2. Web site option for proxy cache server（Web站點針對雲端緩存的配置）

本小節主要講述頁面站點在被瀏覽器或內容分發平臺的代理服務緩存時所面臨的問題，並給出對開發者更友好的緩存服務解決方案建議。

存在的問題

下圖是一個用戶訪問站點時的請求所通過的緩存相關的路徑。

瀏覽器部分雲加速服務，對頁面的修改以及緩存對開發者過於透明不可控，包括可是不限於：

• 沒有明確的配置協議，讓控制哪些頁面能夠被緩存，哪些頁面不能被緩存；
• 頁面緩存失效的時間配置，是否沿用HTTP Header中的Cache-Control頭，沒有明確規範，而各種代理緩存服務對此的處理也不一致；

解決方案建議

代理緩存服務自己會在頁面訪問時抓取對應的頁面，所以可遵循如下緩存策略：

• 使用robots.txt文件中新增字段描述站點url pattern粒度的是否容許被緩存；
• robots.txt文件自己可緩存時間用Cache-Control來控制；
• 緩存時間統一用Cache-Control頭來控制緩存超時，用stale-while-revalidate頭來控制平滑更新；
• 對於站點主動配置的緩存系統來講，robots.txt裏邊的禁止相關的內容，效果等同於Cache-Control: no-cache
• 代理緩存服務請求站點時，處理主要流程以下：

  

用例說明

百度搜索結果頁中的一個網站開發者，本身站點的/home/news/data 路徑下的全部頁面都是高時效性的頁面，不但願被任何加速服務緩存。爲了達到這個目的，站長應該在本身站點的robots.txt文件中加入以下內容：

Cache:*
HttpsCacheDisallow:/home/news/data/
HttpCacheDisallow:/home/news/data/
# 對於全部的Cache來講，https和http的在/home/news/data/路徑下的全部內容不容許被緩存
# 若是但願各層加速能平滑更新，那麼能夠在Cache-Control頭裏面寫入以下內容：max-age=864000, stale-while-revalidate=1728000
# 代表：在86400s內本地緩存有效。在172800s內返回舊緩存的同時，異步發起更新。當時間超過172800s時，緩存失效，從新抓取。
複製代碼

全部遵循了緩存規範的服務解析站點的robots.txt文件後，不緩存/home/news/data路徑下的全部內容。知足了開發者的需求。

固然，做爲站長，不能濫用此規範，由於不緩存的頁面每每意味着更慢的加載速度。

在這種場景下，處在HttpsCacheDisallow或者HttpCacheDisallow所配置的Path中的頁面所返回的Cache-Control等header將會僅僅被用來控制瀏覽器端的緩存。

相應的，對於瀏覽器自帶的雲加速服務器來講，方便在瀏覽器上作熱門站點的robots.txt文件，來判斷那些頁面能夠直接不經過本身的雲加速服務，而是直接訪問源站。

3. Web site access info collection when page cached by proxy server

代理緩存服務進行頁面緩存時，也會給站長帶來數據統計上的困擾。本小節試圖從數據統計的方面，提供緩存服務在統計上的一些解決方案。

存在的問題

• 部分頁面強依賴請求的Client IP來作一些策略
• 部分站長鬚要實時知道本身站點的pv特徵
• 緩存後，這些信息尚無明確規範回傳給站長
• 目前，只有FireFox提出了基於x-forward-for的規範，可是這個規範不屬於任何組織

解決方案建議

• 代理緩存服務回傳回源等數據的時候都加上x-forward-for頭來指名真實的用戶IP信息
• HTML中新增用於日誌回傳的標籤，用於告知瀏覽器須要將當前的x-forwad-for發送至對應地址，例如<meta x-forwad-for='true' sendTo='domain/path'>

3、主要技術進展

本月報將收錄移動Web加速技術的主要進展，歡迎讀者一塊兒完善，投稿郵箱：openweb@baidu.com。

Mip：

1. mip-map地圖組件上線，支持百度地圖的定位、地圖控件加載、座標彈窗定製等功能；
2. mip-stats-cnzz 功能升級，可以將頁面的 cnzz 統計請求發送到自定義的 cnzz 服務器節點，修復固定節點的服務不穩定性問題；
3. mip-showmore 功能升級，可以定製展開狀態下的精美的按鈕樣式，讓 showmore 的樣式更加貼合開發者的自身需求；
4. mip-sidebar 升級，彈出時增長平滑的動畫效果，讓彈出的效果更加優美；
5. mip-bind：進行功能完善和升級，在官網上產出詳細的使用說明文檔和示例，幫助開發者更輕鬆使用此功能，同時協助部分電商站點完成 MIP 頁面的該功能的添加；
6. mip-form：去除 password，file等功能限制；
7. 網盟廣告加載速度優化實驗，將投放腳本、廣告位配置提早至 layout 以前加載；
8. 官網文檔開源，開放文檔，作到開源共建。

AMP: 一、 amp-story 默認靜音，添加漸變效果，修復部分兼容性問題，提高組件使用體驗 二、 AdSense / Doubleclick 快速取回 unlayoutCallback 實驗 三、AMP 元素增長API，實現元素的調度時間傳遞給元素自己 四、 amp-analytics 增長新的分析服務商：Alexa Internet，增長參數this.isInabox_，支持基本批處理功能

4、總結

百度在W3C 2017 TPAC會議上針對頁面雲端緩存策略的議題與全球各大互聯網公司有過深刻的交流和討論，也收到了你們的積極響應和回覆。

雲端緩存策略是一項重大的技術創新，但技術野蠻生長的同時也對開發者形成了巨大的困擾，隨着你們對此項技術的普遍深刻應用，雲端緩存策略必然須要統一的標準和規範，開發者經過統一的規範和標準，來配置本身的頁面的雲端緩存策略，來提供更可靠的體驗和功能。

歡迎各位讀者補充各項移動Web加速技術及其最新進展，能夠發送郵件到 openweb@baidu.com，也能夠關注【OpenWeb開發者】公衆號並回復「加羣」，一塊兒來探討相關技術，與咱們攜手推動Web技術的發展！