本文作者：劉鵬
原創宣告：本文為閱文前端團隊 YFE 成員出品，請尊重原創，轉載請聯絡公眾號 ( id: yuewen_YFE ) 獲取授權，並註明作者、出處和連結。
之前我們的文章（文章連結）也有介紹過，Webnovel （起點海外）在去年年初就將首頁以及全部閱讀頁都接入了 Google 的 AMP 技術，並且從體驗和資料上來說都取得了不錯的效果。在去年年底我們又進行了一次迭代，把更多的閱讀頁內容也加入到了 AMP 當中。使用者可以在 Google Search 當中搜尋到我們的小說內容，並且很快就可以進行閱讀。但是同時我們也發現了一些問題，使用者在搜尋結果的第一個落地頁顯示的內容是我們的，但是 URL 卻是 Google 的 URL。雖然 Google 在頂部加了一個 m.webnovel.com 來源的標識，但是很多使用者依然會誤解，並且給我們的統一品牌宣傳帶來了影響。
顯然 Google AMP 團隊也注意到了這一點，在去年年底的時候推出了 AMP WebPackage 技術來解決這個問題。
WebPackage 背景
講到 Package，大家可能想到的都是 Webpack，Rollup，Parcel 這些打包工具。而我們這次講的是 Web Package。Web Package 解決了什麼問題呢？它可以讓你把你的檔案打包給第三方，但是瀏覽器訪問的時候卻可以識別出來你真實的域名。我想很多同學第一反應就是想到 CDN，因為現在 CDN 都是託管在第三方的雲廠商，為了在雲廠商配置我們自己的域名，我們必須把自己的證照私鑰配置在雲廠商的後臺管理頁面上，這樣可以實現使用者訪問的是雲廠商的 CDN 伺服器但是顯示的卻是我們自己的域名。這種操作帶來兩個問題，一個是存在著被第三方雲廠商洩漏我們證照私鑰的風險，另一個是證照過期的時候要記得去第三方平臺更新。而 Web Package 就是用來解決這些問題的。
Web Package 的這個特性也正好可以用來解決我們上面發現的問題。
之前的 Google AMP 技術可以讓使用者在 Google Search 搜尋結果頁面當中非常迅速地進入到搜尋結果頁面。為了保證載入速度儘可能地快，Google Search 其實是將符合 AMP 標準的頁面快取進 Google 的 CDN 當中，當命中搜尋結果的時候，再從 Google CDN 中載入進來，從而保證了非常快的載入速度。這其實跟我們平常使用 CDN 加速是一樣的。必然會帶來一個問題，就是展示出來的頁面 URL 是 Google 的地址，而非我們自己的域名地址。就如圖 1 所示。
為了解決上面的問題，讓使用者有更好的體驗，Google AMP 團隊在去年將 Web Package 引入到了 AMP 技術當中。我們也有幸成為了首批接入這個技術的國內釋出商。在昨天剛剛結束的 Google AMP 2019 會議上，也得到了 Google 官方的認可。
實現 Web Package 中的 Signed-HTTP-Exchanges
在接入 AMP Web Package 過程中，最重要的一步是將我們的內容返回給 Google 爬蟲，而這些內容是需要使用我們的證照進行加密的，這個技術稱為 Signed-HTTP-Exchanges (縮寫為 SXG)。下面我們將詳細介紹如何實現 SXG 並最終在從 Google Search 結果無縫瀏覽我們的站點。
整個操作不算複雜，一共分為以下三步：
1. 從你的 CA 廠商那獲取一個支援 SXG 的證照
這是最重要的一步。如上所述，返回給 Google 爬蟲的內容需要使用證照進行非對稱加密。而這個證照是必須擁有一個 SXG 的擴充套件。截止此文章釋出日期，只有 Digicert 證照頒發商是支援頒佈此型別證照的。並且此證照必須使用 EC 金鑰（非 RSA 金鑰）以及 prime256v1 演算法生成。
需要注意的是，這個證照僅用來給返回谷歌爬蟲的 AMP 文件進行加密。之前接入層是什麼證照依舊使用什麼證照，是沒有影響的（需要注意生成新證照不能導致現在在用的舊證照被頒發商吊銷）。
2. 在伺服器上按照 amppackage 官方步驟部署 amppkg
部署 amppkg 沒有什麼值得說明的，唯一需要注意的是 amppkg 的配置檔案。要捕獲請求引數的時候需要加上 QueryRE = “.*”，其他也沒有要特別注意的。
amppkg.toml
----------
Port = 'port listening'
CertFile = 'path/to/fullchain.pem' # SXG cert from your CA
KeyFile = 'path/to/privkey.pem' # SXG cert key
OCSPCache = '/tmp/amppkg-ocsp'
[[URLSet]]
[URLSet.Sign]
Domain = "amppackageexample.com"
QueryRE = ".*" # to capture query string
複製程式碼3. 配置 AMP SXG 回源
下面是簡單的 AMP SXG 回源的架構圖。
然後就是配置回源接入層了，為了更詳細描述這個問題，我們畫一個 Webnovel AMP 的回源流程圖。
現在 Google 爬蟲抓取 SXG 加密的 AMP 文件會有兩次請求操作。第一次是一個正常的爬取操作，如果後臺是支援給 SXG 加密的 AMP 內容檔案的，則可以在返回的 header 頭上加上 Vary: AMP-Cache-Transform,Accept，Google 爬蟲識別到這個 header 頭之後就可以進行第二次爬取操作，並且會在 header 頭上帶上 AMP-Cache-Transform: google 用來跟第一次爬取操作進行區分。我們的接入層反向代理在識別到這個頭部之後，將請求轉發到對應的 amppkg server，amppkg server 將對應的內容返回給爬蟲即可。
雖然我們給 amppkg server 配置了一個證照，但是這個證照僅用來對內容進行加密，連線是不加密的。所以我們的反向代理轉發到 amppkg server 依然用 http 而非 https。
upstream amppkg { proxy_pass http://IP:PORT; }
upstream webnovelBackend { proxy_pass http://IP:PORT; }
location ^~ /amp/ {
if ($http_amp_cache_transform = "google") {
rewrite ^/(.*)$ /ampSXG/$1 last;
break;
}
# allow google to fetch SXG (Signed Exchange AMP HTML)
add_header Vary "AMP-Cache-Transform, Accept";
proxy_pass http://webnovelBackend;
}
location ^~ /ampSXG/ {
# some detail omitted
proxy_pass http://amppkg/priv/doc/https://m.webnovel.com/;
}
# this location is for browser to get cert for verifying SXG document
location ^~ /amppkg/ {
proxy_pass http://amppkg/amppkg/;
}
複製程式碼到了這裡就完成了整個後臺的配置，可以用官方提供的方法來進行驗證。要想正式環境（Chrome 73 以及以上才支援 SXG 功能）驗證就需要等待一段時間，讓 Google 爬蟲來爬取這些 SXG 加密的 AMP 文件內容了。
結果展示
下面是 Webnovel 在實現 SXG 之後的一個演示視訊。
接入了 AMP Packager 之後的 AMP 和之前有什麼區別呢？雖然我們的資料還不夠多，但是我們分析結果看來，最終跳出率，以及每 session 瀏覽的頁面數對比之前都得到了比較好的優化。待 Chrome 73+版本得到更多普及之後資料會更加明顯，後續再跟大家進行分享。
Tips: 有一個小技巧，正常情況下從 Google Search 引流過來的使用者只能享受第一個落地頁面的 Google Cache 加速。後續就是我們自己網站的內容了，需要我們自己進行接入優化。但是很多時候在全球化的接入能力上，我們相對 Google 來說還是偏弱的。有沒有什麼辦法讓使用者儘可能地都瀏覽 Google Cache 快取裡面的頁面呢？在使用者需要進行一些進一步操作的時候，我們再切到我們自己的頁面。我們研究了一下發現還是可行的。我們的 AMP 頁面對應 Google Cache 中的地址是有一個對映關係，比如說我們的 Webnovel AMP SXG 首頁對應 Google Cache 快取的地址就是 m-webnovel-com.ampproject.org/wp/s/m.webn… ，我們在頁面當中跳轉的 AMP SXG 頁面都換成對應的 Google Cache 地址就滿足了我們的需求，即有效利用了 Google Cache 又讓使用者像在我們自己站點上操作一樣。 視訊如下：
引用文章：
- medium.com/@lewpengfei…
- github.com/ampproject/…
- www.digicert.com/account/iet…
- github.com/WICG/webpac…