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

BrilliantOpenWeb發表於2017-12-12
Web

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

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

一、內容回顧

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

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

二、相關技術介紹：雲端頁面快取策略漫談

近幾年，無論是內容分發平臺還是瀏覽器廠商都會通過雲端的頁面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'>

三、主要技術進展

本月報將收錄移動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: 1、 amp-story 預設靜音，新增漸變效果，修復部分相容性問題，提升元件使用體驗 2、 AdSense / Doubleclick 快速取回 unlayoutCallback 實驗 3、AMP 元素增加API，實現元素的排程時間傳遞給元素本身 4、 amp-analytics 增加新的分析服務商：Alexa Internet，增加引數this.isInabox_，支援基本批處理功能

四、總結

百度在W3C 2017 TPAC會議上針對頁面雲端快取策略的議題與全球各大網際網路公司有過深入的交流和討論，也收到了大家的積極響應和回覆。

雲端快取策略是一項重大的技術創新，但技術野蠻生長的同時也對開發者造成了巨大的困擾，隨著大家對此項技術的廣泛深入應用，雲端快取策略必然需要統一的標準和規範，開發者通過統一的規範和標準，來配置自己的頁面的雲端快取策略，來提供更可靠的體驗和功能。

歡迎各位讀者補充各項移動Web加速技術及其最新進展，可以傳送郵件到 openweb@baidu.com，也可以關注【OpenWeb開發者】公眾號並回復“加群”，一起來探討相關技術，與我們攜手推進Web技術的發展！

相關文章