您需要了解的有關 Google 加速移動頁面的所有信息

已發表: 2022-03-10
快速總結 ↬ 2015 年 5 月，Facebook 推出了其新的應用內發布平台 Instant Articles。 一個月後，Apple 宣布舊的 Newsstand 體驗（本質上是一個充滿新聞應用的精美文件夾）將在 iOS 9 中被一個名為 Apple News 的全新新聞聚合和發現平台所取代。 四個月後，谷歌宣布了自己的計劃，雖然有點遲，但雄心勃勃，計劃通過一種名為 Accelerated Mobile Pages 或 AMP 的基於 Web 的開源解決方案徹底改變移動新聞消費。 在短短幾個月內，我們看到相對平靜的移動數字出版爆發了另一場全面的平台戰爭，因為 Facebook、Apple 和現在的谷歌都在爭奪出版商的忠誠度和讀者的注意力。

2015 年 5 月，Facebook 推出了新的應用內發布平台 Instant Articles。 一個月後，Apple 宣布舊的 Newsstand 體驗（本質上是一個充滿新聞應用的精美文件夾）將在 iOS 9 中被一個名為 Apple News 的全新新聞聚合和發現平台所取代。

關於 Smashing 的進一步閱讀：

  • 感知績效
  • 預載：它有什麼用？
  • 為 HTTP/2 做好準備
  • 漸進增強
  • 漸進式 Web AMP

四個月後，谷歌宣布了自己的計劃，雖然有點遲，但雄心勃勃，計劃通過一種名為 Accelerated Mobile Pages 或 AMP 的基於 Web 的開源解決方案徹底改變移動新聞消費。 在短短幾個月內，我們看到相對平靜的移動數字出版爆發了另一場全面的平台戰爭，因為 Facebook、Apple 和現在的谷歌都在爭奪出版商的忠誠度和讀者的注意力。

儘管 Facebook 和 Apple 在 Google 上取得了顯著的領先優勢，但我們完全有理由相信 AMP 將迅速趕上（甚至可能超過其一個或兩個競爭對手）。 如果您是開發人員或出版商，需要盡可能快速高效地了解 Google Accelerated Mobile Pages 的原因、內容和方式，那麼您來對地方了。

跳躍後更多！ 繼續往下看↓

但問題是什麼？

在我們討論解決方案之前，有必要花點時間來探索一下這個問題。 如果您在移動設備上進行大量閱讀，那麼您很有可能已經非常清楚在手機或平板電腦上與基於 Web 的內容進行交互的範圍從幾乎無法接受到可怕。 頁面通常加載緩慢、呈現不穩定且行為不可預測，主要原因有兩個：

  • 第三方乾擾。 廣告和相關的跟踪技術不僅會向已經受到帶寬和 CPU 限制的設備添加大量和額外的請求，而且頁面在圍繞多個document.write()調用時經常表現得好像被附身了一樣。 《紐約時報》最近進行了一項測試，顯示安裝 iOS 內容攔截器後頁面大小顯著減小，電池壽命延長。
  • 響應式設計帶來的附帶損害。 雖然大多數響應式設計的網站在各種尺寸的屏幕上看起來都很好，但在移動設備上查看時，它們通常包含許多桌面網站的包袱。 當 Paul Irish 對 Reddit 進行性能審計時，他發現大量開銷可以追溯到一個名為 SnooIcon 的資產，這是一個用 SVG 渲染的 Reddit 吉祥物，以便它可以動畫（通過第三方庫，這意味著更多開銷）鼠標懸停 - 不是資產經常發現自己在移動設備上的情況。

進入 Facebook Instant Articles、Apple News 和 Accelerated Mobile Pages——我們的救星來自一個世界，根據 Facebook (PDF, 3.4 MB)，一篇文章在移動設備上的平均加載時間為 8 秒。 雖然將 8 秒稱為永恆顯然是誇張的，但考慮到您可以在這段時間內很好地進入您的第二個 Vine 視頻，可以公平地說，按照今天的標準，它至少是一個永恆。

