现在有越来越多的人抱怨移动网络的网速太慢。这是个永恒的话题，因为无论移动网络网速多快，也满足不了日益增长的网速需求。在 14.4k 调制解调器下龟速上网的时代早已被人们遗忘，现在人们的要求的是瞬间打开任何网页。
然而奇怪的是，现在人们抱怨的并不是网速，而是抱怨网络本身。如果单说提高网速的话，可以透过提升网络速度、降低网络延迟、或是直接提高浏览器的速度来解决。但是抱怨网络本身的话，恐怕只能把黑锅丢给开创互联网的人背了吧。
网页在数量上的扩张速度是非常惊人的。由 HTTP Archive 进行的调查研究结果显示，在 2012 年 1 月，平均打开一个页面所需下载的资料量为 1239kB，共计 86 次请求；而到了 2015 年 9 月，资料量增长到了 2,162kB，请求数增加到了 103 次。这些数字虽然并不直接与页面下载和算图所需的时间相挂钩，但是却是网页所含讯息量发生变化的一个重要指标。
而另一方面，随着网络的发展，本地行动应用也在更为迅猛地发展着。得益于行动装置性能的增强，应用的反应速度也越来越快。因此随着时间的推移，应用程序的反应速度与移动网络的下载速度之间的差距越来越显著。至此，才引发了人们对于网速的抱怨。
这也就是为什么 Facebook 要开发互动式媒体内容创建工具 Instant Articles、为什么苹果开发新闻应用程序、为什么 Google 要开发 Accelerated Mobile Pages（AMP）的原因所在。Google 虽然慢了半拍，但是其开发 AMP 的目的与苹果、Facebook 是一致的，都像是想要使用户浏览 Web 的体验得到提升，使用户感觉就像在使用本机应用程序一样。
对于 AMP 而言，有两个影响用户体验的关键点，那就是 JavaScript 和基于 JavaScript 的广告。 AMP 的优势在于 Google 的强大服务器，劣势则在于 Google 广告。虽然听起来比较可笑，但广告的确是 AMP 的劣势所在。因为 Google 拥有网络上最大的网络广告服务器。如果广告是其中的问题根源，那 Google 为什么不直接从广告的下载速度上解决问题呢？如果你想了解 AMP，那么首先你需要了解Google 新服务本身。
什么是 AMP？
要了解 AMP，你还需要了解 Facebook 的 Instant Articles。Instant Articles 使用 RSS 和标准的 HTML 标签来优化精简所创建的专案。虽然 Facebook 会自动播放影片或音乐片段来提供一些额外的内容，但 Facebook 声称 Instant Articles 的下载速度，仍会比直接从开放网络打开快 10 倍以上。快出来的这部分速度一些来自于优化精简的内容，而另一些则可能得益于缓存。
但问题的关键是，Instant Articles 只能察看与 Facebook 签署过协议的网站内容。这意味着，从 Facebook 的 Instant Articles 上，只有在阅读如美国国家地理（National Geographic）、英国广播公司（BBC），以及 Buzzfeed 等网站上的内容时才会比直接从网页上看来的更快。苹果的 News 的工作方式也大致相同，使用 RSS 标准，然后苹果再对其中的内容加以优化。
所有这些应用程序都会对网络中的内容加以削减优化。这就基本相当于变相改善了 Web 网页日益臃肿的问题。
而 AMP 不同于 Facebook 的 Instant Articles 和苹果的 News 的地方就在于，它并没有用 RSS 或者 HTML 标准，而是使用了自己优化过的 HTML 标准。 AMP 上的 HTML 看起来就跟原 HTML 一模一样 ，一点也不花俏。事实上，如果你不去看顶部的 AMP 专案公告的话，你根本就不知道这个网页已经被 AMP 优化过，看起来就跟 Web 上的对应的网页一模一样。
在 AMP 上用于标记使用的 tag 标签非常有限，如表单标签、音讯或视讯标签、嵌入标签、脚本标签等全都没有。只有在 AMP 的顶端会出现一个很短的 HTML tag 列表。遭受同样命运的还有 JavaScript，AMP 中不会出现广告和追踪脚本。但是，虽然禁了其他的跟踪脚本，Google 其实还是会追踪你的。
AMP 自己也定义了一些标签，像是 amp-YouTube，amp-ad 或是 amp-pixel。这些 tag 标签将有可能成为 Web 标准的一部分（也可能变成“ActiveX”的第二部分）。
AMP 听起来是一个非常棒的专案——更快的网页下载、没有任何跟踪脚本、没有任何 JavaScript。不过，AMP 上同样也有一些设计上的缺陷。
AMP 透过使用自定义组件 amp-img 重新设计了滚动图并将原有的 HTML内容替代，同理也用 amp-audio 替代了音乐内容，用 amp-video 替代了影片内容。AMP 的开发者认为这可以让 AMP 只有在需要时才去调用这些下载项。然而，这却造成了对 Web 浏览器自身的限制，而不是 HTML 本身。 AMP 也很清楚这样做所带来的后果。你失去的不仅仅只是一些 HTML 标签，还有基于 CSS 的动画和滚动条。
不过好在 AMP 的开发者在听取意见上做得非常好。在初期，一个关于 AMP 的程式码曾遭到了强烈反对——原因是这条程式码禁用了阅读时的缩放功能。值得庆幸的是 Google 听取了意见，消除了影响缩放的 tag 标签。
AMP 的标记语言只是其中的一部分。毕竟，如果 AMP 真正想做的事是去掉所有的 Web 增强功能，只呈现页面的内容的话，它完全可以不必这么大费周章。提高下载速度对用户来说是一个不错的附带好处，但从 AMP 的角度来看 Facebook 的 Instant Article 的话，看起来 Facebook 就像是把用户锁到了一个特定的网站、形式或者说服务中。
问题就在于广告服务上
Facebook 开发 Instant Article 的目的是让你在 Facebook 上就能看到其他网站上的内容，这个方向是非常正确。如果能够在 Facebook 里享受到比在其他浏览器更加快的下载速度的话，用户又何必再去用别的应用程序来看呢。
Google 似乎是认识到了来自于 Facebook 的这种威胁——透过 Instant Article，Facebook 完全可以过滤掉 Google 的广告服务。于是 Google 迅速动手开发了 AMP 专案，其目的实际上就是为了增强它在行动广告服务领域的市场。至于为什么电脑用户被抛弃掉了，那是因为 Google 已经掌握把广告推送给你的能力了。
如果你看过 AMP 的展示影片，那你就能知道它在明年将会如何整合到搜寻结果中。AMP 页面在 Google 搜寻页的铺设方式和在其他网页中下载本机应用程序的方式是相通的。使得用户能够享受到非常快的反应速度。
为此 Google 需要把 Web 打造的和行动应用程序一样快。而它也有信心能够做到，因为 Google 有着世界顶尖的网络工程师。Google 也一直在鼓吹的移动网络优势。但网页的发展速度似乎总要比网速的成长更快，于是网速就相对上变得越来越慢了。
Google 已经竭尽自己最大的努力来尝试优化自家的浏览器，而 Chrome 也已经成为世界上最快的 Web 浏览器之一了。但是 Google 发现即使再优化也仍然是治标不治本。所以，在此基础上再对 Web 进行深度优化也就变得顺理成章了。
越来越多的使用者反映，过慢的下载速度已经成为了阻隔讯息和用户之间的一道壁垒。通常浏览器都会通过下载项控制来拦截不必要的内容，而这项功能虽然从出现到现在已经有十多年了，但一直被局限于桌面系统中。直到苹果 iOS 9 的出现，才标志着终于把这一简单的内容拦截工具移植到了行动系统中。
iOS 的内容拦截以及 News 应用，再加上 Facebook 的 Instant Article，你会突然发现——Google 的广告都不见了。而这才是 Google 真正关心的问题，也是开发 AMP 的核心意义。
静态页面需要 Google 的 JavaScript
你可以在 Web 上建立的最基本的网页就是一个包含一些基本的 tag 标签的 HTML 文件。无论拿什么来下载这种网页都会快如闪电。因为其中所含的讯息量很少，而你所要做的只是套个模版，把讯息放到网络上而已。根本不需要 JavaScript，甚至都不需要 CSS。
AMP 或多或少都希望你创建这种静态页面，不过 AMP 并不关心你的网页实际上是静态的还是那种可能需要从数据库中调用的网页，问题的关键是“什么呈现的是静态的”。但随后 AMP 就又要求每个页面下载第三方脚本。直到这个脚本下载完毕前，AMP 会故意将整个页面的透明度设为 0。只有这样页面才会被显示出来。
这的确有点让人摸不着头脑，一名叫作 Justin Avery 的开发者写道：“如果是这样的话，那么很明显直接下载这种页面会来得更快啊。”
Pinboard.in 的创作者 Maciej Cegłowski 就是这样做的，他组建了一个展示页面，复制了 AMP 为基础的（并且 AMP 主页上没有的）JavaScript。透过 3G 连接，Cegłowski 的页面在 1.9 秒下载完毕，而 AMP 的网页则需要 9.2 秒。JavaScript 拖慢了页面的下载时间，即使这个 JavaScript 本身也是 Google 计划中加快 Web 部件的一部分。
讽刺的是，Google 的本意是想鼓励出版商对自己的页面进行改良——将脚本内容压缩，并合理利用暂存。但改良之后却意味着网页将会下载的更慢，也就是说网站如果真的照 Google 说的那么去做了的话，在 AMP 上可能反而会变得更慢了。
最终，对于出版商而言最好的做法仍然是进行常规的 Web 开发，而不依赖于从 AMP 获得的资源。不幸的是，如今独自建立网站的出版商现在是少之又少。大多数出版商有很多地方能够获得与 AMP 相当的下载速度。Google 表示，AMP 将能够提高 15%~85% 的网页下载速度。这么大的变动范围很可能是根据网站上下载第三方脚本的多少而决定的。
对于 JavaScript 的依赖还会造成另一个不利影响。 AMP 依赖于 JavaScript，也就是说如果他们脚本由于某种原因无法下载，比如说你正在驶进了隧道之中的火车上，或是在讯号比较微弱的地区来连接 AMP 的话，显示的页面将会是完全空白的。一旦 AMP 页面失败，将会导致整个页面无法显示。
Google 自己心里很清楚，所以即使是它自己的 Gmail 中也仍然提供著基于 HTML 的备用版本。
为了出版商而开发的 AMP
按照 AMP 的要求，各大媒体所必须要做的就是放弃自己的网络广告。还有互动式地图，还有数据的可视化效果，以及评论系统。
用户可以得到 AMP 精简后的 WordPress 部落格。WordPress 在网络上所有网站的覆盖率高达 24%，而且还有一个简单的方法能够迅速从 WordPress 来生成 AMP 文件，这对于 AMP 而言意义非常重大，将能够极大的推动 AMP 的发展。这当然不是说去让 WordPress 来建立，事实上如果这么做了的话其实会适得其反。因为 WordPress 延伸套偰往往对下载时间有很大的负面影响。我们经常能看到往往一个 WordPress 站点下载了多个外部的 JavaScript 库，而这是由于用户安装了三个分别使用各自的库的延伸套件。AMP 则能够巧妙地透过优化这些部分而解决下载过慢的问题。
那么，为什么出版商希望使用 AMP 呢？因为它是 Google 的专案，而它的影响力已经渗透到各个行业，对流量有着强大的推动力。当 Google 决定发展某个专案，往往会牵动各大媒体的视线。
AMP 不是想摆脱网络，这我们都明白。它的初衷只是想要建立一个平行于 Web 的平台。在这个系统下，出版商不会停止生成常规网页，但他们通常也将在 URL 的末尾生成 AMP 文件（由早期采用者的例子来看）。 AMP 的页面和常规的 Web 网页将透过标准的 HTML 标签来实现相互转换，用户可以在两者之间做出选择。这也就是说，Google 的网络爬虫可能会抢了AMP 的页面，但台式机的 Firefox 也可能会把 AMP 页面重新定向到常规网址上。
或许，多年后 Web 上将不会再有 M 标准的行动专用网站，而是 amp 标准的行动网站。而做为浏览者而言，我们希望的当然是看到干净整洁，没有其他乱七八糟的下载项的网页。不要等待网页缓慢的下载，只要一瞬间的清爽。
如今，我们基本都是在碎片化的时间中来获取外界讯息，获取讯息的方式也越来越多样化。有些人喜欢在网上阅读，有的透过 Rss 阅读器来挑选自己喜欢的内容阅读，有的人透过 Facebook 的 Instant Article，有的透过在 Twitter 上的 AMP 网页来阅读，有的在自己的应用程序上阅读。我们所希望的是，从一个单一的软件上获取到外界所有的讯息，节省我们本来就不多的碎片时间。
AMP 和开放的 Web
虽然 AMP 可能会被强制设计为符合 amp 格式要求的页面，但到目前为止，它似乎看起来比开放的 Web 或是 Facebook 的 Instant Articles 更加亲民化。
如果往乐观的方面想，做为 Google 一直在寻找的加快网络下载速度的解决方案，其实 AMP 的前景是很美好的。正如 Web 开发人员（和 AMP 的乐天派一员）Jeremy Keith 所说：“我希望这会是一种双赢。在出版商透过创建 AMP 版本的网页以安抚 Google 的同时，也许他们会开始问‘为什么我们常规的网页无法做到这样快？’这样的疑问也会促使他们改善他们自己的 Web 网页，从而一起进步。AMP 专案将有可能成为推动整个 Web 前进的急先锋。”
当然，AMP 专案里的人也不都是那么乐观的。开发者 Tim Kadlec 写道：“AMP 感觉并不像一些常规的浏览器那样帮助下载网页，而像是把自己所制定的精简优化规范一点点拖到 Web 之中。Google 透过用一个非常具体的工具来改善开放网络。并向用户展示他们自己定制后的页面，吸引人们来使用 AMP 规范的网页。”
AMP 另一个重要的意义就是在于能够帮助出版商加速他们的网页：Google 将会免费把他们的网页缓存到 Google 自己的 CDN 中。“AMP 就是缓存……如果符合规则，您将可以使用其中的缓存。” 在 AMP 专案中负责 RSS 的 Dave Winer 这样写道，“如果你不这样做，你也可以使用自己的缓存，但这样做将会严重影响到 AMP 的效果。”
这其实就是 AMP 最大的潜在问题。如果 Google 决定滥用其做为网络的预设搜寻服务提供商的权限，将 AMP 页面设置为优先，那 AMP 将会对开放 Web 形成严重威胁。
到目前为止，Google 已经表示，AMP 的网页不会在 Web 搜寻结果页面得到任何优先权。但是，这随时可能会改变。Google为什么要自废武功呢？为什 么 Google 在正式发表 AMP 后不去使用速度更快的网页，而去将下载更慢的网页优先呢？毕竟，下载速度现在已经成为了一个重要的衡量因素，AMP 确实使网页的速度变得更快了。
从长远来看，很难说 AMP 将会以何种方式继续发展壮大。Google 经常会提出新的专案。比如 Gmail 就对电子信箱领域进行了再定义。其他专案也是一波接着一波。还记得 Google Author 吗？这是 Google 为了帮助出版业而做的最后一次努力。
对于 Web 而言，我们希望 Google 能够成功说服出版商使用 AMP。在未来能够真正帮助我们加快网页下载速度。就像 Cegłowski 在他对 AMP 的评语上写的那样：“现在是 2015 年，网站应该主动提供只需更少资源，能够快速下载的网页给行动装置……对于行动装置而言，要求这些网站提供更加舒适的可读版本是一个好主意。让我们进一步提高下载速度，并使其成为唯一的行动网页标准吧。”
- How Google’s AMP project speeds up the Web—by sandblasting HTML
（本文由 雷锋网 授权转载）
