您需要了解的有关 Google 加速移动页面的所有信息

已发表: 2022-03-10
快速总结 ↬ 2015 年 5 月，Facebook 推出了其新的应用内发布平台 Instant Articles。 一个月后，Apple 宣布旧的 Newsstand 体验（本质上是一个充满新闻应用的精美文件夹）将在 iOS 9 中被一个名为 Apple News 的全新新闻聚合和发现平台所取代。 四个月后，谷歌宣布了自己的计划，虽然有点迟，但雄心勃勃，计划通过一种名为 Accelerated Mobile Pages 或 AMP 的基于 Web 的开源解决方案彻底改变移动新闻消费。 在短短几个月内，我们看到相对平静的移动数字出版爆发了另一场全面的平台战争，Facebook、苹果和现在的谷歌都在争夺出版商的忠诚度和读者的注意力。

2015 年 5 月，Facebook 推出了新的应用内发布平台 Instant Articles。 一个月后，Apple 宣布旧的 Newsstand 体验（本质上是一个充满新闻应用的精美文件夹）将在 iOS 9 中被一个名为 Apple News 的全新新闻聚合和发现平台所取代。

关于 Smashing 的进一步阅读：

  • 感知绩效
  • 预载：它有什么用？
  • 为 HTTP/2 做好准备
  • 渐进增强
  • 渐进式 Web AMP

四个月后，谷歌宣布了自己的计划，虽然有点迟，但雄心勃勃，计划通过一种名为 Accelerated Mobile Pages 或 AMP 的基于 Web 的开源解决方案彻底改变移动新闻消费。 在短短几个月内，我们看到相对平静的移动数字出版爆发了另一场全面的平台战争，Facebook、苹果和现在的谷歌都在争夺出版商的忠诚度和读者的注意力。

尽管 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 团队将通用组件优先于特定服务功能（例如，专门为您的社交初创公司提供的小部件），但它也致力于提供足够的多样性以容纳尽可能广泛的内容。
  • 最后，所有这些政策都可能发生变化。 随着网络工作者、自定义元素和影子 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 采用者会很乐意接受这一提议。 （有关如何选择加入 Google 缓存的文档即将发布，但鉴于 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