我们刚刚在 ampproject.org 上发布了一份新指南：“优化托管的 AMP 页面”，解释了如何优化 AMP 文档以使其加载速度更快。
您可能在想：等等 - AMP 不应该开箱即用就很快吗？您是对的：AMP 运行时针对速度进行了优化，所有有效的 AMP 页面都加载速度很快。但是，您可以实施一些额外的性能优化，以帮助浏览器更快地加载 AMP 页面。这些更改微不足道，但可以在不破坏 AMP 有效性的情况下显着提高加载性能。
例如，AMP WordPress 插件，由 XWP 开发，已经实施了指南中描述的一些技术。这导致xwp.co的加载时间提高了12.6%。
另一个例子是晚间标准报，他们更进一步，使用服务器端渲染 (SSR) 发布优化的 AMP。这导致他们的 FCP 比非优化 AMP 版本提高了69%。
为什么您应该关心？
让我们退一步。这真的有必要吗？AMP 文档不是总是由自动执行所有这些优化的 AMP 缓存提供服务的吗？对于某些情况，例如 AMP 文档在 Google 或 Bing 搜索结果中显示时，情况确实如此。但是，在其他情况下，AMP 文档是从源提供服务的：
- 当您的规范页面或移动网页使用 AMP 构建时，例如https://tasty.co。
- 其他平台链接到源上的 AMP 文档。例如，Twitter开始链接到 AMP 页面，而不是提供标准的移动版本。这意味着，如果用户点击 Twitter 移动应用程序中的链接，则该链接将指向您自己服务器上的 AMP 版本页面。
对于这些情况，您从自己的服务器提供 AMP 页面，确保 AMP 页面提供最佳加载性能非常重要。
如何帮助浏览器更快地加载 AMP 页面？
让我们快速了解一下优化 AMP 加载性能的工作原理。AMP 运行时需要加载，才能使 AMP 特定元素（如amp-img或amp-video）正常工作。这意味着amp-img仅在加载 AMP 运行时后才会开始下载图像。
这为我们提供了两个机会来使 AMP 页面加载速度更快
- 确保浏览器尽快下载 AMP 运行时。
- 告诉浏览器即使在 AMP 运行时可用之前也要开始下载重要资产（如图像）。
实现此目标的关键是使用资源提示（如rel=preload）来优先下载关键资源。该AMP 优化指南描述了如何使用资源提示来优化 AMP 页面的不同方法。查看AMP 样板生成器也是一个好主意，它允许您快速生成优化的 AMP 模板。
如何改进首次内容绘制？
还可以进一步优化性能。AMP 运行时实施了静态页面布局系统，以减少渲染和滚动垃圾。它的工作原理是，AMP 样板代码最初隐藏文档，直到加载 AMP 运行时。加载后，运行时会计算布局并显示内容。这种方法的缺点是，用户在加载 AMP 运行时之前会看到一个空白页面，并且不支持渐进式渲染。
为了抵消负面影响，首次内容绘制 (FCP) 时间可以通过使用 AMP服务器端渲染来改进。这样，就可以删除 AMP 样板，以便 AMP 文档可以在不运行 AMP 运行时 JavaScript 的情况下进行绘制。例如，AMP 样板生成器 渲染速度快两倍，比普通 AMP 版本快：
性能提升是什么？
为了找出优化对加载性能的影响，我创建了AMP Start 自行车商店模板的着陆页的三个不同版本：
-
- 无图像：模拟最佳情况，其中没有视觉内容依赖于 AMP 运行时加载。
- 图像：显示内容依赖于 AMP 运行时加载时的加载时间。
- 自托管字体：演示加载自定义字体的影响。
对于每个页面，我测试了四个不同的变体
- 原始：原始的有效 AMP 版本。
- 优化：优化的有效 AMP 版本，它实施了以下优化：
- 优化 + SSR: 实现了与之前版本相同的优化，但额外使用了 服务器端渲染 通过 AMP 优化器。 注意：此版本不是有效的 AMP。
- 缓存： 作为 Google AMP 缓存提供的版本的参考。
所有测试均由 Webpagetest 在摩托罗拉 G（第 4 代）上的 Chrome 中运行三次，使用 1.6 Mbps 的 3G 连接，延迟 300 毫秒。您可以在此 文档 中找到完整的测试结果，包括指向 Webpagetest 的链接。由于测试是在真实设备上运行的，因此执行时间可能会有所不同。
现在，让我们看一下结果
无图像
| 加载时间 (s) | 开始渲染 (s) | 首次交互 (s) | ||||
| 原始 | 4.569 | 4.569 | 4.424 | |||
| 优化 | 4.564 | -0.11% | 4.564 | -0.11% | 4.423 | -0.02% |
| 优化 + SSR | 2.233 | -51.13% | 2.233 | -51.13% | 4.48 | 1.27% |
| AMP 缓存 | 2.039 | -55.37% | 2.039 | -55.37% | 3.508 | -20.71% |
服务器端渲染版本的加载时间快了 50% 以上，这清楚地证明了服务器端渲染 AMP 的优势。但是，交互时间保持不变，因为它仍然取决于 AMP 运行时的加载。
图像
| 加载时间 (s) | 开始渲染 (s) | 首次交互 (s) | ||||
| 原始 | 5.435 | 4.591 | 5.367 | |||
| 优化 | 4.591 | -15.53% | 4.566 | -0.54% | 5.094 | -5.09% |
| 优化 + SSR | 4.095 | -24.66% | 1.892 | -58.79% | 4.818 | -10.23% |
| AMP 缓存 | 3.827 | -29.59% | 1.834 | -60.05% | 4.13 | -23.05% |
在这里我们可以看到，预加载图像显着提高了加载时间。有效的优化 AMP 版本加载速度快了 15%，而优化 + SSR 版本“仅”快了 24%。这是因为图像渲染取决于 AMP 运行时的加载。
自托管字体
| 加载时间 (s) | 开始渲染 (s) | 首次交互 (s) | ||||
| 原始 | 5.509 | 4.609 | 5.424 | |||
| 优化 | 4.55 | -17.41% | 4.53 | -1.71% | 5.112 | -5.75% |
| 优化 + SSR | 4.478 | -18.71% | 1.989 | -56.85% | 5.203 | -4.07% |
| AMP 缓存 | 3.978 | -27.79% | 1.847 | -59.93% | 4.317 | -20.41% |
在这种情况下，优化和优化 + SSR 之间的整体加载时间差异变得非常小，因为服务器端渲染版本因额外的字体下载而延迟。但是，渲染仍然以服务器端渲染的速度更快地开始。
注意：AMP 缓存在所有情况下都更快。主要有两个原因
- 它执行额外的图像优化
- 它不需要建立第二个 https 连接来下载 AMP 运行时，因为运行时是从同一个域提供的。
结论
我们已经看到，可以在您自己的服务器上使 AMP 页面加载得更快。发布 AMP 页面的每个人都需要记住以下要点：
- AMP 首选网站： 所有 AMP 首选网站都应努力发布优化的 AMP，以提高加载性能。
- 配对 AMP 网站： 如果他们的 AMP 页面在其自己的来源（例如通过移动设备上的 Twitter）获得了大量流量，则应发布优化的 AMP。
我们正在积极努力发现新的优化方法并改善 AMP 加载体验。
作者：Sebastian Benz，Google 合作伙伴开发者倡导者