Facebook Instant Articles、Apple News 和 Accelerated Mobile Pages 的簡短演示。 請注意，Facebook Instant Articles 和 Apple News 是應用內體驗，而 AMP 完全基於瀏覽器。

AMP 有何不同？

AMP 與 Facebook Instant Articles 和 Apple News 的不同之處的一些背景信息將使谷歌為其新的數字出版計劃做出的一些決定更加清晰。

Facebook Instant Articles 和 Apple News 有幾個共同點：

  • 應用內體驗。 讀者通過移動設備上的 Facebook 訪問 Facebook Instant Articles，而 Apple News 是 iOS 9 附帶的獨立應用程序。這兩個平台目前都不允許用戶在各自應用程序之外查看特定格式的文章。 將兩者都視為 RSS 的特定於應用程序的刷新。
  • 聯合驅動。 雖然 Facebook Instant Articles 和 Apple News 使用非常不同的聯合格式（Apple News Format 是基於 JSON 的，Instant Article Markup 或多或少是包裝在 RSS 提要中的 HTML），但它們基於相似的原則：誘使您的 CMS 生成必要的聯合格式，Facebook 或 Apple News 將通過定制和優化的渲染器將其吞嚥、解析並使其既美觀又快速。
  • 以體驗為導向。 儘管 Facebook Instant Articles 和 Apple News 都關注性能，但它們同樣關注使文章的外觀和感覺現代。 這兩個平台都具有允許我們通常與定制的、手工構建的閱讀體驗相關聯的流暢交互的組件。

相比之下，Accelerated Mobile Pages 有一個明顯的重點：

  • 基於網絡的體驗。 AMP 文檔旨在在瀏覽器或 WebView 中呈現。
  • 原子文件。 儘管 AMP 文檔由 AMP 運行時驗證、解析和部分呈現（下文有更多內容），但它們是完整且獨立的文檔，它們存在於您自己的 Web 服務器上（並且，可選地，在 CDN 緩存中），而不是元數據將在某個時候轉換為文章並在應用程序中呈現。
  • 以績效為導向。 AMP 更關心 AMP 文檔的性能，而不是美學或交互模式。 這並不是說 AMP 文檔本質上是家常便飯（它們可以像 Facebook Instant Articles 或 Apple News 文章一樣具有正確的樣式），但運行時更關心的是使文章快速呈現，而不是提供花哨的視覺效果，例如瘋狂的小東西。

AMP到底是什麼？

足夠的哲理和高水平的揮手。 讓我們進入細節。 雖然了解 Facebook Instant Articles 和 Apple News 非常容易（它們本質上是花哨的新聞聚合器，具有基於專有聯合格式構建的自定義渲染器），但 AMP 是異常值。 它有點難以掌握，原因有兩個：

  • 沒有一個簡單的模型可以與之比較。 當 RSS 是新的時候，我們都驚嘆於它的力量，寫了無數關於它的破壞性潛力的文章和博客文章，宣布主頁死了（又一次），然後開始忘記它。 Facebook Instant Articles 和 Apple News 本質上是 RSS 的重新啟動，只是它們免除了標準的所有不便，並且每個都恰好只能在一個應用程序中工作。
  • AMP 不是客戶端。 . 雖然 Facebook Instant Articles、Apple News 和 AMP 有幾個共同點，例如專有聯合格式和自定義渲染器，但 AMP 是唯一沒有專用客戶端（瀏覽器除外）的元素。 與其同類產品相比，AMP 更重要的是一組規範、約定和技術，它們可以組合成一個解決方案，而不是本身就是一個端到端（出版商到讀者）的解決方案。

既然我們知道將 AMP 視為成分的集合，而不是完全烤好的蛋糕，那麼讓我們看看這些單獨的成分是什麼：

  • AMP HTML,
  • AMP 運行時，
  • AMP 緩存。

AMP HTML

AMP 文檔是用 HTML 編寫的，而不僅僅是任何 HTML。 一些標籤被禁止，同時引入了一些新標籤（部分是為了替換被禁止的標籤，部分是為了封裝交互功能）。 您可以將 AMP HTML 視為 HTML 在設計時只考慮移動性能的樣子（而不是在 iPhone 推出前整整 14 年才推出）。

