谷歌为什么要推出AMP计划？

谷歌为什么要推出amp计划？

谷歌近日宣布名为AMP的网页加速项目，去提高移动端网页载入的速度。AMP是一个开源项目，这项技术可以限制HTML，CSS，JavaScript中可能会影响网页加载速度的代码。谷歌表示，这项技术可以帮助Nexus 5手机在3G网络下提高网页加载速度15%到85%。（谷歌AMP和百度MIP对SEO的影响）

这个项目的技术核心是AMP HTML。其可以最小化HTTP请求，并将整个网页的内容同时加载。但是这项技术将会限制CSS，像动画和滚动条这样的内容可能会收到影响。并且使用JavaScript代码的内容，也将不会被支持。

原来的移动手机站具体存在的问题是什么呢?

在讨论解决方法前，花费一点时间去探索问题是值得的。如果你在移动设备上有大量阅读的经历，你很可能已经了解到在手机上或者电脑上基于web进行的交互是多么的差劲。页面的加载通常都很缓慢，渲染不稳定而且交互方式往往都很奇怪，这主要是以下两个原因造成的：

第三方的干扰

广告和一些跟踪分析的技术的插入，令到页面的体积增大，请求增多，哪怕用户手持的是一个带宽和CPU处理都受到了限制的设备。而且，页面往往表现得好像就是为了广告服务一样，为止插入了多个document.write()的调用函数。纽约时报最近做了个测试反映出iOS手机在安装了内容拦截软件后，页面体积的巨大减少和电池寿命的增加。

响应式网站设计造成的损伤

尽管大部分响应式网站在各个尺寸的屏幕上都表现良好，但是这也造成他们在手机上展示的时候带有大量的桌面显示资源。当Paul Irish针对Reddit的性能进行调查后，他发现很大一部分开销可以追溯到SnooIcon上。Reddit的吉祥物是使用svg渲染的，这样子他可以在鼠标悬停的时候展现动画效果（基于第三方库，意味着高开销）——这不是经常可以在移动设备上找到资源的情况。

根据Facebook的调查(PDF, 3.4 MB),一篇文章在移动设备上的平均加载时间为8秒。这就是Facebook即时文章、苹果新闻、和AMP所处的世界。花费八秒钟去加载显然是十分夸张的，这已经足够让你去浏览第二个Vine视频了。客观的说，按照今天的标准，这仿佛就是永远都加载不完。

AMP有何不同

一些介绍AMP和Facebook即时文章与苹果新闻不同处的背景资料会指出谷歌为它的新数字出版倡议做出的决定。

Facebook即时文章和苹果新闻有以下几个共同点：

app内嵌的体验

读者通过手机上的Facebook软件来访问Facebook即时文章，而苹果新闻则是采用了iOS 9中的一个完全独立的app。这两个平台均没有允许用户在app外阅读他们的文章。你可以认为他们都是一个特制的RSS更新应用。

联合驱动

然而Facebook和苹果采用了不同的联合格式（苹果新闻格式是基于JOSN的，而即时文章的标记则或多或少地被HTML标记在一个RSS推送中），他们都基于一个相同的原则：哄骗内容管理系统生成必要的联合格式，然后Facebook和苹果就会马不停蹄地去提取、解析，然后把它们弄得漂漂亮亮地，紧接着快速的进行自定义的渲染。

体验导向

尽管Facebook即时文章和苹果新闻都专注于性能，但他们同样关注如何使文章看起来更加现代化。两个平台均有组件容许我们打造圆滑流畅的接口，这一般都会带来可定制的、手工打造的的阅读体验。

相反的，AMP有另外的关注点：

基于web页面的体验

AMP的文件被设计成可以在浏览器和WebViews上渲染。

原子化的文件

尽管AMP的文件是需要在AMP运行时进行验证、解析和部分渲染，但是他们是在你的服务器或者CDN缓存里完全独立的文件，而不是一些可能会在某个点上被转化为文章，在APP上面渲染的源数据集。

面向性能

相比于交互模式或者美学元素，AMP更关注性能。这不是说AMP的文件都很小家子气（当他们使用正确的样式的时候，他们可以和Facebook的即时文章或者苹果新闻那样吸引人），但是相比于提供一些花哨的视觉效果例如疯狂的小东西,他们更关注如何让文章渲染的更迅速。

谷歌现在已经在搜索产品上使用AMP HTML。尽管这项技术还存在一些限制，但是谷歌表示已经有30家发行商和科技公司参与了该项目，其中包括，BBC，纽约时报，Buzzfeed。

虽然这些初始的技术参数可能会被更改，但是AMP的技术规格已经公布在了Github上，供各网站试用。

目前谷歌在努力提升其移动端的阅读体验。虽然这项技术还存在一些不足，但是移动端拥有37%的流量，还是会吸引越来越多网站加入AMP计划。目前百度、搜狗、雅虎已经正式支持AMP！