摘要
移动设备、用户及其相关流量的快速增长,已经成为一些专注于改善移动用户体验(QoE)的项目的动力,但很少有像谷歌发起的加速移动项目(AMP)那样引起争议的,它既因其看似即时的移动网络体验而受到赞扬,又因对其格式的执行的担忧而受到批评。本文首次提出了AMP对用户的QoE的影响的特征。我们使用了一个超过2,100个AMP网页的语料库,以及相应的非AMP网页,基于趋势关键字的搜索来实现这一目标。我们通过观察常见的网络QoE指标来描述AMP的影响,包括页面加载时间(Page Load Time)、第一个字节的时间和速度指数(Time to First Byte and SpeedIndex SI)。我们的结果显示,AMP明显改善了SI,在不考虑预取的情况下,平均比非AMP页面的SI低60%。预取的AMP页面将这一优势进一步推高,预取的页面比非预取的AMP页面加载速度快2000多分钟。 然而,这种明显的提升可能要付出不可忽略的代价 对于数据计划有限的用户来说,这可能是一个不可忽视的代价,因为它平均会产生一个 超过1.4MB的额外数据下载,而用户并不知情。
(省略intro…)
1. Contributions
- 文章开发并应用一种方法来评估AMP的性能优势。使用一个语料库,其中包括 AMP和非AMP页面对的语料库,使用基于趋势性关键词的搜索。
- 文章首次提出了AMP对网络质量的影响的特征。对网络QoE的影响,分析了AMP设计的不同方面的贡献。
- 文章量化了AMP的性能优势和潜在的成本,具体表现在平均数量和额外字节的成本。
- 我们将收集到的数据、测试框架、AMP页面的语料库和测量结果提供给社区。
2. AMP OVERVIEW
AMP旨在通过降低网站复杂性和利用谷歌的大型基础设施和整个网页浏览管道的存在来提高移动网络性能。自2016年首次发布以来,AMP继续被内容提供商和cdn所采用。当用户通过启用amp的浏览器在谷歌中提交搜索时,搜索结果通常会包括启用amp的页面
2.1 The AMP URLs
与启用amp的网页关联的有三种不同类型的url:
AMP original URL是由原始内容提供商托管的页面的AMP版本(可能在提供者的CDN中),AMP的原始URL不会向来自谷歌搜索的用户公开。
AMP cache URL : AMP original URL被验证并缓存在谷歌自己的AMP页面专用CDN上,AMP CDN,作为AMP cache URL
AMP viewer URL:用户通常不会遇到AMP cache URL,而是看到AMP viewer URL,当用户进行web搜索并返回启用amp的结果时,其中一个结果将在隐藏的iframe中预渲染。如果用户单击此结果,则AMP查看器几乎会立即启动切换到已经呈现的iframe。在这一点上,用户并没有移动到不同的页面,但浏览者的URL将被更新以反映所显示的文件。为了更新浏览器的URL,浏览者使用历史API,该API限制新的URL必须与原URL在同一域(即谷歌的搜索结果URL)。这个限制意味着向用户显示的实际AMP页面必须由谷歌CDN提供,这与AMP缓存URL所在的AMP CDN不同。因此,显示在浏览器顶部的URL将使页面看起来属于谷歌(即,URL以www.google.com/amp/ 开始)。为了给内容提供适当的归属,每个AMP浏览者都会添加一个标题栏,显示页面的实际来源。
2.2 How AMP works
更简单,更好的页面执行和延迟加载,在AMP CDN中缓存和页面搜索结果的预渲染。
- 首先,AMP在很大程度上简化了原始网页,并用它自己的HTML标签取代了一些标准的HTML标签,一般用 )tag表示。AMP还限制了JavaScript和CSS的使用;AMP页面不允许包含任何作者编写的JavaScript,除了AMP提供的自定义AMP元素,其中有JavaScript在引擎盖下。AMP还限制了CSS代码的总大小,以最小化文件大小和提高加载时间。阻止JavaScript和CSS在初始页面加载期间阻止DOM呈现。
- 其次,AMP采用了对某些对象的延迟加载,并利用谷歌的AMP CDN进行缓存。它使用延迟加载来避免加载不必要的对象。例如,当前不在第一个视口中的图像和广告直到用户向下滚动时才被加载。
- 谷歌搜索结果中用户可能点击的一些AMP页面在谷歌的搜索结果页面上预先呈现,以进一步减少加载时间。
3 METHODOLOGY
3.1 Collecting a set of AMP pages
为了获得一组具有代表性的AMP页面进行分析,我们使用Selenium构建了一个crawler和scraper,从谷歌搜索结果中收集AMP页面url。使用的搜索关键词是来自 Google Trends for 2017。文章总共收集了670个关键词,其中来自全球的150个,来自美国的520个,删除重复的关键词后只剩下578个。该集合中近90%(522个)的关键词是英语,9%(52个)是西班牙语.剩下的1%的单词是汉语和土耳其语。文章的578个关键字在删除重复项后产生了一组3,401个独特的AMP页面。
3.2 Defining a baseline for comparison
文章不是制作一组有AMP的合成页面,而是依赖于大多数AMP页面都有由内容提供商托管的关联非AMP版本。在许多情况下,可以通过页面头中的标签很容易地找到非amp版本。通过确定相应的原始AMPurl来扩展文章的数据集后,我们只剩下2132个我们可以找到它们的非AMP对应页面。
3.3 Testbed
为了进行我们的评估,我们使用了一个testbed,它由一台使用WebPageTestv17.12 的机器组成,通过我们控制下的路由器连接到互联网。WebPageTest(WPT)是一个开源工具,用于测试网站在不同网络条件下的速度。
3.4 Web QoE Metrics
Page Load Time (PLT):加载页面上的所有对象的时间
Time to First Byte (TTFB):在客户端接收到有效负载的第一个字节的时间。
Speed Index (SI):一个“交互时间”度量,捕获页面加载时的视觉进度——可能是用户体验(UX)的更准确的近似——并计算内容绘制速度的总体得分。且性能较快的页面的SI分数较低。
3.5 Network Environment
文章的testbed的设置是基于该网络使用几种工具的特性分析,包括SpeedTest和NDT。并且验证了文章仿真移动连接的可靠性。图4显示了AMP页面在模拟和实际移动连接上的PLT分布。总的来说,PLT在模拟连接上的分布与实际移动服务的分布非常接近。
4 PERFORMANCE OF AMP
4.1 Overall performance
文章通过比较四种不同类型的页面来评价AMP的整体性能影响,分别是以下4种:
nonAMP(original content provider)
AMP original URL (original content provider)
AMP cache URL (AMP CDN)
AMP viewer URL (Google CDN)
文章的做法: 加载了每页三次,并测量了SI、PLT和TTFB这3个指标
从图a我们可以看到,最大的SI差距是在AMP original url和non AMP url之间,这表明AMP的大部分优势来自于页面复杂性的降低,而不是它对缓存基础设施的依赖。
而图b也是类似的结论,所有的AMP版本在PLT方面的表现都明显优于非AMP版本。这样巨大的好处来自于AMP的延迟加载,通过延迟对某些对象的加载,可以将它们排除在PLT计算之外。
图c中TTFB也显示了使用AMP的性能优势。有趣的是,AMP的原始url显示TTFB更接近非AMP版本,1225毫秒。我们认为,这是由于与AMP CDN或谷歌CDN相比,不同内容提供者的服务器和CDN的物理接近性更加具有多样性。
总的来说,AMP cache URL显示出最好的性能,而AMP viewer URL在所有版本中具有最稳定的性能。后者比前者略慢的原因在于做了一个预渲染的额外工作。
在对SI、PLT的对比中,越往右,这两者的差距越小, 原因是,在AMP viewer URL中存在AMP viewer的标题栏,它放置在原始页面的顶部,导致原始页面的内容在AMP viewer的第一个视口中被绘制得更少、 减少了更加繁重地页面加载的效果。
除此之外,文章进一步讨论了为什么AMP cache URL的变化程度比较高,这可能是由于对AMP原始版本的重验证的原因,AMP缓存默认3个月进行一次重验证。文章也把图5©中AMP cache URL最差的20% TTFB视为测试重新验证的页面。
summary: 虽然大多数站点的AMP版本的SI分布明显快于其他非AMP原始站点,但约9%的非AMP url的SI低于其对应响应AMP版本。
4.2 Website Complexity
文章发现,AMP页面的性能改进与每个页面下载对象的减少——特别是JavaScript对象——显著相关。
图7比较了通过五种类型的url,五种不同的文件类型(HTML、JavaScript、CSS、图像和视频)在每个页面加载的对象总数。而表2列出了每次比较的平均值和标准差(括号之间)。
总的来说,这三种类型的AMP页面中这些文件类型显示的对象数量相似。另一方面,与非amp版本相比,HTML、JavaScript和图像对象的平均数量都减少了近一个数量级。这一趋势再次反映了lazy loading的影响。
然后,文章发现AMP和非AMP页面的对象数量分布的形状存在显著差异。例如,AMP页面在每个页面的对象数量方面往往比非AMP页面更一致(对于所有对象类型,对象数量的标准分布在AMP页面上的总是比非AMP上的要小)。这些巨大的差异意味着下载不同类型的对象所花费的时间要少得多。例如,对于AMP cache url,加载非AMP页面的HTML对象的总时间从5,370 ms(σ = 4,473 ms)减少到1,979 ms(σ = 996 ms)。另一方面,时间的提高对于CSS对象则更小,因为CSS对象数量的减少没有那么显著。
文章对AMP版本的分析显示了一些对CSS和HTML对象的有趣处理。AMP需要所有的CSS inline。AMP页面中的大多数CSS对象都是字体或由第三方应用程序发起的CSS。除了来自第三方应用程序的CSS文件外,还有一些AMP页面与实际的从与原始页面相同组织的另一个URL加载的CSS对象。似乎这些提供者已经采用了这种技术来实现其页面的一致性。至于HTML对象,不像其他对象对象,AMP viewer url比其他AMP版本有更多的文件。更多的HTML对象通常是从AMP cache url下载的HTML页面。
4.3 Removal of objects blocking the DOM
AMP的主要目标是提高用户感知的初始加载时间,以提供一个“几乎瞬时的加载”;
然后文章讨论了影响 loading的原因是 DOM, 且DOM的加载会因为获取HTML或JaviaScript来阻止或延迟。
AMP对应上述问题的应对策略是:采用了额外的技术来防止对象阻止的DOM,包括使用异步JavaScript、inline CSS,以及最小化样式重新计算和从关键的DOM构造路径中删除不重要的内容。
文章重点分析DOMContentLoadedEventEnd (DOMLoaded),为每个版本的url记录在DOMLoaded加载定时事件之前加载的对象。图9显示了对于每种对象类型,在其页面的文档加载定时事件之前加载每种类型的对象所花费的总时间。
总的来说,文章发现AMP技术确实加速了AMP版本的DOMLoaded事件,如表3所示。无论版本如何,AMP页面加载除HTML外的大多数对象的时间通常很短,这是预期的,因为每个网页都必须加载基本页面。除了HTML对象,AMP原始URL的对象加载时间始终小于非AMP URL,AMP cache url 和AMP viewer url的DOMLoaded时间也小于AMP原始URL。前面几段中讨论的不同优化解释了这一点。
通过观察HTML对象,AMP缓存url和AMP viewer url都显示出比其他两个更小的差异。这可以通过从CDN中提供的页面来解释,它们的响应时间更加一致。HTML主要决定了整个DOMLoaded event,尽管AMP页面和非AMP页面之间的差距扩大了。
在AMP查看器url中,CSS对象的零加载时间是特别有趣的。此外,AMP viewer url比其他AMP URL有更少的CSS文件(这里是0),因为在其他AMP URL中的DOMLoaded事件之前加载的大多数CSS文件都是字体,而AMP阻止了在下载事件之前加载。
**summary:**通过消除阻塞DOM的对象,文档加载时间可以大大提高超过4倍,从非AMPURL的3179ms(σ=3599)到AMP缓存URL和907 ms的860 ms(σ = 532)AMP viewer url。
4.4 Fewer DNS Resolutions
AMP页面中对象数量的显著减少自然会导致生成的DNS解析减少。此外,由于AMP在AMP CDN上缓存了许多与页面相关的对象,因此我们应该会看到更少的DNS请求。
为了验证这一点,文章分析了生成的HAR文件(HAR 规范定义了 HTTP 事务的存档格式,可以导出有关其加载的网页的详细性能数据),从访问AMP和非AMP页面和计算在页面加载时DNS解析的数量。具体地说,我们看到每个AMP网址的平均值为16 - 18个DNS(σ≈10)解析数,而非AMP网址的平均值为52个DNS(σ = 33)解析数。
4.5 QUIC and AMP
AMP CDN服务器和Chrome浏览器的结合允许谷歌潜在地利用性能增强的用户级传输协议,如QUIC。虽然QUIC并不是AMP的严格特征,但考虑到移动用户通常接触到的网络条件的可变性,它显然有助于其性能。
实现方式:
使用了在Chrome中的QUIC标志(chrome://flags/#enable-quic),可以根据需要启用/禁用它,并在不同的网络条件下重复这个过程,如不同的延迟和损失比例。
结果:
在没有额外的延迟或损失(图中最左的两条线)的情况下,使用QUIC(QUIC-on)得到平均1983毫秒的PLT(σ=1046),比2082毫秒的(σ =1, 073).然而,在压力更大的网络条件下(图中最右的两条线),QUIC的使用比非QUIC设置(QUIC-off)显示出明显的优势,平均PL的间隙为1000msT(QUIC-on:2386ms(σ=1218) QUIC-off:3334ms(σ=1881)。
5 PRE-RENDERING WITH AMP CACHE
到目前为止,我们已经通过使用AMP的直接URL来比较非AMP页面和AMP对应的页面,从而分析了AMP的性能优势。然而,大多数用户可能会使用嵌入在web搜索结果中的AMP viewer url来访问AMP页面。
具体地说,在用户查看搜索结果页面时,当用户在搜索结果界面上时,AMP页面的第一个预视口上的资源已经被预取和预呈现。如果用户单击一个预渲染的页面,结果会以几乎即时的加载显示。
下面的段落讨论了文章发现的预渲染的好处和潜在成本的方法。
5.1 Capturing the advantage of pre-rendering
在AMP中的预渲染被限制在搜索结果中的第一个AMP页面,或者是AMP转盘中的一个AMP页面(当这个转盘位于搜索结果的顶部时,如图1a)。
如果上面没有AMP页面,如果/当用户向下滚动时,预渲染将在出现的第一个AMP结果上进行。
我们通过检查HAR文件来验证这一点,通过搜索任何来自于端点cdn.ampproject.org,AMP CDN。
为了理解AMP预渲染对搜索结果的影响,文章模拟指定用户选择,并捕获预渲染的全部好处。**对应做法:**对于数据集中的每个关键字,文章发出一个搜索,在结果页面中识别顶部的AMP URL,并加载相关的AMP页面,计算对应不同的QoE指标。且文章使用WPT工具,使用其脚本功能支持对网页请求序列的测试。
WPT支持使用其脚本功能进行网页请求序列的测试。我们为每个关键词运行一个两步脚本,只记录第一步(最初的谷歌搜索)之后的第二步(随后的 页面加载),然后再进行第一步(最初的谷歌搜索)。
图12使用AMP viewer URL来说明加载一系列预渲染和没有预渲染的对象之间的差异。在图中,每一行表示一个对象的请求、请求状态代码、响应的大小(大小0表示异步请求)以及处理该请求的时间。红色的竖线显示页面加载事件(PLT),我们显示在这一行之前加载的对象
对顶部和底部图形的快速比较可以看出,当用户访问第一个AMP查看器URL时,包括基本页和图像文件在内的大量对象没有被加载已经在预渲染过程中预取。这些预取的对象,将在PLT之前下载
5.2 Pre-rendering and QoE
文章现在研究在搜索结果页面上预取的时间,文章从页面加载开始就计算图中的每个时间,从图13可以看到预取总是在搜索结果页面的PLT之后开始。尽管在预取的开始和结束之间还加载了一些其他对象,但在该时间间隔内加载的大多数对象都来自AMP CDN。此外,我们还发现,如果建立到AMP CDN的连接(通过请求preconnect.gif)可以从页面加载的开始到PLT之后有所不同。
5.3 Cost of AMP Prefetching
但预取并不是没有代价的。为了估计预取的潜在开销,文章重新访问所选的578个关键字的搜索结果页面,并查看AMP的数量预提取和预渲染的数据。
做法:用关键字集测量通过AMP预取从web搜索结果页面下载的总字节。这意味着,对于大约90%的搜索结果,在第一个视口中没有AMP页面,因此,没有从AMP CDN预取数据(不滚动)。然而,对于其他10%的搜索结果,如果AMP结果出现在第一个视口中,则预渲染会产生不可忽视的开销。平均来说,看看这些网络搜索结果,AMP的预取行为会对使得数据平均消耗1.4MB(2.3MB with 95 percentile, and 6.1MB for the maximum)
虽然在第一个视口中带有AMP条目的搜索结果的比例是特定关键字使用集的函数,但文章假设来自谷歌Trends的关键字集合为最终用户预渲染的预期开销提供了一个很好的估计。我们认为估计的开销是一个下限,因为它不包括AMP资源在下一个视口中,尽管AMP将在滚动时预取这些资源。国际电联[30]的一份报告让文字估计了这种间接费用对用户的潜在成本。对于移动宽带价格排名前20的国家的用户来说,1.4MB的额外数据平均意味着0.14美元的额外费用。
6 IMPACT OF AMP’S FEATURES
图17显示了来自Sec.5中使用的收集的50个页面在PLT方面的性能差距。 图中的水平线显示,对于特定的页面(例如,www.crowfishboxes.com),AMP original、AMP cache、AMP prefetch 对非AMP版本的提升。最大的性能好处来自于AMP origin page,与基线的non-AMP url相比,PLT平均提高了9657ms,这种改进是AMP的许多静态方法和它采用的延迟加载的结果;AMP cache提供的好处不那么令人印象深刻,比AMP original url的平均PLT提高了714 ms,AMPcache减少了图像的大小和质量,这是AMP cache的一个关键功能,但并没有显著改善PLT,因为AMP只记录了第一个视口,而且可能只有一些图像。
正如预期的那样,预渲染的AMP显著提高了PLT。
7 DISCUSSION AND FUTURE WORK
在2018年2月至5月期间,我们采用了与收集AMP页面语料库相同的数据收集方法。使用相同的578个谷歌趋势关键词2017年,最近的一年可用的是,我们搜索关键字,并计算由我们的爬虫显示的AMP采用的内容提供商的数量.
图18绘制了每月采用AMP的服务提供者的结果数量的变化,使用2月的数字作为基线。除了3月份的小幅下降外,该数据显示了采用率呈增长趋势,4月和5月分别有514个和525个内容提供商。虽然这只是一个近似值,但基于随时间变化的流行关键词子集,越来越增长的采用趋势似乎很明显。
7.1 Criticism around AMP
AMP也引起了相当程度的争议。主要是由于担心谷歌的影响、内容归属的复杂问题
和预抓取的开销。
一个普遍关注的问题是谷歌对AMP结果的优先排序,AMP的转盘,可见的优先级,对内容提供者来说已经是一个需要考虑的重要事情.除此之外,人们还担心加载速度和搜索结果排名之间的关系。谷歌宣布了Google Speed Update[48],称谷歌将使用页面速度作为移动搜索排序。没有直接的证据表明这和AMP之间的关系,但这似乎是“自然的”,AMP的提高的性能将导致更高的页面排名。
另一个被提出的问题是,通过AMP viewer url向用户提供AMP页面,用户流量保持在谷歌的生态系统中。这一点,加上它强制执行的受限格式的AMP页面的“干净外观”,也造成了一些关于内容属性的混淆。为了解决这个问题谷歌试图通过在AMP查看器页面中添加源URL,并最终将URL匹配到原始源,来帮助将内容属性化到原始源。
最后,正如在第二节中所示。5AMP预取和预渲染结果会导致一些额外的数据。每次搜索中用于prefetch的平均1.4 MB的额外数据,于某些数据计划有限的用户来说不是微不足道的开销。
7.2 Future work
- 讨论更多网络配置下AMP的性能
- 更多关于AMP用户体验的定性研究可能有助于提高对AMP不同特性的好处的理解。此外,扩展对“用户”的定义,包括采用者和开发者可以帮助我们理解一些关于AMP的争议
- 将AMP与其他旨在改善移动用户的网页浏览QoE的技术进行比较也可能会很有趣,从而获得更多关于如何改善移动网页浏览体验的一般经验教训。
8 RELATED WORK
Client-side optimization
内容预取、预渲染和推测加载系统可以减少网络中的高延迟对web QoE的影响。带有预渲染链接标签的网页会触发预渲染,浏览器提前准备一个(隐藏的)页面,以便用户一点击链接就可以呈现给内容。
Proxy-based acceleration
许多研究建议和产品旨在通过划分客户端和远程代理服务器之间的负载过程来提高移动web的性能。例如,亚马逊Silk和OperaMini是移动设备的网络浏览器,并且有服务器辅助网络速度。
Platform solutions.
除了AMP之外,其他项目和提案也试图通过改变页面的编写和服务方式来减轻网络问题的影响。例如,拥有有影响力平台的公司已经投入了大量努力来提高其平台上移动网页浏览的性能,特别是新闻,以获取用户流量。Apple has provided Apple News for their mobile devices,and Facebook made Instant Articles available through the Facebook apps since 2012.虽然这些选项可以极大地改善移动体验,但它们的好处仅限于其特定应用程序的用户。
Network optimizations
HTTP/2和SPDY通过允许客户端浏览器在单个TCP连接上的所有请求,减少了PLT。HTTP/2还允许服务器在请求对象之前进行推测地“推送”对象,以改善加载时间。QUIC是继SPDY的协议,被谷歌广泛部署和使用。虽然不是严格的AMP,AMP在可能的情况下利用QUIC。
9 CONCLUSION
- 对加速移动页面(AMP)进行了定性,这是谷歌为提高移动浏览体验所做的最积极和最有争议的努力之一。
- 展示了谷歌搜索结果中AMP页面的预渲染是AMP响应能力的关键贡献者,但这可能会给移动数据带来巨大的开销,这取决于预渲染的使用率和用户访问预渲染网站的频率。
- .文章的工作有助于对AMP的性能效益进行独立的分析。