AMP 如何为网络广告构建用户体验优先的生态系统?

阅读 556
收藏 8
2016-11-02
原文链接:mp.weixin.qq.com

文|Google AMP 项目的技术负责人 Malte Ubl

此故事讲述 Accelerated Mobile Pages(AMP) 如何为网络广告构建用户体验优先的生态系统。

在执行 AMP 项目时,我的工作很重要一部分是在 Twitter 上和我们的 GitHub 期刊中参与讨论,讨论主题围绕 AMP 是什么、它应该是什么以及它是否走在正确的道路上。通常,这些讨论最终会触及某人所说的问题:

“很好,你们让内容更快了,但广告呢?它们不是影响页面加载时间的最大障碍吗?”

AMP 的初衷是尽可能提升用户浏览网页内容的体验。因此,我们不能只是构建一些理想化的系统 - 必须支持现有的货币化方法才可获得广泛的采用,促成用户体验的普遍改善。在当今的网络中,它意味着:AMP 必须支持广告。
我在 AMP 项目的前几个月学习了许多有关互联网广告的知识,其中之一就是网络广告行业的改变并不是很快。事实上,看看网络上大量广告相关的 JavaScript,经常可以看到 90 年代情景的重现。
这导致 AMP 的设计做出了妥协:支持传统网络广告,这一妥协可以减小对嵌入广告的网页的影响。为实现此目标,AMP 使用以下方法:
  • 内容优先。AMP 先加载其余内容,最后再加载广告,以免广告减慢加载速度。

  • 限制。AMP 严格管理广告可以访问的页面区域,控制在一个明确的矩形范围内。另外,这也可避免页面在广告显示时“跳来跳去”。

  • 缓解。AMP 可缓解广告技术(例如“document.write”)中常见的各种 JavaScript 糟糕情形,限制它们对广告本身以及整个网页的影响。

  • 干预。AMP 可减慢计时器(例如用于当前不可见广告动画的计时器),这样广告在其未显示时使用的电池电量和 CPU 要少很多。Firefox、Safari、Opera 和 Chrome 最近开始默认执行此操作,当这推广到更多用户后,我们很乐意删除代码。由于在 AMP 中,所有传统广告都在 iframes 内运行(AMP 外部的许多广告可以访问主机页面),因此这些新的浏览器干预行为特别适用于 AMP。

这些措施加上 AMP 对一般网络内容的积极优化,可以显著缩短网页加载时间并缓解广告对用户体验的影响。特别是,始终先加载内容保证了广告永远不会妨碍用户在指定网页中的操作。
不过,实话实说,我们目前的方法还是有一些局限。先说说比较明显的局限吧:将广告延迟到内容后面加载可能是一个合理的折衷,但与精确控制广告生命周期的最佳策略相比,依然距离遥远。而 AMP 至今尚未解决的最大问题称之为协调问题。
协调问题

网络最大的优势之一是拥有超级灵活的组合模型,可以轻松地将诸如 YouTube 视频、Instagrams、Tweets 和广告等即兴合成到一个网页中。合成固然简单,但所有这些组件需要共享同一个负责执行 JavaScript 计算和大多数 UI 操作的线程。此时就会产生协调问题:虽然每个组件单独来看可能运行得很不错,但当组装到一起时,情况很容易恶化,导致糟糕的用户体验。
这是广告的常见问题之一。比如,可以想像一下,有 3 个广告,每个广告的每帧动画使用 6ms 的 CPU。这本身没什么问题 - 很容易保持在帧预算内,实现每秒 60 帧(每帧总时间 16ms)。但当这些广告一起出现在同一个网页中时,它们突然需要每帧 18ms,浏览器无法再提供每秒 60 帧的顺畅体验。
这就是协调问题:即使是设计得很好的广告,聚合到一起也会对用户体验产生负面影响。
最后,就算是忽略上述问题,为了提高广告素材的整体质量,改善它们对用户体验的影响,还是有很多工作可以做。最初设计 AMP 只是为了能够轻松地创建可在网络上良好运行的文件,但它似乎同样很适合创建网络广告。
推出面向广告的 AMP

今年初,Google 团队在思考这样一个问题:

“AMP 用于一般内容效果好得出奇,何不将其用于广告?”

…然后他们这样做了。这些基于 AMP 的广告本身就是正常、有效的 AMP 文档,只不过成了广告素材而已。我对此非常兴奋,因为它提供了一种解决上述所有技术挑战的方法,帮助我们构建一个技术上更加健康的互联网广告生态系统。

