从 AMP 中汲取经验教训，回馈整个网络的一年

2020 年 5 月 28 日更新：相关 Google 搜索公告

2018 年 3 月，我们撰写了一篇博文，讲述了我们为填补网络平台的空白而将从 AMP 中学到的内容贡献给所有网络开发人员所做的努力。在这项工作中，我们与 Google Chrome 团队、Igalia（他们帮助我们进行 WebKit 中的实施工作）以及更广泛的网络标准社区展开了合作。我们还从社区中学到了很多东西，并且看到了很多令人兴奋的工作，我们迫不及待地想要应用这些工作。以下是关于这项工作的进展情况的更新。

我们的工作重点是将 AMP 在应用程序层实现的好处带到整个网络平台（AMP 或其他平台）。

• 衡量性能和用户体验：让客观衡量高负载性能和某些 UX 属性（例如在加载时不会发生位移的稳定加载体验）成为可能。
• 保护隐私的即时加载：允许在用户点击之前预加载网络内容，而不会在用户导航到页面之前向页面作者泄露用户对页面的兴趣。
• 导航创新：通过传统点击以外的方式从一个网页导航到另一个网页。例如，通过在轮播中滑动或从一篇文章滚动到另一篇文章。
• 防护措施：为开发团队提供一种机制，以避免使用对 UX 有害的网络平台的某些旧功能。让开发团队能够类似地控制第三方代码的行为。

我们在提炼最初的广泛想法方面取得了重大进展，并与网络社区合作，将这些想法转化为具体的标准提案。这需要做很多工作，所以我们将事情分成一系列帖子，从今天开始讨论衡量性能和用户体验和防护措施。

衡量性能和用户体验

AMP 团队经常被问到：为什么不直接衡量页面是否快速，而要依赖 AMP？我们同意，这是一个好问题。

自 AMP 创建以来，网络空间发生的一个重大变化是，现在有了Chrome 用户体验报告等工具，这些工具理论上提供了一种获取网络上大多数网站的性能数据的方法。然而，进一步研究后我们意识到，现有的指标不足以真正说明网页理想的用户体验属性。

onload 等旧指标并不是用户感知性能的良好代理。页面既可以在onload 触发之前很久就显示为已加载，也可以在onload 触发之后很久才显示为尚未加载。

一种现代指标 首次内容绘制 (FCP) 是当前唯一可用的候选指标，用于大规模衡量感知性能。遗憾的是，虽然良好的用户体验始终具有良好的 FCP，但拥有良好的 FCP 并不足以真正了解页面是否快速。FCP 可能应该被称为首次非完全微不足道的绘制，因为很明显，在 FCP 时，用户在许多情况下不会认为页面已充分呈现。例如，加载指示器将触发 FCP，但用户不会对此阶段感到满意。

出于这些原因，我们投入定义其他指标，以便描绘用户感知性能的更全面图像。目前正在讨论的两个指标是 最大内容绘制 (LCP，名称可能会更改)，它在页面上最大的文本或图像元素绘制时触发，以及 布局稳定性，这是页面加载期间布局稳定性的指标。我们希望这些指标与 首次输入延迟（其标准化程度更高）一起使用，可以让人们从用户的角度合理自信地说页面是否快速且表现良好。

护栏

AMP 引入了 AMP 验证器，以确保文档符合一系列最佳实践，并在不符合时给出有用的错误消息。基于 蒂姆·卡德莱克 和 约阿夫·魏斯 早期关于 内容性能策略理念 的工作，功能策略 的概念通过 与网络社区的讨论 得以发展。它们既提供了一种关闭有害的旧功能（如同步 XHR）的方法，又提供了一种向网站开发团队 报告违反最佳实践（如加载比必要大得多的图像）的方法。

一系列 功能策略 现正处于开发阶段，涵盖网络开发的许多方面。功能策略的一个有趣方面是，虽然广泛的浏览器支持对于强制执行是可取的，但对于仅报告模式（您可以在其中收到有关您网站问题通知），部分浏览器支持通常足以解决所有网络浏览器用户的已识别问题。

总结

这结束了我们关于将从 AMP 中吸取的经验教训贡献给整个网络的系列文章的第一部分。感谢整个网络社区在使这些标准提案步入正轨以及提供极好的反馈方面提供的惊人帮助，使这些提案比我们自己所能做到的好得多！

本系列文章的下一篇文章是保护隐私的即时加载 和导航创新。它们将在未来几天发布到此博客中。

由 AMP 技术指导委员会成员、Google 软件工程师 Malte Ubl 发布