AMP項目實戰分享

04-28

AMP是什麼

Google 前沿的 AMP 「 Accelerated Mobile Pages 」技術，能使用戶從搜索引擎當中進入我們頁面的體驗得到一個極大的提升。確切地說，AMP並不是一門新的技術，它只是一種能讓頁面打開得更快的解決方案。你只要會HTML、CSS、略懂JS，就可以開發你自己的AMP頁面。

有關AMP更多內容可以參看官網。

我們為什麼選擇AMP

看看AMP能給我們帶來什麼：

1. AMP能夠帶來SEO排名優化。

2. AMP Cache能夠讓我們充分藉助Google CDN Cache的優勢。雖然我們內部已經做了很多優化，包括DNS預熱（有關DNS預熱可參見我們組同事寫的一篇文章——網站性能優化——DNS預熱與合併HTTP請求），但如果能有Google全球CDN支持就更是件好事。

3. Google搜索結果對AMP頁面有預載入處理，能讓用戶更快地到達我們的著陸頁。

所以，作為攜程的海外業務部門，我們率先試水了AMP SEO項目。

AMP項目開發

AMP項目開發和普通站點的開發模式幾乎一樣，但是為了最大限度提升性能，AMP項目頁面有不少要求。比如（不限於）：

1. 為了避免 JavaScript 延緩頁面渲染，AMP頁面不能包含自己編寫的JavaScript。

2. CSS都必須內聯，以減少HTTP的請求，並且有50KB的大小限制。

3. AMP 頁面允許第三方 JavaScript，但僅限在沙盒環境下的 iframe 中。

4. 用戶幾乎可以使用所有原生的HTML標籤，但是對img等會產生外部資源依賴的標籤，只能使用amp-img自定義標籤。

基於以上幾點，頁面上所有交互邏輯都必須通過CSS實現，無法依賴JS。對於實現複雜的交互，AMP會顯得力不從心。但是這其實是和AMP原則相一致的，JS豐富了頁面，但JS也是頁面優化噩夢的開始。What Google AMP means for the JavaScript community這篇文章將闡述JavaScript對性能的影響。

當開發完成後，必須保證頁面是符合AMP規範的，只有符合AMP規範的頁面才會被搜索引擎收錄。在Chrome中安裝AMP Validator插件，當你的頁面是完全符合AMP規範的時候，Chrome Validator AMP按鈕會呈現綠色。如下圖：

當頁面通過驗證以後，我們還需要在link中配置amphtml和canonical，讓Google搜索發現我們的頁面。

如果同一個頁面同時具有非AMP版本和AMP版本:

為非AMP頁面添加以下標記：

<link rel="amphtml" href="https://www.example.com/url/to/amp/document.html">

為AMP頁面添加以下標記：

<link rel="canonical" href="https://www.example.com/url/to/full/document.html">

只有一個版本的網頁:

如果只有一個版本的網頁，並且該版本是 AMP 網頁，則仍要為其添加規範鏈接，該鏈接會指向其自身：

<link rel="canonical" href="https://www.example.com/url/to/amp/document.html">

至此，AMP頁面開發工作基本完成，可以發布了。

我們踩過的"坑"兒

AMP有不少限制要求，開發中難免碰到不好解決的問題。以下對我們碰到過的問題及解決方法進行分享。

AMP對表達式複雜度有限制要求，最大值是50。複雜度50是什麼概念呢，比如以下例子，只有純粹的字元串連接，但是以下複雜度已經接近是46，如果再增加一個連接，會達到53的複雜度，控制台會直接報錯：

<a href=<%- searchData.defaultSearchUrl %> [href]="/m/hotels/" + location.concatResult + "/?checkin=" + date.selectedStartDate + "&checkout=" + date.selectedEndDate + "&starID=" + activeStarKeys.keys + "&adult=" + guestsSelectResult.adultsNum + "&children=" + guestsSelectResult.childNum + "&ages=" + guestsSelectResult.childAges>

對於此問題，除非AMP放開複雜度限制，否則我們能做的只能是盡量提前運算，當需要某個計算結果的時候，可以直接使用。比如例子中，location.concatResult就是在location組件內部先進行concat，再將concat的結果拼接到href。此外，可以盡量簡化交互，減少參數。

此問題在AMP開發中勢必會碰到，詳細討論可以看ISSUES-11434。