这是面向广告的 AMP(简称 A4A)的初期阶段,但在几个星期前宣布 GitHub 的相关工作之后,该团队已将他们的拉取请求合并到 AMP 中,目前正在安排现场试验。AMP 本身将继续支持非 AMP 广告素材,以便逐渐过渡到更庞大的生态系统。
将广告请求与广告渲染分开

回想起来,A4A 的第一项创新看似非常明显,但影响极大:如上所述,默认情况下,AMP 会先加载内容再加载广告,加载的速度通常很慢。这是因为渲染广告耗用的 CPU 和内存较多。

查看图片

但是,广告请求本身可能较慢,因为许多工作都必须在服务器端完成(想一想:拍卖) - 晚点加载不利于缩短加载时间。从客户端的角度来看,提出请求本身消耗的资源很少,但其副作用(广告的渲染)却代价高昂。将两者分开后,A4A 大大提升了广告渲染速度,而又不会增加 CPU 和内存开销。

更深入一步:AMP 受限的子集

AMP 的核心元素之一是随附的验证器,用于检查 AMP 文档是否符合某些规则。其理念是:如果符合规则,文档加载速度就会很快。我们为 AMP 设计的规则集考虑了广泛的文件类型和用例。另一方面,广告素材更关注用例,因此实际上不需要 AMP 所展现的全部功能。因此,面向广告的 AMP 会仔细挑选构建广告素材所需的 AMP 功能。例如,不允许基于 AMP 的广告加载包含任意 JavaScript 的 iframes。

这与广告技术的现状相反:广告素材通常完全控制浏览器,它们在运行时可动态加载更多代码,因此无法真正知道它们要做什么。另一方面,基于 AMP 的广告素材具有定义明确、可静态分析的行为,同时仍可访问绝大多数网络平台功能。

目前针对文档优化的 AMP 肯定缺少具有吸引力的广告所需要的许多组件类型。团队正在努力消除功能差距。例如,面向广告的 AMP 将随附一个组件,用于显示基于时间轴的平滑、交互式动画。
重复使用 AMP

广告通常自带一组衡量工具,用于收集重要信息,例如用户是否实际查看广告。这实质上会增加负载量、初始编译和执行时间、电池使用量以及运行时性能的其他方面。

通过其现有的 `amp-analytics` 机制,AMP 已随附进行这些衡量所需的全部代码。它不依赖于供应商,支持广泛的衡量指标。这意味着广告可以利用目前对 AMP 页面有益的 “测量一次,报告多次” 功能,完全消除上述带宽和运行时成本。

协调解决方案
就像所有其他 AMP 资源一样,基于 AMP 的广告也是页面布局的一部分。因此它们会自动利用 AMP 的功能尽可能减小对运行时性能的影响。
特别是,AMP 只对屏幕上可见的内容进行动画处理。先到此为止吧。浏览器正在平台级实现此功能,但必须谨慎,不能破坏现有用例。面向广告的 AMP 是新的专用技术,能够确定何时需要动画,从而进一步减少 CPU 的使用量和电池耗电量。
AMP 将充当广告监管员,确保广告不会对网页上的主要内容造成不利影响。当 AMP 检测到当前设备无法达到 60 帧/秒的速度时,基于 A4A 的动画会调整到较低但一致的帧速率。类似地,如果 AMP 无法稳定帧速率,将会关闭动画。这可确保每部设备获得其能提供的最佳体验,并确保广告不对用户体验的重要方面(例如滚动)产生不利影响。
跨平台

作为 AMP 项目的一部分,面向广告的 AMP 是一种独立于供应商的方案。虽然我们仍在早期的试验和实施阶段,但此技术的设计目标是支持所有广告网络。如果您使用广告技术,请在 GitHub 上打招呼吧:

https://github.com/ampproject/amphtml/issues/3133

我们认为 A4A 使用户体验前进了一大步,希望在互联网广告行业中得到广泛采用。

这正是我们对广告所做的工作

现在是早期阶段,我们刚开始探索将 AMP 用于广告。

在未来,
  • 对广告进行静态分析的结果将是:广告安全并且能良好运行,

  • 它们能够使用一组常用的功能显著减少带宽消耗,

  • 只有屏幕显示上的广告才会使用 CPU,从而最大程度地延长电池寿命,

  • 并且将与页面协调广告,确保主要内容和功能始终以 60 帧/秒的速度顺畅运行

我们正在努力为网络广告构建用户体验优先的生态系统,期待见到 AMP 在出版市场中取得成功,这可能行得通。

推荐阅读:

Google搜索结果正式AMP化

微信小程序和谷歌有什么关系?

谷歌为网站站长提供更多的安全浏览帮助

介绍一款好用的开源通用型渲染工具

AMP 和 React+Redux:为什么不呢?

查看图片
评论