听见英国 原文&amp翻译_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
听见英国 原文&amp翻译
上传于||文档简介
&&绝​对​台​湾​原​版​,​翻​译​,​译​文
阅读已结束，如果下载本文需要使用5下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩43页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢[译]关于谷歌的AMP，你需要知道这些。 - w3ctech - 中国最大的前端技术社区
[译]关于谷歌的AMP，你需要知道这些。
2015年5月，Facebook推出了它的新应用内发布平台，。一个月后，苹果宣布旧的)体验（基本上是一个装满了新闻应用的花哨文件夹）会在iOS9中被全新的新闻聚合和发现平台所取代。
四个月后，轮到谷歌了。尽管有些姗姗来迟，但是却显得雄心万丈。他们宣布了一个将彻底改变手机新闻消费的计划和一个开源的基于web的解决方案，他们称之为或者简写为AMP。在短短几个月内，我们可以看到相对平静的数字出版业务已经爆发为一个全面的平台战争。无论是用户的关注度，还是出版社的忠诚度，Facebook、苹果、谷歌之间展开了激烈的争夺。
尽管Fackbook和苹果相对于谷歌具有十分明显的先手优势，但是我们有理由相信AMP会迅速的迎头赶上（甚至可能超越一两个竞争对手）。如果你是一个开发者或者发布商，并且想知道为什么AMP如此快速高效，他是怎么做到的？那么恭喜你，你来对地方了。
但是问题是什么呢?
在讨论解决方法前，花费一点时间去探索问题是值得的。如果你在移动设备上有大量阅读的经历，你很可能已经了解到在手机上或者电脑上基于web进行的交互是多么的差劲。页面的加载通常都很缓慢，渲染不稳定而且交互方式往往都很奇怪，这主要是以下两个原因造成的：
第三方的干扰
广告和一些跟踪分析的技术的插入，令到页面的体积增大，请求增多，哪怕用户手持的是一个带宽和CPU处理都受到了限制的设备。而且，页面往往表现得好像就是为了广告服务一样，为止插入了多个document.write()的调用函数。纽约时报反映出iOS手机在安装了后，页面体积的巨大减少和电池寿命的增加。
响应式设计造成的损伤
尽管大部分响应式网站在各个尺寸的屏幕上都表现良好，但是这也造成他们在手机上展示的时候带有大量的桌面显示资源。当针对Reddit的性能进行调查后，他发现很大一部分开销可以。Reddit的吉祥物是使用svg渲染的，这样子他可以在鼠标悬停的时候展现动画效果（基于第三方库，意味着高开销）——这不是经常可以在移动设备上找到资源的情况。
根据(PDF, 3.4 MB),一篇文章在移动设备上的平均加载时间为8秒。这就是Facebook即时文章、苹果新闻、和AMP所处的世界。花费八秒钟去加载显然是十分夸张的，这已经足够让你去浏览第二个Vine视频了。客观的说，按照今天的标准，这仿佛就是永远都加载不完。
以下是一段介绍Facebook即时文章、苹果新闻和AMP的视频。注意到Facebook的即时文章和苹果新闻都是APP内嵌的页面，而AMP是完全基于浏览器的。
AMP有何不同
一些介绍AMP和Facebook即时文章与苹果新闻不同处的背景资料会指出谷歌为它的新数字出版倡议做出的决定。
Facebook即时文章和苹果新闻有以下几个共同点：
app内嵌的体验
读者通过手机上的Facebook软件来访问Facebook即时文章，而苹果新闻则是采用了iOS 9中的一个完全独立的app。这两个平台均没有允许用户在app外阅读他们的文章。你可以认为他们都是一个特制的更新应用。
然而Facebook和苹果采用了不同的联合格式（是基于JOSN的，而则或多或少地被HTML标记在一个RSS推送中），他们都基于一个相同的原则：哄骗内容管理系统生成必要的联合格式，然后Facebook和苹果就会马不停蹄地去提取、解析，然后把它们弄得漂漂亮亮地，紧接着快速的进行自定义的渲染。
尽管Facebook即时文章和苹果新闻都专注于性能，但他们同样关注如何使文章看起来更加现代化。两个平台均有组件容许我们打造圆滑流畅的接口，这一般都会带来可定制的、手工打造的的阅读体验。
相反的，AMP有另外的关注点：
基于web页面的体验
AMP的文件被设计成可以在浏览器和上渲染。
原子化的文件
尽管AMP的文件是需要在AMP运行时进行验证、解析和部分渲染，但是他们是在你的服务器或者CDN缓存里完全独立的文件，而不是一些可能会在某个点上被转化为文章，在APP上面渲染的源数据集。
相比于交互模式或者美学元素，AMP更关注性能。这不是说AMP的文件都很小家子气（当他们使用正确的样式的时候，他们可以和Facebook的即时文章或者苹果新闻那样吸引人），但是相比于提供一些花哨的视觉效果例如,他们更关注如何让文章渲染的更迅速。
究竟什么是AMP
足够的哲学思考和高质量的决定。让我们看看细节。让你关注Facebook即时文章和苹果新闻是非常容易的（他们基本上都是一些在联合格式上面专门定制的花哨新闻的集合），而AMP则不同。这一点比较难把握，因为以下两个原因：
没有一个简单的模型来比较
当RSS刚刚推出的时候，我们都为他的力量惊叹不已，写了无数的文章和博客来宣称其巨大的潜力，（再次），然后我们就忘记了这所有的一切。除了它们摒除了所有标准带来的不方便，并且只是在一个应用中工作，Facebook即时文章和苹果新闻本质上是一次RSS的重启，
AMP不是一个客户端
当然Facebook即时文章、苹果新闻和AMP有有几个共同的元素，例如都有专有的联合格式和自定义化得渲染，然而AMP是唯一一个没有专用客户端的（除了浏览器）。和他们相比，AMP是一套规范、规定和技术可以结合成各种解决办法，而不仅仅是一个点对点的（出版商到读者）的方法。
既然现在我们知道要把AMP想象为一些配料的集合，而不是一个完全烤好的蛋糕，那么让我们看看这些单独的组件有哪些。
AMP runtime,
AMP cache.
AMP文件使用HTML编写的，但是不只是HTML。有些标签是被禁用的，并且引入了一些新标签（部分取代了那些被禁止的标签，并且提供了部分封装的交互功能）。你可以把AMP HTML想象成如果HTML仅仅是为了移动端性能而设计的样子（而不是像被引入iPhone前的14年前的那样）。
由于AMP HTML专为最佳性能而设计，所以要理解他的价值，我们必须要明白他解决的问题。以下是三件在移动端对加载和渲染造成最大影响的三件事情：
有效负荷的大小
响应式网站一直颇受我们欢迎，因为它允许我们建议一个可以适配每一个设备和屏幕的简单网站。但这也意味着在带宽和CPU都受到限制的移动设备传输着桌面模式的负荷（HTML, JavaScript, CSS and assets）。（那些认为自己的手机和一部小型电脑差不多的人们，的确是对手机给予了太多的信心了。你的iPhone 6s只有2GB大小的RAM，而你的手提电脑可能拥有8GB或者16GB）。
资源并不是总是以理想的顺序进行加载的，这意味带宽、CPU和RAM经常处理一些用户可能永远无法看到的部分。此外，资源经常不指明他们的宽高（特别是使用广告网络或者通过调用document.write()注入的时候）。因为资源的大小迟迟不能决定，页面经常要进行重新的绘制。并且会触发不必要的和昂贵的布局重新计算。这就是为什么页面像一只追踪激光的小猫一样胡乱跳动，因为他们以往的处理是如此低效。
JavaScript的执行
我不会在这里戳破JavaScript的性能问题，但是现代网站经常堆砌之。然而尽管他能在桌面计算机上没有任何明显延迟的执行，但是手机是一个十分不同的环境。我想我们都统一，JavaScript还是保持在一个较低的限度比较好。
描述了手机上流畅web体验的三个障碍，AMP HTML也主要存在三个主要目标：
AMP文件不是桌面版网站的响应式版本。虽然AMP文件可以是（并且通常都是）响应式的，但是他们主要响应移动环境。换言之，AMP不是一个可以在桌面端和移动端都绝对能运行的页面，他主要是为移动设备设计的。
控制外部资源加载
AMP runtime会控制外部资源的额加载来确保其高效性，从而让用户需要的内容尽快地出现在屏幕上。
封装交互功能
尽管AMP文件更倾向于提供给用户直接简单的用户体验，但是这并不妨碍他们变得现代和互动。AMP runtime提供了高度优化的被封装的JavaScript，所以开发者不需要冒险写他们自己的交互功能。
AMP HTML标记
下面是一些在AMP HTML上被禁止的标签：
显然，这个标签有很多内容要说。我会在下文谈论更多关于JavaScript的细节；目前，就假设你在AMP文件里唯一可用的script标签就是加载AMP runtime或者
base标签的禁止可能只是谷歌的一些比较谨慎的操作而已，如果社区抱怨的比较厉害，他很可能会。（不过我猜测没有人会关注这个）。
frame和frameset
确切来说在移动端上使用这两个标签并不是十分适合，所以抛弃掉。
object, param, applet和embed
可悲的是，你的AMP文件不能包含任何Flash或者Java小程序了。（这是讽刺，以防它不是很明显）
form和input元素 (使用button标签除外)
Form最终可能会被封装成一个组件，因为没有了脚本，他们实在。
接下来，将会是一系列用于替代的标签，它们的目的是优化资源加载并且确保更好的安全性：
替代img标签，能够根据视口位置、系统资源和链接优化资源加载。
替代HTML5的video标签，所以视频内容可以被懒加载（当然还是会考虑到视口因素）。
替代HTML5的audio标签，所以音频内容可以被懒加载（考虑到视口因素）。
amp-frame标签通过默认和在iframe可能出现的地方添加限制来确保他们占用整个AMP文档来确保安全性。
最后，这里是所有添加了功能和交互的标签，你可以使用它们而不需要编写JavaScript。
amp-ad标签确保了AMP runtime可以像加载其他外部资源那样来加载广告了（目前，广告往往是最后才被加载的），他确保了来自广告网络的JavaScript尅在内部执行而不用触发页面布局重计算。（再见了，doucment.write()）。
这个微型框架可以分析数据并且发送给第三方供应商。截止今日，Adobe分析、Chartbeat、ClickTale、comScore、Google分析、Nielsen和Parse.ly。
这是用于嵌入，而且它支持发送多个客户端变量到服务器。
这个优化组件在水平方向上通过互动的方式展示多个子图像。
这允许读者可以在一个全屏的“收藏夹”视图里打开图片。它同时支持缩略图和全屏图像。
这将用于加载GIF图像并且提供急需使用的占位符功能。
它设置了自定义字体加载超时，并且可以设定后备字体以防你的自定义字体没能在规定的时间内加载。
被amp-fit-text包裹的标签会根据可用空间自动分配一个适合的字体大小。你可以把它认为是一个比较小的响应式。
利用amp-list标签，你可以加载动态的、重复的JSON数据然后利用HTML模板渲染他们。（看下文的app-mustache标签）
这个支持你利用来进行渲染。
如果选择不适用AMP缓存（下文会介绍相关知识），amp-install-serviceworker标签会为当前页面加载和安装一个service worker。Service workers很好用，但是我认为现在就依赖于他们。
显然易见的，这嵌入了指定视频ID的youtube视频。
嵌入推特（可以选择推特卡）。
嵌入Instagram图片。
这个组件加载并且展示来自的视频（和视频播放器）。
内嵌一个组件，或者“Pin it”按钮到你的AMP文档中
Embed a Pinterest widget, or “Pin It” button, in your AMP document.
内嵌Vine视频到你的AMP文档中。
需要注意的是，amp-前缀不是一个标准的HTML标签，它们也不是专有的。相反，他们是利用JavaScript实现的，用于确保安全性和优化远程资源加载（会在AMP Runtime部分进行介绍）的合法的。换言之，尽管AMP HTML看起来像，事实上他只是一个比较聪明的符合web标准的应用并且和差别不大。
AMP HTML的样式
AMP文件的样式是由标准的CSS控制的，并且和你目前用的并没有特别大的区别。然后，有几件事还是需要记住：
所有的样式必须用内联样式文件来决定——不提供外链样式文件和元素级的内联样式。（一个外链样式文件会导致在布局计算前需要下载多一个文件，而元素级别的内联样式可能会导致文件臃肿。）
样式大小必须控制在50KB以内。谷歌的理念是，50KB的样式文件对于一个优秀的文档或者文章是足够的，但是对于一个好的网站还是不够的。
你的内联样式文件必须有amp-custom属性。（如&style amp-custom&）。
@规则——@font-face（会在下文讨论字体的时候谈到）、@keyframes和@media都是允许的。
一些选择器会由于性能问题而受到限制，例如通配符(*)和:not()选择器。
!important是被禁止的，因为要确保AMP runtime对元素的样式有最终的决定权。
可以通过覆盖默认类来为AMP自定义组件改变样式，如.amp-carousel-button-prev，或者使用一些预定义的CSS自定义属性，如--arrow-color。
所有外部加载的资源必须要明确宽度、高度和布局属性（在下文布局部分会讲到），来减少布局重计算的次数。
可以使用GPU加速（和不触发布局重计算的）的transitions和animations是允许使用的。目前opacity和transform都被加入了白名单。
有关样式文档的其他细节，可以阅读。
一篇按照AMP文件格式展示的纽约时报文章。 ()
如果你符合以下条件，AMP十分乐意去支持自定义字体：
字体必须装进一个链接标记中或者使用CSS的@font-face规则。换言之，你不能使用JavaScript来加载字体。
所有字体都必须通过HTTPS提供。
字体提供商必须被列入到白名单中。目前，在白名单中的字体提供商只有和fast.fonts.net。但是，考虑到出版商、广告方和分析提供商的支持，我猜测很快就会有更多的字体提供商被加入。
AMP的布局方法主要是围绕两个主要目标而设计的：
runtime必须能够在外部资源真正加载前推断出所有外部资源的尺寸，那样他才能够迅速的计算出最终的布局。一旦布局确定，文章就可以被渲染，用户就可以与其进行交互，哪怕广告、图片、音频和视频仍然未完成加载。（而且这些加载中的资源，会无缝的呈现，不会因为需要更新页面的布局而影响到阅读体验。）
AMP的文章应该是响应式的。就好像他的名字暗示的那样，AMP是专门用于移动设备的。所以，在这种语境下，“响应式”并不包括桌面端。相反的，AMP文件只需要在所有的移动端设备上面呈现良好即可，从老旧的细小的iPhone4到现在相对巨大的iPad Pros。
前者的目标主要通过要求所有外部加载的资源都具备宽高属性来实现。（还有对脚本的限制，让新资源不能被硬塞进来。）后者通过标准的媒体查询中的media属性、size属性和AMP专用的layout属性实现的。
以下是AMP目前支持的布局的概述：
这个元素最初不显示，但是可以通过用户的交互触发显示。（这与组件类似amp-lightbox一起使用的。）
这个元素具有固定的宽高，意味着runtime不能对他应用响应式处理。
responsive
我认为这是最有用和最神奇的AMP布局选项。无论被分配到什么空间，元素都会保持自己的宽高比。（基本上，让这个元素在任何分辨率下都显示的很好。）
fixed-height
这个元素会使用他自己所分配到的空间，但是会保持一个固定的高度。（在水平方向上进行缩放）。
这个元素会填充整个父容器而不考虑比例问题。（想像一下width:100%和height:100%。）
这个元素是一个容器，因此会让他的子元素来定义他的尺寸，就像标注的div元素一样。
利用AMP的布局系统来实现一个实用的简单的文件布局是相对容易的一个事情。但是当你需要考虑到每个需要支持的设备，然后如何分配每个元素的属性，仍然会有相当大的差异。对于更详细的介绍，你应该参考。
是支持的。基本SVG，无论是桌面端还是移动浏览器上。而且图像并没有比矢量更容易缩放，所以AMP和SVG是十分搭配的。最大的限制在于，由于脚本限制，你不能利用JavaScript来为你的矢量元素添加动画。不过实话说，你不应该在移动端上面做这种事。然而，如果你真的想让你的SVG动起来，根据上文样式部分所列举的限制，你仍然可以用CSS animations。记住SVG是DOM的一部分，所以他可以被控制样式，添加动画，就像其他元素一样容易。
AMP在JavaScript上面的哲学
既是好消息又是坏消息。坏消息是，很快你就不能为你的AMP文件写任何的JavaScript了。但是，这也是个好消息。记住AMP不是一个移动应用框架。相反，是一个移动文章框架，因此应该为文章优化出无缝的和流式的阅读体验，没有了臃肿的客户端脚本其实带来了十分多的好处。
话虽然这么说，但是永远禁止所有JavaScript毕竟是不现实和过于严厉的。现实情况是，网络依赖于JavaScript已经有一段时间了。即使在相对简单的阅读体验下，诸如广告、分析和交互特征等都需要JavaScript。另外，网络最好的事就是它的开放性和它无尽的创新力、表达力，这些大部分都是由JavaScript提供的。
既要考虑到任意的用户编写的JavaScript的性能问题，又要考虑到现代网络中JavaScript的普遍性和必然性，AMP团队推出了一下脚本原则：
现阶段不会有用户编写的JavaScript被允许和支持。在你的AMP文件中你只能有两种脚本标签：（它的类型应该是application/ld+json）和标签用于引入AMP runtime和拓展的AMP组件。
AMP的作者们预期大部分JavaScript的需求都是在移动文章的消费商，因此AMP支持了相关的替代品（amp-pixel，包括使用链接标记或者@font-face的自定义字体，等等）或者提供能够与AMP runtime兼容的插件（如amp-ad、amp-analytics、amp-carousel等等），从而确保安全性和性能表现。
如果你真的需要使用JavaScript来达成一些如交互的功能，你可以，然后利用[amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html)来引入它。被包含在amp-iframe中的内容甚至被允许与父文档进行有限的通讯如请求调整尺寸。
AMP组件是开源的（），并且期望大家参与进来。所以一段时间后会出现新的组件（事实上，在编写这篇文章的时候，已经有几个新的组件推出了，所以我已经更新了好几次）。尽管AMP团队会优先开发特定功能的服务组件（比如，一个用于启动社交的插件），他也会尽力提供足够多样的组件，以适应范围足够广的内容。
最后，所有的这些原则都可能会发生变化。因为浏览器的一些功能如web workers，自定义元素和shadow DOM将会被广泛支持，所以支持用户编写JavaScript，同时又能确保安全性和性能的可能性将越来越大。
想了解更多关于AMP组件的未来，可以阅读“”中的“拓展组件”部分
剖析一个AMP文件
既然你已经对AMP HTML有一个相当扎实的了解了，那么让我们来分析一个样板。
当然了，你会通过一个doctype声明来启动你的AMP文件：
&!doctype html&
接下来，指定你的HTML文件为AMP 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版本应该包含一个对AMP文件的引用：
&link rel=&amphtml& href=&my-amp-index.html&&
因为AMP页面是为移动设备设计的（你可能也想，所以确保自己引入了meta viewport标签：
&meta name=&viewport& content=&width=device-width,minimum-scale=1,initial-scale=1&&
下一行代码可能看起来会有点奇怪，这是因为它真的很奇怪。你还记得你看到过一些页面会在字体加载和应用前短暂地渲染文字内容，然后闪烁，接着才按照设计者期望的那样进行重新渲染？下面的标记是确保页面的透明度在他被正确渲染前为0（不可见）。
opacity: 0
&noscript&
opacity: 1
&/noscript&
这个方法的问题是，如果AMP runtime加载失败，技术上他不可能让页面的透明度从0变为1.为了弥补这样的突发事件，上面的代码会改成这样子：
animation: amp-timeout 0x 5s 1
@keyframes amp-timeout {
0% {opacity: 0;}
100% {opacity: 1;}
接下来就是引入AMP JavaScript runtime：
&script async src=&https://cdn.ampproject.org/v0.js&&&/script&
而引入拓展组件你需要这样子：
&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&: &http://schema.org&,
&@type&: &NewsArticle&,
&headline&: &Turn Your AMP up to 11!&,
&image&: [ &img/cover-opt.jpg& ],
&datePublished&: &T08:00:00+08:00&
现在让我们呢加入一些字体，可以用link标签或者在CSS中使用@font-face规则
&link href='/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'&
&link href='/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'&
然后我们将一些样式（不多于50KB），利用amp-custom属性引入：
&style amp-custom&
你现在可以去使用你刚学的AMP HTML去构建一个差不多规范的HTML文件了。
我不会花费太多时间在AMP runtime上，因为，就好像其他runtimes，这东西有点黑盒。这不是说AMP runtime不可访问（他是，和这个项目其他部分一样）。相反，就好像那些好的runtimes，开发者不需要确切的知道它是怎么工作的来优化它，只需要大致了解他在做什么就可以了。
AMP runtime是完全用JavaScript实现的，是由引入它的AMP文件来启动的，就像其他外部JavaScript文件一样。
&script async src=&https://cdn.ampproject.org/v0.js&&&/script&
从那里开始，AMP runtime主要做三件事情：
管理资源的加载和他们的优先级
插入AMP组件
可选的，为AMP HTML引入一个runtime验证。
验证器是创作符合AMP要求的文件的关键。它可以通过简单的添加`#development=1到文档的URL上，然后你就只需要打开你的控制台去观看你的报告单。
错误看起来是这样的：
AMP验证器在控制台中报错。 ()
一个漂亮整洁的符合AMP文档需求的会是这样子汇报的：
一个通过验证器的AMP文档。 ()
（可选的）AMP缓存
AMP文档可以像其他HTML文档那样从服务器上获取，但是他们也可以使用AMP缓存提供。可选的高速缓存技术使用了多种方式去优化AMP文件：
团向引用可以可以用为视口特定设置的尺寸的图片来代替。
首屏部分的图片可以使用内联的方式来节省额外的HTTP请求。
CSS变量可以内联来减少客户端的开销。
扩展AMP组件可以被预加载。
HTML和CSS可以被压缩来减少通过线路的字节数（或者电波）。
任何人都可以在他们自己的CDN中运行他们自己的AMP缓存。出版商可以免费使用谷歌的CDN。鉴于谷歌好像知道一些关于可拓展性的方法，我猜大部分AMP使用者会很乐意接受他们的提议。（关于如何操作谷歌缓存的文档即将到来，但鉴于谷歌已经索引和缓存互联网，我打赌它会围绕你的links标签进行更改或者是一个额外的meta标签。）
读者们如何找到AMP的内容
AMP文件与标准HTML相似可以让他在任何现代浏览器上面渲染，在我看来，这儿是一个巨大的优势（AMP相比于Facebook即时文章和苹果新闻更为开放和包容）。但事实上，他同样引起了一个问题，读者们怎样找到AMP的内容呢。
如果读者在移动设备上面使用谷歌进行搜索，各个可以直接链接到AMP版本的文章上（谷歌一直没有说AMP文件比非AMP文件更为优先，但是他说过他会，所以你可以考量一下）。事实上，，他可能早在2016年2月就会送搜索导流到AMP页面上。发现类引擎如Pinterest从而把流导向AMP页面。最后，网页可以把他们自己的流从响应式版本导向AMP版本。但是在我看来，这样子仍然有一些遗漏。
其他搜索引擎会把流导向AMP文章吗？（想和苹果做生意的搜索引擎或许不会这么做。）社交APP会在用户发出文章链接的时候预加载AMP文件，从而让文章即时渲染吗？（Facebook应该不会这么做。）移动浏览器会寻找与amphtml有关的link标签吗？（Chrome会，但是Safari应该不会。）集成商和新闻阅读器会特别去为快如闪电的AMP内容修改自己的设置吗？（是时候复活了。）
鉴于此，对于此问题的众多答案都是一致的：待定。
动起来去看AMP
最简单的浏览AMP的方式就是去看。如果你是特别容易信任他人的类型，你可以观看视频并认为现实里它的效果就是展示那样子。如果你是那种必须要，你可以在移动设备上面打开，并且自己尝试一下浏览AMP页面（下面是二维码）
AMP样例二维码。
你可以使用桌面Chrome的开发者调试公寓区体验AMP。你只需要这么做：
在Chrome里打开。
通过“View” → “Developer” → “Developer Tools.”打开开发者工具。
点击左上角的手机图标进入。
选择你最喜欢的设备进行模拟。（最好在模拟器里面重新加载一次）
在Chrome开发者调试工具中的AMP
谁会使用AMP呢
现在使用AMP仍然相对较早，所以很难说谁在使用这种新的格式，用到了什么程度。话虽这么说，但是我也已经看到了几个使用者，而且根据和所说，它已经被许多主要出版商、CMS开发商、广告商和分析提供商所重视（计量内容和订阅访问正在接受审查）。我不会列举他们，因为我相信这个表每天都在变化，但是你可以关注或者。
我觉得怎么样？
我很高兴你提出了这个问题，我猜测所有的出版商最终都会采用AMP。如果说像BuzzFeed这样的公司教会了行业什么的话，那就是尽可能地进入多个领域，数字出版应该是一个科技平台可以提供给读者他们想要的内容无论他们在哪，而不仅仅是个单一的点，等待读者来看。
支持AMP的成本也是比较低的。如果出版商已经支持了或者计划支持Facebook的即时文章或者苹果新闻，那么他们还不如顺便支持AMP。尽管CMS策略在整个行业里有巨大的不同，但是大部分CMS都有模板或者插件的的概念，一旦实现这种模板或者插件，大部分的AMP转换工作就可以完成。(Wordpress，已经有了相关并且在2016年1月。）因为AMP相比于他的竞争者更为开放（意味着他是开源的，乐于接受贡献，基于web与和客户端无关），所以出版商能够长久控制他们的的格式，我希望出版商会对此感到更加舒适。
现实情况是出版商会支持花费他们最低开销而能让他们的内容呈现在最多数量的读者面前的联合格式。目前为止，我们仍然在这场平台战争的非常早期的位置，这个时候各种格式会尽可能利用他们的独特优势争取尽量好的位置。在这个节点，还是很难判断谁会胜出，谁会成为明日的RSS。
扫码关注w3ctech微信公众号
只有w3ctech成员才能发表和回复。
后发表或回复！