AMP

AMP URL 中有什么？

未分类

以下内容由 Google 搜索软件工程师 Alex Fischer 发布在 Google 开发者博客 上。

简而言之：今天，我们向 Google 搜索中的 AMP 集成添加了一项功能，允许用户访问、复制和分享 AMP 文档的规范 URL。但在深入了解新闻之前，让我们退一步，详细阐述 AMP 世界中的 URL 以及它们与 AMP 的速度优势之间的关系。

URL 中有什么？在网络上，URL 和 源在某种程度上代表了内容的可信度和所有权。当您阅读纽约时报的文章时，快速浏览一下 URL，您就会相信您所读的内容代表了纽约时报的声音。归属、品牌和所有权都很明确。

不同移动应用中的近期产品发布和 Google 搜索中的 AMP的近期发布使这一界限变得有些模糊。在本文中，我将首先尝试解释我们做出的一些技术决策背后的原因，并了解现有的不同类型的 AMP URL。然后，我将概述我们正在做出的更改，以解决与 URL 相关的担忧。

首先，AMP 文档有三种不同类型的 URL

  • 原始 URL：以 AMP 格式编写的发布商文档
    http://www.example.com/amp/doc.html
  • AMP 缓存 URL：通过 AMP 缓存提供的文档（例如，Google 提供的所有 AMP 都通过 Google AMP 缓存 提供）。大多数用户永远不会看到此 URL。
    https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html
  • Google AMP 查看器 URL：在 AMP 查看器中显示的文档（例如，在搜索结果页面上呈现时）。
    https://www.google.com/amp/www.example.com/amp.doc.html

image1

尽管三个不同的 URL 具有不同的来源，但对于本质上相同的内容来说可能会令人困惑，但存在这几个不同的 URL 的主要原因有两个：缓存和预渲染。两者都是 AMP 速度的重要因素，但需要新的 URL，我将详细说明原因。

AMP 缓存 URL

让我们从 AMP 缓存 URL 开始。Google AMP 开发者倡导者 Paul Bakaus 有一篇优秀的文章，描述了为什么存在 AMP 缓存。Paul 的文章详细描述了 AMP 缓存的好处，但并没有完全回答为什么它们需要新 URL 的问题。这个问题的答案归结为 AMP 的一项设计原则：构建以方便采用。AMP 试图大规模解决移动网络的一些问题，因此其组件必须对每个人都易于使用。

有很多选项可以获得验证、接近用户以及 AMP 缓存提供的其他好处。然而，对于一个小型网站来说，它不管理自己的 DNS 条目，没有工程资源通过复杂的 API 推送内容，或者无法支付内容分发网络，很多这些技术都是不可访问的。

出于这个原因，Google AMP 缓存通过简单的 URL“转换”来工作。网站管理员只需在某个 URL 上提供其内容，Google AMP 缓存就可以通过 Google 的全球基础设施缓存和提供内容，通过一个新的 URL 来镜像和转换原始内容。就这么简单。另一方面，使用原始 URL 利用 AMP 缓存将要求网站管理员修改其 DNS 记录或重新配置其名称服务器。虽然有些网站确实这样做，但基于 URL 的方法对于绝大多数网站来说更容易使用。

AMP 查看器 URL

在上一个部分中，我们了解了 Google AMP 缓存 URL——指向 AMP 文档的缓存版本的 URL。但是www.google.com/amp URL 呢？为什么需要它们？这些是“AMP 查看器”URL，它们的存在是因为预渲染。

AMP 内置的隐私和资源节约型预渲染支持很少被提及，而且常常被误解。AMP 文档可以在不引发资源获取级联、不占用用户 CPU 和内存、不运行任何隐私敏感分析代码的情况下进行预渲染。无论嵌入式应用程序是移动网页还是原生应用程序，这都适用。然而，对新 URL 的需求主要来自移动网络实现，因此我使用 Google 的移动搜索结果页面 (SERP) 作为说明性示例。

预渲染如何工作？

当用户执行返回启用 AMP 的结果的 Google 搜索时，其中一些结果会在后台进行预渲染。当用户点击预渲染结果时，AMP 页面会立即加载。

预渲染通过在嵌入页面（搜索结果页面）上加载一个隐藏的 iframe 来工作，其中包含 AMP 页面的内容以及一个附加参数，该参数指示仅预渲染 AMP 文档。处理这些 iframe 生命周期管理的 JavaScript 组件称为“AMP Viewer”。


AMP Viewer 在隐藏的 iFrame 中预渲染 AMP 文档。

