 |
VOOZH | about |
|
VOOZH | about |
Web 性能優化（Web Performance Optimization，WPO）是一個老生常談的話題，我也寫過很多關於「性能優化」的文章。最近 Google 某個團隊推出了一項名為 Accelerated Mobile Pages（AMP）的技術，號稱能大大加快移動端頁面呈現速度，提高整體體驗。本文就帶大家認識一下這項新技術。
Accelerated Mobile Pages（官網、GitHub），直譯為中文是「加速的移動頁面」的意思。根據官方說明，AMP 在Speed Index（首屏展現時間平均值）測試中，性能有 15% ~ 85% 的提升，測試是在模擬 3G 網絡環境並模擬 Nexus 5 的條件下完成。
AMP 如何讓頁面性能大幅提升暫且擱置一邊，先來看看它是什麼。根據官網文檔得知，AMP 主要由 AMP HTML、AMP Runtime 以及 AMP Components 三部分組成。
<body>、<article>這些標籤可以直接使用，沒有任何限制；有些標籤允許有限制的使用，例如<meta>標籤不能使用屬性；而像<img>、<audio>這樣的標籤需要替換為<amp-img>、<amp-audio>等
AMP Components；更多的標籤如<frame>、<from>不允許使用。
完整說明可以查看官網的AMP HTML 格式文檔。以下是該文檔中的 AMP HTML 示例：
<!doctype
html><html⚡><head<metacharset="utf-8"<titleSample
document</title<linkrel="canonical"href="./regular-html-version.html"<metaname="viewport"content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no,minimal-ui"<styleamp-customh1{color:red}</style<scripttype="application/ld+json"{
"@context":"http://schema.org", "@type":"NewsArticle", "headline":"Article
headline", "image":["thumbnail1.jpg"],
"datePublished":"2015-02-05T08:00:00+08:00"}</script<scriptasynccustom-element="amp-carousel"src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"</script<stylebody{opacity:0}</style<noscript<stylebody{opacity:1}</style</noscript<scriptasyncsrc="https://cdn.ampproject.org/v0.js"</script</head<body<h1Sample
document</h1<pSome
text<amp-imgsrc=sample.jpgwidth=300height=300</amp-img</p<amp-adwidth=300height=250type="a9"data-aax_size="300x250"data-aax_pubname="test123"data-aax_src="302"</amp-ad</body</html可以看出，AMP
HTML 與普通 HTML 並沒有什麼太大區別，上面這段代碼可以直接存為.html文件，並在瀏覽器中正常運行。下面簡單列舉一些格式上的要求：
<!doctype html>；<html ⚡>或<html amp>（讓其他程序能方便地識別出這是 AMP HTML）；<link rel="canonical" href="$SOME_URL" />標籤，用來指定該文檔普通版本的 URL；如果只有一個版本，使用當前 URL 即可（告訴搜尋引擎，這是同一個頁面不同的版本，否則可能會被判作弊）；<meta charset="utf-8">放置在 HEAD 區域最開始的位置（實際上，普通 HTML 也應該這麼做）；<meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no,minimal-ui">；<script async src="https://cdn.ampproject.org/v0.js"></script>作為 HEAD 區域最後的元素；<style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>；在上面的 AMP HTML 代碼中，HEAD 區域最後外鏈引入的 JS 就是 AMP Runtime。AMP Runtime 提供對自定義元素（Custom Elements）的支持，負責協調資源的加載時機和優先級，以及提供驗證器等調試功能。
訪問 AMP HTML 時，在 URL 最後追加#development=1會開啟開發者模式。這時 AMP Runtime 會自動加載驗證器，並在控制台顯示本頁不符合 AMP 規範的位置信息。
<img>和<video>等標籤，用來實現對資源的自定義加載策略；它也用於實現一些複雜的交互效果，如圖片輪播。AMP Components 分為兩類：
1）內置組件，包括：amp-img、amp-audio、amp-anim、amp-ad、amp-pixel、amp-video，在 AMP HTML 引入了 AMP Runtime 之後，這些內置組件就可以直接使用。
2）擴展組件，包括：amp-carousel、amp-lightbox、amp-iframe、amp-instagram、amp-twitter、amp-youtube。要使用擴展組件，需要在 AMP HTML 中引入該組件對應的文件。例如要使用 amp-carousel 就必須引入以下文件（必須要有async和custom-element屬性）：<scriptasynccustom-element="amp-carousel"src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"</script
這裡有一個按照 AMP HTML 規範編寫的頁面，大家可以直接用瀏覽器打開查看：AMP 示例。
經過前面對 AMP 的介紹，你一定會感到奇怪，為什麼 AMP HTML 有那麼多限制和約束，這樣閹割後的 HTML 還有什麼適用場景。實際上，AMP 只關注於一件事 —— 提高靜態頁面的性能。
這個「靜態」並不是指沒有服務端參與的頁面，而是指沒有複雜交互、以內容展現為主的資源頁，典型例子就是新聞詳情頁。現在的網站類型很多，遊戲類、視頻類、電商類等等，每一類網站都有著自己的特點，優化策略也各不相同，用一種方案去解決所有問題不切實際。所以 AMP 項目將關注點放在了更容易優化且效果最明顯的內容型頁面。
Web 優化有很多種方案，每種方案都有自己的適用範圍。有些收益很高的優化手段，存在這樣那樣的限制：例如針對具體業務邏輯所做的優化，很難通用化；部署 Google 的PageSpeed模塊等服務端優化方案，使用成本很高；藉助客戶端所做的優化，如現在廣為流行的移動端 WebView 容器加速方案，優化效果局限在指定 APP 內，甚至還會導致使用通用瀏覽器訪問速度更慢（這個話題很有意思，有機會以後再討論）。
以內容為主的新聞詳情頁，大部分性能消耗在圖片、視頻等媒體資源以及第三方功能如廣告、社會化組件的加載上。將這些內容替換為 AMP Components，避免資源默認被加載，再用 AMP Runtime 統一協調和管理，確實是一個通用化、低使用成本且能讓所有瀏覽器受益的折中方案。而且，AMP 方案不依賴任何特定的服務端或客戶端，可以將頁面直接託管在 CDN，進一步提高用戶訪問速度。
瀏覽器對不同資源加載和預加載有自己的策略，對於預加載，我們有一些控制權，但總的看來這一塊對於開發者來說還是很不可控。例如瀏覽器默認會並行加載多張圖片，但在屏幕小、網速慢、性能差的手機上，串行由上到下加載圖片很可能體驗更好。
行動裝置在網絡、CPU、內存等方面與 PC 差距很大，很多 PC 上可以忽略的問題，在移動端不得不重視起來。例如我們都知道圖片是異步加載的，頁面觸發 DOMContentLoaded 事件並不需要等圖片加載完，但在移動端，大量圖片加載帶來性能開銷卻會大幅延後 DOMContentLoaded 時機。以下是我們在某個移動產品中，將圖片進行延遲加載處理後的 DOMContentLoaded 時間對比統計，可以看到明顯的變化：
responsive布局下，組件會根據初始高寬比例自動調整大小。
另外，一些資源非常消耗性能，例如 gif 和 video，AMP Runtime 可以在它們處於不可見時銷毀元素，釋放資源。總之，使用了 AMP 方案，相當於將頁面資源託管給了 AMP Runtime 管理，一次修改就可以坐享後續所有策略升級帶來的性能提升。
本文到這裡，差不多快要結束了。經過上面的介紹，大家對 AMP 項目應該有了一定的認識。最後談談我的看法：
AMP 項目對書寫代碼設置了大量限制，例如所有資源只能託管給 AMP Runtime 加載；不允許使用 AMP Runtime、AMP Components 之外的 JS；不允許使用 inline JS；只能使用有限的 inline CSS 樣式；JS 和 Web Font 必須使用指定的 CDN 等等，這都是為後面的優化策略做準備。整體原理並不複雜，難點是配套設施的建立，以及如何說服網站主改造代碼。不過，Google 後續很可能對使用了 AMP 的頁面提權，這樣一來大家就有動力了。
符合 AMP 規範的頁面不會比由 WPO 專家優化後的頁面更快，它是一個通用化的技術，肯定包含很多業務用不上的代碼邏輯，也有很多優化手段它無法提供。但對於不知道如何 WPO 的網站來說，使用 AMP 則是一個非常不錯的選擇。
不過，我認為 AMP 很難直接用在國內項目中。首先，前面說過，AMP Runtime、Components 必須從cdn.ampproject.org加載；Web Font 必須從加載。這樣做的出發點是為了更可控，以及更好的在各網站之間共享緩存，但是這些域名在國內很難訪問甚至直接被牆。其次，從目前 AMP
目前已有的擴展組件來看，instagram、twitter、youtube 這類國外媒體常用的服務在國內都無法使用，內置的 ad 組件也不符合國情。
但是，AMP 項目對我們進行移動 Web 優化仍然很有借鑑意義。實際上，控制資源加載、處理響應式元素避免頁面抖動、主動釋放資源等策略，我們在項目中都有自己的嘗試與經驗，但我們的方案要麼過分依賴服務端，要麼沒有抽象成通用模式，導致無法推廣到更多產品，這些都是後續可以努力的方向，而 AMP 規範和代碼實現，將會是最好的參考資料。
----於2015-10-10 01:47:24發表於「前端技術」分類下。