AMP限制編寫JavaScript，也就不允許我們讀寫Cookie、LocalStorage，但是記錄用戶行為是很重要的事情，比如一些表單信息，用戶的選擇，等用戶下次打開我們的頁面時，能夠顯示用戶上一次的狀態。我們的解決方法是通過http set-cookie方式解決前端無法記錄cookie的問題。
amp-form只能提交ajax post請求，無法做到以post表單形式跳轉。所以在開發過程中盡量避免出現post表單形式的請求，一般改用ajax post加頁面跳轉的形式來提交。在迫不得已的情況下，可以考慮通過增加非amp的中間路由，在中間頁中構造表單並自動提交數據。
AMP CROS：用戶最終訪問的是AMP Cache，在AMP launch新版本之前，命中AMP Cache，頁面地址並非是真實地址而是Google AMP Cache地址，如果頁面上有額外的非同步請求，就會有跨域限制，所以我們要在服務端開啟跨域，返回頭設置AMP-Access-Control-Allow-Source-Origin。
amp-iframe有sandbox屬性，用來指定iframe內部的站點許可權，默認值為空。如果希望iframe內部可以執行js腳本，則需要設置成"allow-scripts"；如果需要添加內部發送同域請求的許可權，則需要設置成"allow-scripts allow-same-origin"；但如果amp-iframe的src是同域站點，那麼sandbox屬性必須不能包含allow-same-origin，這樣做杜絕了脫離amp控制項發送請求的可能性。
AMP下統計頁面埋點必須基於AMP自帶的統計控制項，目前AMP封裝了市面上大部分的第三方統計系統。但是由於公司內部的統計工具沒有AMP對應的控制項，所以無法接入。對於頁面埋點統計，開發者要評估自家的統計工具。

如何優化AMP頁面

最大化提速

通過對非SEO數據非同步化載入，讓AMP更快。

amp-install-serviceworker，讓你打開的不僅僅是一個AMP頁面

AMP頁面作為搜索排名優化頁面的同時，還兼具引流功能。雖然AMP頁面能讓用戶從搜索結果中最快速地到達我們的landing頁，但是只有用戶最終從landing頁又回到原始頁面走完必要的業務流程，才是有效的轉化。例如，在我們的業務中，用戶可以通過搜索引擎快速到達酒店列表、酒店詳情的AMP頁面，但只有從酒店詳情AMP頁面跳轉到支付頁（非AMP），並完成支付，才算轉化成功。如果原始頁面體驗不好，用戶依舊可能中途流失。這似乎不是AMP的"錯"，但AMP確實還能再做些什麼。

通過amp-install-serviceworker安裝原始站點的sw.js，提前載入好原始頁面的資源，當用戶從AMP頁面跳出，進入原始主站的時候，讓主站體驗更好，從而提高實際轉化。

談談AMP的局限性

實踐後，我們發現AMP有以下局限性，希望對於打算了解AMP這一技術，或者有計劃接入AMP技術的團隊，可以起到借鑒作用。

AMP不支持touch事件，影響交互體驗

AMP官方給我們的解釋是：因為不是所有的瀏覽器都支持passive event，為了最大化瀏覽器的支持和效能，所以touch事件只開放給AMP內部組件使用，比如amp-carousel。

AMP沒有開放獲取Cookie的許可權

因為第三方會緩存AMP頁面，出於安全考慮，AMP頁面上不開放Cookie。不過最新消息是，AMP官方回應後續可能會考慮開放Cookie。（來自官網的最新消息：AMP頁面上已經能夠獲取cookie，不過僅限於部分標籤，具體可參見相關文檔：ampproject/amphtml）

只能使用AMP提供的組件

雖然AMP提供了不少組件(並且在持續新增中)，但是開發者無法自己書寫JS去實現交互，不適合開發複雜的交互。

eamp框架，讓開發AMP項目更簡單

eamp是從我們AMP SEO項目中提取出來的簡化版框架，能夠讓我們快速開啟AMP Node項目，使用者無需從0開始搭建，更能專註AMP頁面開發。

特點：

1. 快速搭建基於Node的AMP項目

2. 內置自動化上線打包工具，自動將css打包內聯，符合AMP規範

3. 目錄結構清晰，職責劃分清楚，便於多人開發協作