用户的浏览器加载文档和 AMP 运行时并开始渲染 AMP 页面。由于所有其他资源（例如图像和嵌入）都由 AMP 运行时管理，因此此时不会加载其他任何内容。AMP 运行时可能会决定获取一些资源，但它将以资源和隐私敏感的方式进行。

当用户点击结果时，AMP Viewer 所要做的就是显示浏览器已经渲染的 iframe，并让 AMP 运行时知道 AMP 文档现在可见。

如您所见，此操作非常便宜——没有涉及到网络活动或对新页面的硬导航。这导致了结果的近乎即时加载体验。

google.com/amp URL 从何而来？

以上所有操作都在用户仍在原始页面（在我们的示例中，即搜索结果页面）时发生。 换句话说，用户没有转到不同的页面；他们只是在同一页面上查看了一个 iframe，因此浏览器不会更改 URL.

我们仍然希望浏览器中的 URL 反映屏幕上显示的页面，并让用户可以轻松链接到该页面。当用户在浏览器中点击刷新时，他们希望显示相同的文档，而不是底层搜索结果页面。因此，AMP 查看器必须手动更新此 URL。这使用 History API 完成。此 API 允许 AMP Viewer 更新浏览器的 URL 栏，而无需进行硬导航。

问题是浏览器应更新到哪个 URL。理想情况下，这应该是结果本身的 URL（例如，www.example.com/amp/doc.html）；或 AMP 缓存 URL（例如，www-example-com.cdn.ampproject.org/www.example.com/amp/doc.html）。不幸的是，它不能是这两个中的任何一个。History API 的主要限制之一是新 URL 必须与原始 URL 具有相同的来源（参考）。这是由浏览器强制执行的（出于安全原因），但这意味着在 Google 搜索中，此 URL 必须位于www.google.com来源。

我们为什么要显示标题栏？

上一部分解释了 AMP 查看器必须处理的 URL 限制。然而，这些 URL 可能令人困惑和误导。它们可能为网络钓鱼攻击打开大门。如果一个 AMP 页面显示了一个看起来像 Google 的登录页面，并且 URL 栏显示 www.google.com，用户如何知道这个页面实际上不是 Google 的？这就是需要额外归因的地方。

为了提供适当的内容归因，每个 AMP 查看器都必须向用户明确显示他们正在查看的内容来自何处。实现此目的的一种方法是添加一个标题栏，显示页面的“真实”来源。

接下来是什么？

我希望上一部分已经清楚地说明了为什么存在这些不同的 URL，以及为什么每个 AMP 查看器中都需要有一个标题。我们已经听说了您对这种方法和 URL 重要性的看法。那么接下来是什么？正如您所知，我们希望对我们所做的事情进行深思熟虑，并确保我们不会破坏用户对 AMP 页面期望的速度和性能。

自 2016 年 2 月在 Google 搜索中使用 AMP 以来，我们采取了以下步骤：

  • 所有 Google URL（即 Google AMP 缓存 URL 和 Google AMP 查看器 URL）尽可能反映内容的原始来源：
    www.google.com/amp/www.example.com/amp/doc.html
  • 当用户向下滚动页面阅读文档时，AMP 查看器标题栏会隐藏，释放宝贵的屏幕空间。
  • 当用户在查看器不可用的平台上访问 Google AMP 查看器 URL 时，我们会将他们重定向到该文档的规范页面。

除了上述内容外，许多用户都希望能够访问、复制和分享文档的规范 URL。今天，我们将在 Google 搜索的 AMP 查看器页眉中添加一个锚按钮，以支持此功能。此功能允许用户通过长按显示的链接来使用其浏览器的原生分享功能。

在未来几周内，Android Google 应用将在用户点击应用的分享按钮时分享文档的原始 URL。iOS Google 应用上已提供此功能。

最后，我们正在利用即将推出的网络平台 API，以进一步改进此功能。其中一个 API 是 Web Share API，它允许 AMP 查看器调用平台的原生分享流程，并使用原始 URL 而不是 AMP 查看器 URL。

作为 Google，我们致力于为用户和发布商提供尽可能好的 AMP 体验。蓬勃发展的生态系统对我们非常重要，而归因、用户信任和所有权是此生态系统的重要组成部分。我希望这篇博文有助于阐明 AMP 文档的三个 URL 的来源、它们在使 AMP 快速加载中的作用，以及我们为进一步改善 Google 搜索中的 AMP 体验所做的努力。最后，一个生态系统只有在您的参与下才能蓬勃发展：给我们 反馈 并 参与 AMP。


发布者：Google 搜索软件工程师 Alex Fischer。