译者：El_Nino_T9

原文链接

这是关于 AMP 怎么来构建用户体验优先的网络广告生态系统的故事。

AMP 是什么？AMP应该是什么？AMP 是不是在做正确的事？在 Twitter 和 Github issues 里讨论关于类似的这些问题是我在 AMP 项目的工作中一个重要的组成部分。通常这些讨论会得出一个观点，比如：

“Cool，你们让内容加载更快了，但是广告呢？广告不是更影响页面加载时间吗？”

AMP 的最初目标就是提升尽可能多的网页内容的用户体验。这意味着我们不能太理想化，我们必须支持现有系统的商业化手段来获得更多的采用，这样才能有更广泛的用户体验提升。在如今的 Web 上，这表示：AMP 不得不支持广告。

为 AMP 工作的第一个月里，我学到相当多关于互联网广告的事情，其中一项就是 Web 广告完全不可能很快发生变化。事实上，看着大量基于 JavaScript 的 Web 广告，你不免回想起 90 年代。

这就会导致 AMP 要做一些设计妥协：要支持传统的 Web 广告，当然，会以一种更不影响页面的方式来嵌入。为了实现以上目标，AMP 采用了以下方法：

• 内容优先。 AMP 会在内容加载后才加载广告，所以广告不会减慢页面的加载速度。

• 隔离。 AMP 将严格管理页面中的广告，广告只能访问和控制预先定义好的一块矩形区域。这样就避免弹出那种“跳来跳去”的广告。

• 缓解。 AMP 将通过限制他们对广告本身与整个页面的影响，来减轻各种 JavaScript 的最差实践，比如经常出现在广告技术的 document.write。

• 干预。 AMP 会减慢那些你暂时看不到的广告元素的用来实现动画效果的定时器。Firefox，Safari，Opera 和 Chrome 最近开始默认做这件事，当更多的用户接收到更新后我们很乐意删除掉这些代码。因为 AMP 内的传统广告运行在 iframe 里（很多 AMP 外的广告有访问宿主页的权限），这些新的浏览器功能将会在 AMP 里工作的很好。

这些措施，加上 AMP 对于普通 Web 内容的优化，显着提高了页面加载时间和减轻广告对用户体验的影响。尤其是，内容总是优先加载的事实保证了广告永远不会妨碍用户去做他访问这个网站要做的事。

然而，我们迄今为止采用的方法可能并不完美。在内容完全加载完后再延迟加载广告，这可能是一个还 OK 的妥协，但明显还远远不是最好的策略，我们还可以更细力度的控制整个广告生命周期。但目前 AMP 还没有解决这个最大的问题，所以这就是我们说的协调问题。

协调问题

来源: Daniel Stockman, License: CC BY-SA 2.0

Web 的最大优势之一就是它有一个超级灵活组合模型。这就让我们可以轻易的把像 YouTube 视频、Instagram 照片、推特还有广告之类的东西组合成一个页面。虽然组合在一起很简单，但是所有的组件都是共享同一个线程来做 JavaScript 计算，还有绝大多数 UI 操作。当每个组件独立工作的时候，可能性能非常好，但是当他们集成到一起的时候性能可能就会变得很糟糕，这就是协调问题。

这是广告的一个常见问题。比如，这很容易算，有三个广告，每个广告的动画一帧要消耗 CPU 6ms。这对他本身来说是没问题的，仍然能做到每秒 60 帧（或者说每帧计算的耗时还没超过 16ms）。但是当这些广告一起出现在同一个页面的时候，就突然需要 18ms 来渲染每一帧了，浏览器也就不能提供每秒60帧的流畅体验了。

这就是协调问题：即使设计的再完美的广告，当多个广告聚集到一起的时候，也会对用户体验造成负面影响。

最后，即使忽略以上所说，还有很多可以做，来提升广告创意的整体质量和他们对用户体验的影响。AMP 是为了能简单的创建高性能的的页面才开发的，但似乎能给 Web 广告带来同样的改进也是很伟大的。

介绍 AMP for ads

今年早些时候，谷歌的一个团队问他们自己的问题：

“AMP 对于普通的内容已经工作的很好了。我们能不能把他用在广告上？”

…这就是他们所做的。基于 AMP 的广告就是正常的，有效的 AMP 文档，只能碰巧他们是广告创意而已。AMP for ads 解决了上文所说的所有技术问题，把我们领向了一条技术上更健康的构建互联网广告生态系统的道路。