因為 AMP HTML 旨在實現最佳性能，要理解和欣賞它的價值，我們需要了解它解決的問題。 以下是影響移動設備上網頁加載和呈現的三個最大因素：

  • 有效載荷大小。 響應式網頁設計為我們提供了很好的服務，因為它允許我們為每個設備和屏幕構建一個網站。 但這有時也意味著將桌面大小的有效負載（HTML、JavaScript、CSS 和資產）交付給帶寬和 CPU 受限的移動設備。 （那些將手機視為小型台式電腦的人過於看重移動硬件。您的 iPhone 6s 有 2 GB 的 RAM，而您的筆記本電腦可能有 8 或 16 個。）
  • 資源加載。 資源並不總是以最佳順序加載，這意味著帶寬、CPU 和 RAM 通常專用於用戶可能永遠看不到的資產。 此外，資源經常不聲明它們的寬度和高度（特別是通過廣告網絡提供或通過document.write()調用注入時），這不僅會導致頁面在延遲確定資源尺寸時自行調整大小，而且還會觸發不必要的和昂貴的佈局重新計算。 這就是導致網頁像激光追逐小貓一樣跳躍的原因，因為它們表現得如此緩慢。
  • JavaScript 執行。 我不打算在這裡提出 JavaScript 性能的話題，但是現代網站經常以兆字節為單位堆積它，雖然它可能在台式計算機上執行而沒有任何明顯的延遲，但移動仍然是一個非常不同的環境，我認為我們都同意，JavaScript 最好保持在最低限度。

鑑於移動設備上流暢的網絡體驗存在這三個障礙，AMP HTML 主要存在於三個目的：

  • 鼓勵簡潔。 AMP 文檔不是桌面網站的響應版本。 雖然 AMP 文檔可以（並且通常是）響應式的，但它們在移動環境中是響應式的。 換句話說，AMP 文檔不是絕對可以在任何地方（桌面和移動設備）工作的一頁，而是專門為在移動設備上正常工作而設計的。
  • 控制外部資源加載。 AMP 運行時控制外部資源的加載，以確保流程高效，從而使內容盡可能快速、智能地出現在用戶的屏幕上。
  • 封裝交互功能。 儘管 AMP 文檔傾向於直接為讀者提供直接的閱讀體驗，但這並不意味著它們不能是現代的和交互式的。 AMP 運行時通過高度優化的 JavaScript 提供封裝的功能，因此開發人員不會冒著編寫自己的代碼而影響性能的風險。

AMP HTML 標籤

以下是 AMP HTML 中完全禁止的標籤列表：

  • script這顯然是一個很大的腳本。 我將在下面提供有關 AMP 在 JavaScript 上的立場的更多詳細信息； 現在，假設您的 AMP 文檔中僅有的script標籤是那些加載 AMP 運行時的腳本標籤，以及（可選）基於 JSON 的鏈接數據的標籤。
  • base出於謹慎考慮， base標籤似乎被禁止，如果社區抱怨，它最終可能會被列入白名單。 （我的猜測是沒有人真正關心一種或另一種方式。）
  • frame和frameset反正不是很好地利用移動房地產，所以很好擺脫。
  • object , param , applet和embed遺憾的是，您的 AMP 文檔不會包含任何 Flash 或 Java 小程序。 （那是諷刺，以防它不完全明顯。）
  • form和input元素（ button標籤除外） 表單支持最終可能會被實現為封裝組件，因為它們在沒有腳本的情況下用途有限。

