TL;DR：我们正在对 AMP 在 Google 搜索等平台上的工作方式进行更改，这将使链接页面显示在发布者的网址下，而不是 google.com/amp 网址空间下，同时保持 AMP Cache 服务的性能和隐私优势。
当我们首次在 Google 搜索中推出 AMP 时，我们做出了一个重大的权衡：为了实现用户告诉我们他们想要的即时加载的用户体验，我们需要在用户点击之前开始加载页面。正如我们在去年的一篇深入博客文章中详细介绍的那样，出于隐私原因，基本上不可能从发布者的服务器加载页面。在用户主动访问他们的页面之前，发布者不应该知道用户对什么感兴趣。相反，AMP 页面是从 Google AMP 缓存加载的，但这种行为会导致网址更改为包含 google.com/amp/ URL 前缀。
我们自己也是有意义的网址的忠实粉丝，并且认识到这不是理想的。你们中的许多人同意。这当然是我们听到的关于 AMP 的第一反馈。我们力求确保这些网址尽可能少地出现在各个地方。随着时间的推移，我们在 Android 和 iOS 上的 Google 搜索原生应用开始默认显示发布者网址，我们与浏览器供应商合作，尽可能分享文章的发布者网址。然而，我们无法修复在最重要的地方（网络和浏览器 URL 栏）的网址状态。
我们进行了长达数月的努力，今天我们终于有信心找到解决方案：正如 W3C TAG 所推荐，我们打算基于新兴的 Web Packaging 标准实现新的 AMP 缓存服务版本。基于此 Web 标准，Google 搜索中的 AMP 导航可以利用保护隐私的预加载和 Google 服务器的性能，同时 URL 保持发布者预期，并且 Web 的主要安全上下文（即来源）保持不变。我们基于 Chrome 浏览器和 Google 搜索的实验版本构建了一个原型，以确保它确实在实际用例中提供所需的 UX 和性能。此步骤让我们相信，我们找到了解决此难题的有希望的解决方案，并且它很快将成为用户在 Web 上遇到 AMP 内容的方式。
下一步是朝着在 Web 浏览器和 Google AMP 缓存中完全实现新的 Web 标准迈进。我们的目标是让尽可能多的浏览器可以使用 Web Packaging（毕竟，Web Packaging 除了 AMP 之外还有激动人心的用例，例如离线页面、ES6 模块加载和资源捆绑）。特别是，我们打算扩展 在 WebKit 上的现有工作以包括 Web Packaging 的实现，并且 Google Chrome 团队的实现已经开始。
我们对这项工作的开展感到非常兴奋，我们预计这些更改将在 2018 年下半年首次惠及用户。感谢您对这件事的所有反馈，我们将在本博客中随时向您更新进度！
马尔特·乌布尔，Google AMP 项目的技术负责人。