以下是来自 DART Creations 的 David Attard 的客座文章。 David 将向我们介绍 AMP（不知道这是什么？继续阅读）以及如何将现有网站转换为 AMP 网站。 提示：这样做是为了获得巨大的性能提升。 AMP 正在成为一件大事。 WordPress 正在这样做。 我收到了 Google 提示我这么做，并且 Analytics 支持它。
如果您关心访客的利益，您就会知道快速网站是良好用户体验的主要因素之一。 快速的网站可以在很大程度上让您的用户感到满意并再次访问。 坚决的网站管理员将始终追求那些几毫秒的速度提升。
使您的网站快速加载的一个重要的新方法称为 加速移动页面 (AMP)，这是一个由 Google 发起 的项目。 移动数据与我们的家庭 WiFi 连接不同。 它很慢。 AMP 旨在通过严格规定的方式消除网站中最无效的部分来帮助解决这个问题。
让我们来体验一下 AMP！
我们将了解如何将现有网页设计转换为 AMP。 然后我们将衡量它带来的差异。
为什么选择加速移动页面？
手机在移动网络上通常会遇到延迟问题。
即使对于包含静态内容的简单文章，页面也可能需要很长时间才能加载文本。 脚本、图像、视频……所有这些都需要更长时间。 也许广告会更晚出现，并且页面会调整自身以反映新加载的内容。 这并不是一个愉快的加载体验。
AMP 想要改变这一切。 发布商和科技公司已经走到一起，建立了最佳实践，这些实践将使页面快速呈现。
这是一个非平凡的问题。 AMP 的初始重点是静态内容，这使得更彻底的优化成为可能。
目前，AMP 只是一个开源的概念验证。 事实上，我们将遇到一些限制，表明这项技术仍处于起步阶段。
是什么让 AMP 比传统网站更快？
AMP 对源代码有非常严格的规则，以便获得它追求的巨大速度提升。
AMP 的基本原则包括
- 仅使用异步脚本。 非异步脚本会阻塞 DOM 构造并延迟页面呈现。
实际上，AMP 完全限制了 JavaScript 的使用。 脚本仅允许在为性能而精心设计的自定义 AMP 元素中使用。 自定义 AMP 脚本的示例包括 Google Analytics、Facebook、Twitter 和 YouTube。
第三方脚本（例如广告或第三方服务）被排除在关键路径之外，并且仅允许在 iframe 中使用。 同样，这不会阻止页面的呈现。
稍后将详细介绍脚本。
- 外部资源需要设置尺寸。 图像和 iframe 等内容需要具有尺寸，以确保 AMP 在下载元素之前知道其尺寸。
- 不要让任何内容阻止呈现。 简而言之，没有任何内容可以阻止 AMP 呈现。 外部元素包含在 iframe 中。 AMP 将创建 iframe 框，甚至不知道它将包含什么内容。
- CSS 必须内联且大小受限。 AMP 与通常选择在外部文件中链接 CSS 的做法相反。 AMP 强制使用内联 CSS，原因与脚本相同：因为 CSS 会阻塞呈现和页面加载。
内联 CSS 的最大值为 50 千字节，以确保其有效使用。
- 字体加载必须高效。 网页字体可能非常大，并且会严重影响性能。 在正常情况下，浏览器会被阻止下载字体，直到脚本和样式表下载完毕并准备就绪。 这会导致长时间的初始等待时间，直到大型字体开始下载。
在 AMP 中，CSS 是内联的，脚本是异步的。 因此，浏览器不必等到这些操作完成后才能下载字体。
- 仅在 GPU 上运行动画。 一些动画需要浏览器而不是 GPU 完成的页面布局更新。 AMP 将动画限制为
transform和opacity，以便不需要页面布局更新，并且所有动画都保留在 GPU 上，在那里它们运行速度很快。 - 资源加载优先级。 AMP 优化资源下载，以便首先下载最重要的资源。 仅当用户可能看到图像时才会下载图像。
- 页面即时加载。 PreConnect API 用于预取、呈现和下载用户可能使用的资源。 这是有效地完成的：仅当内容可能被请求（例如“屏幕可见区域”内容）时才会预呈现和下载。
AMP 的组成部分
对标准 HTML、CSS 和 JS 有许多“更改”，这些更改使使用 AMP 优化的页面获得了速度提升。
- AMP HTML：这些是使用自定义 AMP 属性扩展的 HTML 标签
- AMP JS：一个库，确保 AMP HTML 页面快速呈现
- AMP CDN：使用 HTTP 2.0 提供 HTML AMP 页面，以实现最大效率
将页面转换为 AMP 的步骤
由于我完全不熟悉 AMP，因此我遵循了他们的 推荐清单。
我想从一个现有的普通（非 AMP）页面开始，所以我从 CodePen 选择了一个 Pen：samyerkes 的 示例文章布局。
- 将 amp 属性添加到标签中
<html amp lang="en"> - 添加规范链接元素
<link rel="canonical" href="index.html"> - 更改了字符集标签。 请注意，这与 ALL-CAPS UTF-8 不同，AMP 对此很敏感。
<meta charset="utf-8"> - 添加元视口标签
<meta name="viewport" content="width=device-width,minimum-scale=1"> - 在
<head>的底部添加 AMP Project CDN 脚本<script async src="https://cdn.ampproject.org/v0.js"></script> - 将所有
<img>标签更改为<amp-img>并添加width和height属性。 例如<amp-img src="http://farm4.staticflickr.com/3595/3288866270_23cb40f37c_b.jpg" alt="Crashed plane vintage photo" height="1024" width="734"></amp-img>使用
<amp-img>标签时，您需要遵循此语法- 必须包含明确的
width和height。 - 建议包含一个占位符。 占位符会立即显示，因此在实际资源加载之前会有“某些内容”可见。 例如，您可以加载图像的低分辨率预览，该图像正在加载中。
<amp-anim src="animated.gif" width=466 height=355 layout="responsive" > <amp-img placeholder src="preview.png" layout="fill"></amp-img> </amp-anim> - 可选：
layout="responsive"。 阅读有关其他布局选项的信息。
- 必须包含明确的
- 删除
<link>样式表并使用<style amp-custom>内联所有 CSS
结果：改进的加载时间
测试环境是在 SiteGround GoGeek 共享主机帐户上创建的几个子域。 测试使用 GTMetrix 和 Pingdom 工具进行，并且运行了几次以消除来自外部环境的任何波动。
测试 1：短文章
我们进行的第一个测试是使用 CodePen 中指定的完全相同的文章，其中文章相对较短。
| 示例文章布局（原生 HTML） | 示例文章布局 AMP | |
|---|---|---|
| 测试 1 | 3.3 秒，1.17 MB，8 个请求 | 1.7 秒，1.18 MB，5 个请求 |
| 测试 2 | 1.2 秒，1.17 MB，8 个请求 | 2.0 秒，1.18 MB，5 个请求 |
| 测试 3 | 1.3 秒，1.17 MB，8 个请求 | 1.0 秒，1.18 MB，5 个请求 |
您可以看到一些波动。 如果仔细观察瀑布图，您会发现波动实际上主要来自 AMP CDN。 不幸的是，这是使用共享资源的副作用，该资源可能会承受负载。
测试 2：文章长度增加三倍，并包含三倍的图像
| 示例文章布局（原生 HTML） | 示例文章布局 AMP | |
|---|---|---|
| 测试 1 | 1.1 秒，2.3 MB，14 个请求 | 1.6 秒，1.18 MB，5 个请求 |
| 测试 2 | 1.1 秒，2.3 MB，14 个请求 | 0.9 秒，1.18 MB，5 个请求 |
| 测试 3 | 2.3 秒，2.3 MB，14 个请求 | 1.1 秒，1.18 MB，5 个请求 |
结果解读
除了实际加载时间之外，AMP 页面中的请求数量也低于普通页面。仅此一项，就能使页面速度更快，因为请求数量越少，等待的延迟就越少（每个请求都会受到延迟的影响）。
此外，当页面使用 AMP 后，页面的总大小也显著减小。包含大量图片的大型文章似乎从 AMP 中获益更多。
在我们进行的一项早期测试中，我们测试了一篇相当简短的文章，其中只有少量图片。这项测试并没有得出非常确定的结论，因此我们加大了测试力度。在我们现在展示的测试中，我们将文章长度增加了两倍，并将图片数量也增加了两倍。有趣的是，虽然我们使图片数量增加了两倍，但在文章的 AMP 版本中，请求数量并没有增加。
据我了解，除了 AMP 规范本身的效率之外，AMP 只加载视口以上的内容（这解释了为什么在图片数量增加三倍后，请求数量保持不变）。它只加载文章的第一部分，“视口以上内容”，因此内容更短、更小，当然也更快。
关于<script>标签的一句话
引用AMP 工作原理页面上的原文
我们很早就意识到，许多性能问题都是由在页面中集成多个 JavaScript 库、工具、嵌入内容等引起的。
紧随其后的是
考虑到这一点，我们做出了一个艰难的决定，即 AMP HTML 文档不包含任何作者编写的 JavaScript 代码，也不包含任何第三方脚本。
在我看来，这有点过于激进。
我理解，有些东西必须做出牺牲。性能提升是有代价的。即使在优化普通网站的性能时，你也需要做出一些妥协。
有时是网站图片的质量。高质量的图片会导致文件大小较大。有时需要牺牲功能。有时需要移除第三方脚本，例如社交网站集成。
你总是需要根据自己的优先级做出一些艰难的决定。
在我看来，完全消除脚本有点过于激进。像 jQuery、Bootstrap、Angular、React 这样的库……是当今 Web 开发必不可少的构建模块。
完全移除脚本是在自断其臂。这将使 AMP 完全脱离地球，进入一个狭小的世界。
只有当你愿意在网页功能方面做出非常严重的妥协时，它才会变得实用。即使在新闻网站领域，AMP 的初始关注点，也有一些艰难的挑战。
我们能猜测 AMP 的发展方向吗？
这还处于早期阶段，很难预测 AMP 的未来。坦率地说，我真的很希望 AMP 能够成功。网页变得臃肿不堪，对性能的关注度太低。我们需要真正努力让 Web 变得更快。HTTP/2 是朝着正确方向迈出的一步。AMP 也是如此。
不幸的是，由于缺乏对脚本的支持，AMP 感觉受到了限制。我希望 Web 开发人员能够共同努力，找到一个公平的解决方案，既能保持 Web 速度，又能实现我们所需的功能。
这是一个邀请。抽出一些时间帮助 AMP 项目。如果你没有足够的技术能力，那就阅读相关信息并进行测试。宣传它，让人们对它感兴趣。谁不想成为一个为所有人打造更美好、更快的 Web 的一部分呢？
关注 Google 一段时间后，可以预见 Google 可能会采取哪些措施来推动 AMP 的发展。我们可能很快就会听说 AMP 是 SEO 排名信号。你在这里先听到的。
如果这意味着用托管在特定平台上的 Web 替换免费且开放的 Web，我就不想。
我敢肯定，你不需要更改托管服务提供商。你想在哪里托管就在哪里托管。
不过我明白你的意思。它确实是一种非常奇怪的语法，浏览器无法原生支持，你必须链接
才能使其发挥作用。这是一种你无法控制的第三方脚本。不过看起来它是一个开放规范，并且有大量来自不同领域的贡献者。我不知道它成为“真正”规范的机会有多大（可能很小）。
需要说明的是，Tim Kadlec也表达了类似的担忧，并且有一些替代方案。
另外，我希望你睡得安稳；)
我明白了。所以你添加了他们的 JS 文件（大概必须放在头部），它会对页面进行重新解析。我想这样更好。但是它仍然严重依赖于 CDN。而且你可以自己做很多精简工作（包括内联 CSS，如果你喜欢的话）。我希望 Google 不要明确地给 AMP 加分，而不给其他能够通过其他方式获得相同效果的人加分。
嗨，Casey，
事实上，我们现在正在讨论为了效率而编写代码，这本身就是朝着正确方向迈出的一步。
正如 Chris 正确所说，你可以选择任何你想要的托管服务提供商。WordPress 刚刚发布了一个 AMP 插件，所以不用担心必须托管在特定的地方。
我的“担忧”在于，你必须有一个“不同”的网站版本。我曾经讨厌 m.site.com 这种做法，我觉得响应式设计要好得多，但这又回到了这种模式。
关于加分，我当然同意不应该给予这种偏见，但我确实相信 Google 已经奖励加载速度快的页面。但我相信他们可能会稍微偏向 AMP。他们确实有强迫实施自己喜欢的措施的习惯。HTTPS、移动友好……我相信这种情况还会再次发生 ;-)
这也是一个大忌，因为不支持 JS 的用户（此技术完全依赖于 JS）。
所以，方法很好——但技术不对。
这已经存在了
http://motherfuckingwebsite.com
http://bettermotherfuckingwebsite.com
注意到这两个网站加载速度有多快吗？当然，这会导致用户体验有疑问，并且无法满足大多数网站的需求。但是，当你抛弃所有无用的填充和冗余内容时，网站的速度就会惊人地快！
我自己的网站与第二个网站非常相似。最少的 CSS，仅此而已。
Web 已经变得像软件开发一样。有越来越多的资源，所以网站和软件工程师经常不在乎他们是否使用了越来越多的资源。即使他们浪费了这些资源。最终，一切都变成了一个臃肿的垃圾堆，人们依赖这个垃圾堆，所以它会继续滚成更大的垃圾堆。
Nadya 说得很好，想起这两个网站仍然存在，我忍不住笑了。
有时这一切都变得过于臃肿和不必要了……
嗨，Nadya，
哈哈，我已经很久没访问过这些网站了！
不过这正是重点——Web 变得臃肿，因为很多人只是沉迷于所有漂亮的东西，或者根本没有时间去关心效率（我们不妨不说懒惰——因为我知道我自己也有罪）。这正是 AMP 的意义所在——如果你不想自己动手，那么你将被迫接受它。
更好的是，如果大多数 Web 都支持它，我们就可以不去理会它，它会在服务器端自动完成……
我们正在进行这场对话，这本身就是一个良好的开端。
David
我认为当你提到“内联所有 CSS”时，你是指将所有外部样式表转换为单个嵌入式样式表，对吧？链接的页面一开始谈论的是内联 CSS，但该页面上的示例是嵌入式样式表。
嗨，Sasha，
是的，我就是这么做的，我嵌入了所有样式表，因为重写所有页面以内联 CSS 会花费太多时间。
从本质上讲，两者都可以 - 重点是双重的。
无需在渲染开始前完全下载外部 CSS
CSS 限于 50K 以确保有效利用它，并且从本质上讲，它保持精简（且快速）。
David
我不认为我理解整个 AMP 热潮。
那些专注于博客元素的大型网站从中受益，是的，绝对的，我明白这一点。但除此之外，这只是谷歌为了能够与 Facebook 和 Apple 竞争而推出的一种方式。
并且因为它已经开源，所以每个人都对此感到兴奋吗？
嘿，Piet，
AMP 的目的是使移动网络更快……请记住，世界上大部分地区（尤其是发展中国家）都是通过手机在非常糟糕的数据网络上访问互联网的。即使在发达国家，您也会发现很多移动数据速度缓慢的区域。
即使数据充足，很多时候也会受到严格的计量，因此提高效率具有多重优势。
最重要的是，它使访问 AMP 页面变得非常非常快。您必须尝试并体验它才能在现实中看到区别。
现在，就谷歌与 Apple 和 Facebook 竞争而言，我真的不认为这是重点。许多主要的出版机构已经加入，因为这将为用户提供积极的用户体验。我相信他们都有自己的议程，但在我看来，这将带来很多好处。
谷歌将如何通过 AMP 与 Apple 和 Facebook 竞争？
我实际上住在上海，它位于您提到的那些发展中国家之一，我可以告诉您，在有覆盖的地方，4G 的速度比大多数 Wi-Fi 连接快得多 :)
新闻中已经发布了许多关于 Google AMP 如何与 Apple News 和 Facebook Instant Articles 相比和/或不同的内容。
财富 去年 10 月发表了一篇文章，还有很多其他文章。
不要误解我的意思，对于大型出版商和其他发布大量文章的网站来说，它可能很棒。
但我看不出每个人都开始对此感到兴奋的原因，也就是那些没有博客的人。
还有其他方法可以使网站加载速度更快，我正在考虑静态加载。我认为，这才是应该炒作的重点 :)
好的，我明白你的意思，关于竞争。我不能说我不同意，但是。无论既得利益是什么，只要一项新技术以一种好的方式将我们的做事方式提升到一个新的水平，我认为这始终是一件好事——无论该技术的催化剂是什么。
这就是为什么在我看来炒作是好的，因为就像我在另一场对话中所说的那样，任何时候我们都在讨论如何让网络更快，我们都是赢家，你不觉得吗？
我对 AMP 感到兴奋。可惜的是，它集中在 Google CDN 和 Google 托管的脚本上，但其余部分都是社区一直在讨论但没有全面实施的最佳实践。AMP 页面从 Google 搜索结果页面加载的速度令人印象深刻，因此希望非开发人员会开始注意到这种速度，并要求他们使用和管理的网站也具有这种速度。
确实，您无法加载自定义脚本，但您可以加载 iframe，因此您仍然可以执行嵌入等操作。
（吹毛求疵：我相信网站的大小应该以兆字节 MB 或 Mebibytes MiB 为单位来衡量，而不是以兆比特 Mb（小写“b”）为单位来衡量。）
嘿，Flimm，
我相信 Google CDN 是我们可以习惯的东西。或者找到一个更好的地方来托管它——现在还处于早期阶段，改进势必会发生。
同意速度感知，我希望这最终会被更多的大人物采用……然后问题就变成了人们赶上最佳实践以跟上步伐。
同意，随着采用率的提高，我们将找到更多解决当前存在的“问题”或限制的方案。
感谢您的吹毛求疵，我们会更新它！
David
在我看来，AMP 有点被夸大了。它只是执行性能最佳实践（即不要使用脚本，内联必要的 CSS，异步加载所有内容等）。
无论如何，文章中的这一行
没有多大意义。AMP 用于静态内容页面，例如新闻文章。静态内容页面上没有脚本和其他动态元素的位置。当然，也有一些例外，例如广告、分析等——但归根结底，我们并不是在谈论将 AMP 用于任何动态内容。
嘿，Agop，
当然，它只不过是执行最佳实践——同意。鉴于 WordPress 已为此提供支持并发布了 AMP 插件，我认为这是迈向使网站速度更快的一大步。
关于另一条评论，您自己指出了需求。我在该段落的那部分中的观点是：如果我们必须将 AMP 扩展到新闻文章之外的内容，例如博客文章会怎样？不太动态，但仍然有很多脚本会被禁用。在我看来，肯定有很多改进的空间。
我是在为脚本问题的解决方案辩护，而不是抱怨它。
对于使用 Drupal 的用户，请查看模块（实际上是一个完整的发行版）AMP。还有一个关于它的演练博客文章，今天刚刚发布。Drupal 8 有一个 beta 版本，Drupal 7 有一个开发版本。该博客称，Drupal 7 的 beta 版本将在未来两周内发布。
还有另一种替代方案Amp Project 模块和主题。尽管最近有提交，但目前还没有发布（甚至没有开发版本）。但是您可以通过 git 获取它。看起来专注于 Drupal 7。
感谢分享，Ivan
我努力使我的网站具有响应性和轻量级。最多 1 或 2 个 css，1 个 js，除了照片之外的所有内容都使用 svg。所有这些——感谢 Chris 提供这些！——结果是一个相当快速且兼容移动设备和桌面的网站。我没有与 AMP 进行比较，也许 AMP 速度更快。也许不是。造成差异的是广告。我不得不忍受很多糟糕的广告，其中包含大量的 js、跟踪器和垃圾，这些都使我的页面缓慢且臃肿。而且它们都违反了 AMP 的主要思想（异步脚本、渲染阻止等）！
即使 AMP 不会出现这种情况，因为它会对不良广告产生一定的影响——或者他们现在告诉我们的就是这样——但会持续多久？如果发布者在 AMP 上投放糟糕的广告，我们将回到原点，但我们仍然需要管理网站的两个版本。
如果我还要制作 AMP 页面，那么最初优化我的网站的意义何在？这难道不是我们几年前都采用的响应式设计的终结吗？
从长远来看，谷歌不会利用 AMP 页面上的广告投放来形成垄断吗？
为什么要为可以使用现有语法、已经拥有良好的浏览器支持和普遍知识的事情实现新的语法？这个选择似乎不合理，或者我是否过于墨守成规？在我看来，使用 AMP 不是一个技术选择，例如“我是否要为此项目使用 Sass？”，“我应该使用 iconfont 还是 SVG？”等。对我来说，它更多的是关于营销而不是关于开发和网络最佳实践。
当然，在一个一些理想主义者（像我一样）试图从他们的页面中删除所有谷歌、Facebook 等脚本的世界里，例如从 Analytics 切换到 Piwik，删除 Facebook 喜欢按钮等以避免跟踪器，将我的所有数据提供给谷歌并为我的访客提供一些隐私，你告诉我我必须在我的所有移动页面上放置一个新的谷歌脚本？伙计，他们真厉害。
这个 AMP 事情确实在我的脑海中引发了许多问题。不过，这篇文章是一个很好的概述。如果我使用的是 WordPress，我肯定会尝试一下。
嘿，Francois，
你提出了很多有趣的问题。当然，网站优化不仅仅是 AMP 的领域。您可以（也应该）实施您提出的建议，您将不需要任何 AMP 页面。
我不认为您必须“选择”是否要将页面 AMP 化。我的感觉是，展望未来，WordPress 和其他内容框架实际上可能会自动执行 AMP 化。
这将为每个人带来好处。您（作为开发人员）将不必担心必须使用 AMP。内容编写者（非技术人员）不必想知道为什么他们的网站速度很慢。移动访客将自动获得 AMP 化的页面。
这是一个理想的世界，也可能发生也可能不发生。我想我们必须拭目以待。
David
我非常同意您提出的所有问题和论点。直到最后一段。我不明白为什么 WordPress 网站会从 AMP 中获益，而非 WP 网站则不会。
因为安装插件并查看效果非常容易，无需编写任何代码。我没有使用CMS，所以需要从头开始构建一切。
我的意思不是说Piet，任何网站如果实现了AMP，无论是否是WP网站，都可以从中受益。
所以AMP引发了一些问题，但如果使用WP安装，这些问题就不会存在？
抱歉，这说不通。是什么阻止你设置WP安装以便尝试AMP？
您是否还进行过测试以确定速度指数？据我了解，内联CSS等的主要好处是首先加载关键内容。页面加载不是一个有意义的衡量指标。
我认为如果总体上关注性能，这确实是一种很好的编码方法和最佳实践。目前，当您等待页面加载或页面冻结以加载广告时，用户体验非常糟糕。问题：这将对响应式方法产生什么影响？想法？
正如你正确指出的那样，这些测量结果并不能很好地反映实际结果。获得良好的实际测量结果有点困难，因为我们没有专门计时来衡量AMP的好处。
这是一个非常好的问题……我认为必须有一种方法将两者结合起来。通过WiFi连接的移动设备上的响应式页面，应该与缓慢的移动数据连接上的AMP页面有所不同。
将AMP作为SEO信号对整个网络不利。
AMP可能对整个网络不利。谷歌希望所有网络流量在某些时候都通过他们的服务器，对于一家经常批评封闭花园理念的公司及其支持者来说，即使这些封闭花园并不真正存在，他们也肯定不会回避创建自己的收费公路。
Quentin，我并不是说我同意这种前进方式，我只是猜测如果谷歌想给它一个好的提升，未来可能会发生这种情况。
Cloudinary的新响应式图像调整器是否可以在不使用amp-img的情况下提供帮助？
任何将图像调整为更小尺寸的操作都有助于加快网站速度。
但这与AMP无关
我不同意…
允许脚本将完全破坏AMP希望实现的目标。如果允许这样做，我们会发现一天之内就会加载4个库，并且每个页面上都会有5000行自定义JavaScript。
那么AMP还有什么意义呢…？
如果您需要加载库和自定义脚本……那么请不要使用AMP……只需优化和简化您的响应式网站即可。
Ray，
我认为脚本在AMP中可能会有其用处。Twitter、Facebook和Google Analytics等已经有了与AMP兼容的“解决方案”。
我想说的是，可能存在一种介于两者之间的途径，可以带来两全其美的好处。当然，我还没有找到解决方案……
我知道你的意思…
这确实需要开发人员进行一些克制。
但从我的角度来看，即作为以客户为中心的代理机构的数字总监，我可以预见到会发生什么……
客户会希望X、Y和Z出现在他们的AMP页面上，开发人员将不得不让步并开始加载jQuery等等。
很快，我们将撤销AMP原本的目的……而且我将浪费大量开发人员时间，却没有任何实际收益。
目前，AMP还比较新，大多数客户不知道它有什么作用以及为什么它很重要。因此，在技术会议上，我可以说：“伙计们……我们可以在您的网站上提供AMP。但这里有一些限制。”
从某种程度上说，这实际上是一件好事……因为它可以防止客户肆意妄为。
目前，我们投入大量时间和精力来优化我们的移动体验。AMP只是让我们能够更进一步。
我完全同意你的观点。
鉴于AMP主要针对文章/新闻类网站，因此脚本肯定不是其关键部分。
是的，当你去找客户说，听着，你想要最快的体验吗？这些是限制，你能接受吗？
我很高兴我们也同意AMP的最后一点，即它推动了界限并有助于完全优化移动体验。
几周前我写了一篇文章，提出了关于Google AMP的一些问题并进行了一些速度测试。希望得到您的反馈！ https://medium.com/@mattshull/questions-for-google-amp-a6c1963b13cd#.283qqccfa
总的来说，我非常担心确保网络速度的这种方向。我有很多上面提到的问题，但我最关心/最大的问题是资产的预加载以及考虑到我在Buzzfeed页面上发现的内容，它会延伸到什么程度。
David，文章很棒！
嘿，Derek，感谢你的评论。
对AMP进行了相当深入的探讨，并且你提出了一些很好的问题。至于预加载问题，我认为AMP只加载当前可见的内容（即折叠以上的内容）。因此，图片丰富的网站不应该影响用户，因为图片将在用户滚动到它们时及时加载。如果它以这种方式工作，那么这将是一种非常创新且高效的加载图像方式。这也是您需要指定图像尺寸的原因，以便在图像加载时文章不会发生跳动。
David