現在，為了優化資源加載和實施最佳安全實踐，這裡列出了替換其 HTML 對應標籤的標籤：

  • [amp-img](https://www.ampproject.org/docs/reference/amp-img.html)通過考慮視口位置、系統資源和連接性等因素，替換img標籤並優化資源加載。
  • [amp-video](https://www.ampproject.org/docs/reference/amp-video.html)替換 HTML5 video標籤，以便延遲加載視頻內容（考慮視口）。
  • [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html)替換 HTML5 audio標籤，以便可以延遲加載音頻內容（考慮到視口）。
  • [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) amp-iframe標記通過執行諸如默認沙盒內容和限制iframe 似乎可以確保它們不會支配 AMP 文檔。

最後，以下是 AMP HTML 引入的所有標籤，用於向您的文檔添加功能或交互性，而無需您編寫 JavaScript：

  • [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) amp-ad標籤允許 AMP 運行時管理廣告的加載，就像所有其他外部加載的資源一樣（目前, 廣告最後加載），並確保來自廣告網絡的 JavaScript 無法在父 AMP 文檔中執行或觸發不必要的佈局計算。 （再見， document.write() ！）
  • [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html)這個微型框架打包分析數據並將其發送給第三方提供商。 截至今天，AMP 支持來自 Adob​​e Analytics、Chartbeat、ClickTale、comScore、Google Analytics、Nielsen 和 Parse.ly。
  • [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html)這用於嵌入網絡信標，它支持將多個客戶端變量發送到服務器的令牌。
  • [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html)這個優化的組件以交互式水平方向顯示子圖像。
  • [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html)這允許讀者在全屏“燈箱”視圖中打開圖像。 它支持縮略圖和全尺寸圖像的規範。
  • [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html)這會加載動畫 GIF 並提供急需的佔位符功能。
  • [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html)設置自定義字體的加載超時，並在您的自定義字體未在分配的時間內加載時指定備用字體.
  • [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) amp-fit-text標記中的文本將自動分配一個優化的字體大小可用空間。 將其視為一種預先包裝好的響應能力。
  • [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html)使用amp-list標籤，您可以加載動態的、重複的 JSON 數據，然後使用 HTML 呈現它模板。 （請參閱下面的amp-mustache標籤。）
  • [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html)這支持渲染 Mustache HTML 模板。
  • [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html)如果您選擇不使用 AMP 緩存（下文將詳細介紹緩存），則amp-install-serviceworker標記為當前頁面加載並安裝服務工作者。 服務人員很狡猾，但在我看來，現在依賴他們還為時過早。
  • [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html)可以預見的是，這會嵌入具有指定視頻 ID 的 YouTube 視頻。
  • [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html)嵌入推文（推特卡可選）。
  • [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html)嵌入 Instagram 圖片。
  • [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html)此組件從 Brightcove 加載並顯示視頻（和視頻播放器）。
  • [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html)在您的 AMP 文檔中嵌入 Pinterest 小部件或“Pin It”按鈕。
  • [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html)在您的 AMP 文檔中嵌入指定的 Vine 視頻。

請注意，雖然amp-前綴標籤並不完全是標準 HTML，但它們也不是專有的。 相反，它們是具有 JavaScript 實現的合法自定義元素，可以執行諸如強制最佳安全實踐和優先加載遠程資源的操作（更多信息請參見下面的“AMP 運行時”部分）。 換句話說，雖然 AMP HTML 可能看起來有點像擁抱、擴展和消除策略，但它實際上只是對 Web 標準的巧妙應用，與自定義data-屬性並沒有太大區別。

樣式化 AMP HTML

AMP 文檔的樣式是使用標準 CSS 完成的，與您已經為內容設置樣式的方式沒有太大區別。 但是，請記住幾件事：

  • 所有樣式都必須使用內聯樣式表完成——沒有外部鏈接的樣式表，也沒有元素級的內聯樣式。 （外部鏈接的樣式表需要在計算佈局之前下載額外的文檔，並且內聯元素級樣式可能會使文檔膨脹。）
  • 樣式限制為 50 KB。 Google 的理念是 50 KB 足以容納一篇漂亮的文檔或文章，但不足以容納一個漂亮的網站。
  • 您的內聯樣式表必須具有amp-custom屬性（即<style amp-custom> ）。
  • @規則—— @font-face （更多關於下面的字體）、@keyframes 和@media @keyframes是允許的。
  • 一些選擇器具有已知會挑戰性能的限制，例如通用 ( * ) 選擇器和:not()選擇器。
  • !important限定符被禁止，以確保 AMP 運行時對元素大小有最終決定權。
  • 自定義 AMP 組件（如amp-carousel ）的樣式是通過覆蓋默認類（如.amp-carousel-button-prev ）或使用一組預定義的 CSS 自定義屬性（如--arrow-color ）來完成的。
  • 所有外部加載的資源都必須指定寬度、高度和佈局屬性（更多關於下面的佈局），以盡量減少昂貴的 DOM 佈局重新計算。
  • 可以使用 GPU 加速（並且不會觸發重新計算）的過渡和動畫是允許的。 目前， opacity和transform已列入白名單。

有關樣式化文檔的更多詳細信息，請參閱 AMP HTML 規範。

A New York Times article formatted as an AMP document
格式為 AMP 文檔的《紐約時報》文章。 （查看大圖）

字體

AMP 很高興地支持自定義字體，但有幾個條件：

  • 字體必須使用鏈接標籤或 CSS @font-face規則加載。 換句話說，您不能使用 JavaScript 加載字體。
  • 所有字體都必須通過 HTTPS 提供。
  • 字體提供者必須被列入白名單。 目前，唯一列入白名單的提供商是fonts.googleapis.com和fast.fonts.net 。 但是，考慮到出版商、廣告商和分析提供商增加對 AMP 支持的速度有多快，我懷疑很快就會有更多支持。

佈局

AMP 的佈局方法是圍繞兩個主要目標構思的：

  • 運行時必須能夠在所有外部加載的資源實際加載之前推斷出它們的大小，以便可以盡快計算出最終佈局。 一旦佈局計算好，文章就可以被渲染並且讀者可以開始與之交互，即使廣告、圖像、音頻和視頻還沒有完成加載。 （並且，隨著這些資源的加載，它們將無縫呈現，而不會通過更新文檔的佈局來破壞閱讀體驗。）
  • AMP 文章應該是響應式的。 正如名稱“Accelerated Mobile Pages”所暗示的那樣，AMP 文檔專門用於移動設備； 因此，在這種情況下，“響應式”不包括桌面分辨率。 相反，AMP 文檔應該在所有移動設備上看起來都不錯，從人們仍在使用的那些微小的舊 iPhone 4 遺物一直到相對龐大的 iPad Pro。

前一個目標主要是通過要求所有外部加載的資源都具有width和height屬性來實現的（並且通過限制腳本進一步強制執行，以確保新資源不會被硬塞進去）。 後者是通過標準媒體查詢、 media屬性、 sizes屬性和特定於 AMP 的layout屬性來實現的。

以下是 AMP 當前支持的佈局的概述：

  • nodisplay該元素最初不顯示，但顯示可以由用戶操作觸發。 （這與amp-lightbox等組件結合使用。）
  • fixed元素具有固定的寬度和高度，這意味著運行時不能應用任何響應式行為。
  • responsive式 在我看來，這是 AMP 佈局選項中最有用和最神奇的。 該元素使用分配的任何空間，同時保持其縱橫比。 （基本上，“請讓這個東西在任何分辨率下看起來都很好，謝謝。”）
  • fixed-height元素使用分配的空間，但保持固定高度（水平縮放）。
  • fill元素填充它所在的容器，而不考慮縱橫比。 （想想width: 100%和height: 100% 。）
  • container元素是一個容器，因此，它允許它的子元素（而不是它的父元素）定義它的大小，就像一個標準的div元素一樣。

使用 AMP 的佈局系統實現功能性和簡單的文檔佈局相對容易，但是當您考慮它支持的所有內容以及值如何應用於不同類型的元素時，就會發現相當多的細微差別。 有關更詳細的細分，請參閱 AMP 佈局規範。

SVG怎麼樣？

支持的！ Basic SVG 在桌面和移動瀏覽器中都享有全面的支持，而且圖形的響應速度並不比矢量快，因此 AMP 和 SVG 組成了一個非常好的團隊。 最大的限制是，由於腳本限制，您將無法使用 JavaScript 為矢量製作動畫——老實說，您可能不應該在移動設備上這樣做。 然而，如果你真的必須為你的 SVG 注入一點活力，你仍然可以使用 CSS 動畫來做到這一點，根據上面樣式部分中概述的相同限制。 請記住，SVG 是 DOM 的一部分，因此它可以像任何其他元素一樣輕鬆地設置樣式和動畫。

AMP 的 JavaScript 哲學

好消息和壞消息都在這裡。 壞消息是您不會很快為您的 AMP 文檔編寫任何 JavaScript。 但在某種程度上，這也是好消息。 請記住，AMP 不是移動應用程序框架。 相反，它是一個移動文章框架，並且因為文章應該針對無縫和流暢的閱讀體驗進行優化，所以對於繁重的客戶端腳本來說，確實沒有很多好的用例。

話雖如此，永遠禁止所有 JavaScript 既不現實又有點嚴厲。 現實情況是，網絡依賴 JavaScript 已經有一段時間了——即使是在簡單且相對平淡的閱讀體驗的背景下——用於廣告、分析和交互功能之類的事情。 此外，Web 最好的地方之一是它的開放性和看似無限的實驗、表達和創造力的能力——其中很大一部分是由 JavaScript 提供支持的。

AMP 團隊認識到任意用戶編寫的 JavaScript 對性能保證的負擔，以及 JavaScript 在現代 Web 環境中的普遍性和必然性，提出了以下腳本原則：

  • 目前不支持或不允許用戶編寫的 JavaScript。 您的 AMP 文檔中可能只有兩種類型的腳本標籤：鏈接數據標籤（其類型為application/ld+json ）和同時包含 AMP 運行時和擴展 AMP 組件的標籤。
  • AMP 項目的作者已經預見到在移動文章消費的上下文中對 JavaScript 的大部分需求，因此 AMP 要么支持替代方案（ amp-pixel ，包括帶有鏈接標籤的自定義字體或@font-face規則等），要么提供與 AMP 運行時兼容的實現，因此可以保證安全性和性能（ amp-ad 、 amp-analytics 、 amp-carousel等）。
  • 如果您確實必須將 JavaScript 用於交互功能，您可以獨立構建該功能，然後將其包含在[amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html)標籤。 amp-iframe中包含的內容甚至允許與父文檔進行有限的通信，例如調整大小請求。
  • AMP 組件是開源的（Apache 2）並且對貢獻開放，所以隨著時間的推移會出現新的組件（事實上，在撰寫和編輯本文的過程中出現了幾個新組件，所以我已經更新了幾次）。 雖然 AMP 團隊會優先考慮通用組件而不是服務特定功能（例如，專門為您的社交初創公司提供的小部件），但它也致力於提供足夠的多樣性以容納盡可能廣泛的內容。
  • 最後，所有這些政策都可能發生變化。 隨著 Web Worker、自定義元素和影子 DOM 等瀏覽器功能得到更廣泛的支持，支持用戶編寫的 JavaScript 和自定義組件的選項——同時仍保證安全性和性能——將大幅擴展。

有關 AMP 組件未來的更多信息，請參閱“AMP HTML 組件”規範的“擴展組件”部分。

AMP 文檔剖析

現在您已經對 AMP HTML 有了相當深入的了解，讓我們分解一個樣板。

當然，您將使用doctype聲明開始您的 AMP 文檔：

 <!doctype html>

接下來，將您的 HTML 文檔指定為 AMP HTML，不管您信不信，您可以使用高壓表情符號作為html標記中的屬性：

 <html >

或者，如果你是一個老式的脾氣暴躁的人，並且對用可愛的表情符號裝飾你的代碼的想法感到憤怒，你可以使用更保守的amp屬性，而不是：

 <html amp> <!-- A good sign that you're boring! -->

在您的head標籤中，不要忘記utf-8字符編碼說明：

 <meta charset="utf-8">

並鏈接到您的文檔的非 AMP 版本（標記為canonical ，以便它不會顯示為重複內容）：

 <link rel="canonical" href="my-non-amp-index.html">

相反，您的非 AMP 版本應包含對 AMPlified 文檔的引用：

 <link rel="amphtml" href="my-amp-index.html">

由於 AMP 頁面適用於移動設備（並且您還需要 GPU 光柵化），因此請務必包含元viewport標籤：

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

下一行代碼看起來有點奇怪，因為它是。 您知道您有時會如何看到網頁在加載​​和應用字體之前會短暫呈現文本，然後閃爍並再次呈現設計者預期的方式？ 下面的標籤將頁面的不透明度保持在0 （不可見），直到它被正確地設置樣式。

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

這種方法的問題在於，如果 AMP 運行時無法加載，從技術上講，頁面的不透明度可能永遠不會從0變為1 。 為了彌補這種意外情況，上面的代碼可能會更改為更接近此的代碼：

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

接下來要做的是包含 AMP JavaScript 運行時：

 <script async src="https://cdn.ampproject.org/v0.js"></script>

並包括您需要的任何擴展組件的 JavaScript 實現：

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

（注意async屬性的使用。這不是可選的——阻塞越少越好。）

或者，您可以添加一些鏈接數據，如下所示：

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

現在讓我們在 CSS 中使用link標籤或@font-face規則添加一些字體：

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

然後我們將添加一些樣式（價值不超過 50 KB），並帶有所需的amp-custom屬性：

 <style amp-custom>

您現在已經準備好使用您剛剛了解的有關 AMP HTML 的所有內容構建或多或少標準的 HTML 文檔。

AMP 運行時

我不會在 AMP 運行時上花費太多時間，因為與所有運行時一樣，它有點像一個黑匣子。 這並不是說 AMP 運行時不可訪問（它是開源的，就像項目的其餘部分一樣）。 相反，就像所有好的運行時一樣，開發人員不需要確切地知道它是如何工作的以利用它，只要他們通常了解它的作用。

AMP 運行時完全在 JavaScript 中實現，並通過將其包含在 AMP 文檔中來啟動，就像任何外部 JavaScript 文件一樣：

 <script async src="https://cdn.ampproject.org/v0.js"></script>

從那裡開始，AMP 運行時主要做三件事：

  • 管理資源加載和優先級，
  • 實現 AMP 組件，
  • 可選地，包括 AMP HTML 的運行時驗證器。

驗證器對於創作符合 AMP 標準的文檔至關重要。 只需將#development=1附加到文檔的URL 即可打開它。 然後，您所要做的就是打開控制台查看您的成績單。

錯誤如下所示：

AMP validation errors in the console
控制台中的 AMP 驗證錯誤。 （查看大圖）

一個漂亮、乾淨、合規的 AMP 文檔如下所示：

An AMP document that passes validation
通過驗證的 AMP 文檔。 （查看大圖）

（可選）AMP 緩存

AMP 文檔可以像任何其他 HTML 文檔一樣從網絡服務器提供，但也可以從特殊的 AMP 緩存提供。 可選緩存使用多種技術進一步優化 AMP 文檔：

  • 圖像參考可以替換為特定於查看者視口大小的圖像。
  • 首屏圖片可以內聯以保存額外的 HTTP 請求。
  • 可以內聯 CSS 變量以減少客戶端開銷。
  • 可以預加載擴展的 AMP 組件實現。
  • 可以縮小 HTML 和 CSS 以減少通過線路（或者，在本例中是電波）發送的字節數。

任何人都可以在自己的 CDN 上運行自己的 AMP 緩存，或者發布商可以免費使用 Google 的緩存。 鑑於 Google 似乎對可擴展性了解一兩件事，我猜大多數 AMP 採用者會很樂意接受這一提議。 （有關如何選擇加入 G​​oogle 緩存的文檔即將發布，但鑑於 Google 已經對 Internet 進行索引和緩存，可以肯定的是，它將圍繞您的link標籤，也許還有一個額外的meta標籤。）

讀者如何找到 AMP 內容？

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

AMP demo QR code
AMP demo QR code.

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

  1. Go to g.co/ampdemo in Chrome.
  2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
  3. Go into device mode by clicking on the little phone icon in the top-left corner.
  4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)
An AMP document in Chrome Developer Tools
An AMP document in Chrome's Developer Tools.

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

我很高興你問。 My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

其他資源

  • “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
  • Accelerated Mobile Pages Project, official website
  • Accelerated Mobile Pages, blog
  • AMP HTML, GitHub
  • Docs, Accelerated Mobile Pages Project
  • Nigel Tufnel explaining why his amp goes to 11