AMP for ads 或者叫 A4A 还处于很早期的阶段，但是几周前 AMP 团队已经在 GitHub 把 A4A 合并进 AMP了，并且在进行真实的测试。AMP 本身将继续支持非 AMP 广告，以便更广泛的生态系统逐步过渡过来。

分离广告请求和广告渲染

A4A 的第一项创新似乎非常显而易见，但是会有很大的影响：如上文所诉，AMP 默认将会在所有的普通内容加载完之后才懒加载。因为渲染广告很耗费 CPU 和 内存。但是广告请求本身会很慢，因为在服务端有很多工作要做（比如：竞价排名）——所以为了更快的加载时间，延迟做这件事是很不划算的。客户端发起请求代价是超级低的，只是副作用（广告的渲染过程）很昂贵。通过分离这两者，在没有额外的 CPU 和 内存 消耗下，A4A 实现了更快的广告渲染。

一个A4A 带给简单广告的性能提升的示例视频。

更深入一点：一个受限制的 AMP 子集

AMP 的核心要素之一是附带一个验证器，检查 AMP 文档必须遵守一定的规则。我们的想法是：如果符合了这些规则，那么这个文档就能加载的很快。我们为 AMP 设计的规则集包含了我们眼中的一整套文档类型和用例。广告从另一方面来说，是一个更明确的用例，因此并不需要 AMP 暴露出完整的功能。为此，A4A 仔细挑选出 AMP 中构建广告的时候所需的东西。举个例子，基于 AMP 将不允许任意的 JavaScript 加载 iframe。

与此形成鲜明对比的现状是：广告内容通常具有在浏览器的完全控制权，他们可以在运行时动态的加载更多代码，所以要搞清楚他们究竟将会做什么是不可能的。基于 AMP 的广告从另一方面说将会有预定义的，可静态分析的行为，同时还能访问绝大多数的 Web 平台功能。

AMP 目前对文档所作的优化，肯定是缺少了很多实现漂亮广告需要的组件。AMP 团队正在努力减少这些功能上的差距。比如 A4A 将带有一个流畅的可交互的基于时间轴的动画组件。

AMP 再利用

广告一般都带了一套他自己的监测工具来搜集一些重要信息，比如一个广告是不是真的被用户看到。这大大影响广告的大小、初始化和运行的时间、电池的消耗和运行时性能等方面。

AMP 通过 amp-analytics 组件，已经可以实现这些监测代码的功能。他没有依赖而且支持相当多的指标。这意味着广告将会受益于 AMP 页面的 ""加载一次，报告多次"" 的功能，完全消除上述带宽和运行成本。

协调问题的解决

来源: Daniel Stockman, License: CC BY-SA 2.0

基于 AMP 的广告将像所有其他 AMP 资源一样参与到页面布局。这意味着他们自动利用 AMP 的功能，最大限度地减少资源对运行时的性能的影响。

特别是，** AMP 只有在屏幕上可见时才播放动画**。虽然浏览器会在平台级实现这一功能，他们需要在不打破现有的用例的情况下是保守的。 A4A 是全新的，特殊用途的技术，可以精确定位是否需要动画，从而进一步降低CPU的使用率和电池消耗。

AMP 会管理所有的广告，确保它们不会对页面上的主要内容产生负面影响。 基于 A4A 的动画在监测到当前设备不能做到每秒60帧的帧率时，会对动画做节流，虽然帧数会降低，但是帧率会更稳定，动画效果会更流畅。同样的，如果 AMP 不能稳定帧率，就会把动画关闭。这确保了每个设备都能达到他最佳的用户体验，并且广告不会对包括滚动在内的用户体验造成负面影响。

跨平台

作为 AMP 项目的一部分，A4A 是厂商中立的。虽然我们仍处在早期试验和实施阶段，该技术旨在支持所有的广告网络。如果你是做广告技术的，来 GitHub 冒个泡。我们相信A4A跨出了用户体验的巨大一步，希望他在互联网广告行业广泛采用。

这是我们正在做的广告

目前还很早期，我们才刚开探索怎么使用 A4A。

未来

• 广告可以静态分析，确保是安全而且可用，

• 可以使用公用的功能来显著降低带宽消耗，

• CPU 只能用在可见的广告上，延长电池寿命，

• 保证主要内容和功能可以保持每秒60帧的顺滑.

我们试着去建立一个用户体验优先的 Web 广告生态系统，参考 AMP 在出版业的成功，A4A 应该也会成功的。

_This post was originally published on Medium _by Malte Ubl, Tech Lead for the AMP Project.