2020 年 6 月 26 日更新：自此博客文章上线以来，AMP 已正式从 OpenJS 基金会孵化计划中毕业。请 在此处 查看新闻。
今年夏天是 AMP 的第一行代码编写完成五周年。该项目不断演变，受到网络动态特性、不断变化的用户期望、生态系统中的想法和代码贡献等因素的影响。我们认真听取了出版商和开发者社区的意见，并根据他们的反馈不断迭代 AMP。
在 AMP 社区的支持下，我们一直致力于实现我们的使命，即提供以用户为先的内容格式，并在此过程中帮助支持网络上的每个出版商、商家和广告商的成功。凭借五年的经验和获得的众多见解，我们回顾了该项目的起源、沿途吸取的教训以及 AMP 的未来可能是什么。
开端：快速变化的网络和偶然的对话
在我成为 Google 的软件工程师之前，网络就已经开始为其未来而苦苦挣扎，而《连线》在其“网络已死”专题中对此进行了著名的描述。如今，网络已经演变并继续蓬勃发展，但在 2010 年，这篇文章确实包含了一定的真理。随着移动设备、应用程序和社交平台的兴起，许多行业，尤其是新闻出版商，都看到了消费者行为的巨大转变，而网络却在苦苦挣扎。
网络出版商在提供引人入胜的移动体验方面面临着难以置信的挑战——当时，移动网页的平均打开时间为 19 秒。出版商不仅要学会如何为移动设备设计内容，还要学会如何发展他们的商业模式。社交平台的同步兴起增加了对出版商时间的需求，因为他们的重点分散在为网络和社交媒体开发上。
为了应对这些挑战和移动设备上不断变化的用户期望，新闻和社交媒体平台上出现了新的内容消费格式。这些格式为用户提供了一种更快速的方式来获取新闻，并提供一致的用户体验，但这些格式仅限于它们开发的平台。它们还向出版商提出了与商业模式控制和品牌相关的疑问。
2015 年春季，来自世界各地的数百名记者和技术人员齐聚赫尔辛基参加 Newsgeist Europe，这是 Google 举办的一项年度活动，旨在讨论新闻业的未来。Newsgeist 沿袭传统，与会者提出了多个议题，其中一个提出了以下问题：“Google 可以为新闻做什么？” 围绕新专有新闻和社交内容格式展开的此次会议重点关注内容分发，部分原因是为了应对出版商日益增长的 UX 挑战。
在讨论期间，新闻出版商表达了对分布式内容采用新的潜在开源方法的需求；最初将其称为“便携式内容单元”。该想法是，此“单元”可以帮助满足通过精良的用户体验联合内容的更多机会，同时保持出版商对商业模式、品牌和展示的控制。出版商还表示，新的开源方法可能会鼓励围绕单一格式进行更大程度的协作。
在 Newsgeist 之后不久，Google 搜索的工程副总裁 David Besbris 开始组建一个产品团队，我加入了该团队，我们开始就构建新的分布式内容格式展开早期讨论，我们正式开始将其称为便携式内容单元 (PCU)。早期，我们的团队专注于与出版商接触，以便深入了解其行业的需要。我们一直问自己最初引发这些对话的问题：“Google 可以为新闻做什么？”
我们与出版商的早期对话始于我们的数字新闻计划产品工作组，这让我们相信，既能解决移动体验设计又能解决性能的整体解决方案对于面临新的内容分发机会不断增长的格局的出版商来说可能是一个有力的选择。我们通过与世界各地的出版商进行讨论和规划会议，在全球范围内扩展了这种协作。有了这一认识，我们有了使命。我们看到了新闻行业提高移动设备上的网络性能至关重要，我们开始努力使 PCU 成为现实。
该项目的早期设计由三个问题驱动
- 我们如何让网络在移动设备上与专有和原生新闻消费体验竞争？
- 如何在确保发布者的品牌自由度和获利能力的同时做到这一点？
- 我们如何不仅让这些事情成为可能，而且真正确保广泛的发布者取得成功？
最后一个问题是真正的关键：在网络上实现出色的用户体验一直是可能的，只是分布不均。这种新方法将实现优秀体验的民主化：无论发布者的规模、技术能力或预算如何，都能让他们发布高性能的网页，与网络上的最佳网页相媲美。
我很幸运，在我之前在 Google 的项目中，我的工作重点是让工程师更容易取得出色成果，而无需成为网络开发专家，这与上面的问题 (3) 紧密相关。这意味着我们可以将为这项先前工作开发的内部软件用作第一个 PCU 验证器的基础。关键的见解是，如果软件可以告诉人们在犯错时该怎么做，那么人们就不需要成为专家来实现既定成果。
我们的团队与少数发布者会面以测试新格式，还有几十个发布者分享了他们的内容提要，以便我们可以直接代表他们进行实验。我们将内部 PCU 名称更改为AMP 项目，或当时所称的加速移动页面项目。经过无数小时的发布者反馈周期，我们在 2015 年 10 月宣布了我们的第一个开发者预览版，有 30 多家发布者参与，这强调了我们的信念，即这项工作的成功不在于一个人的领导，而在于许多人的领导。
根据发布者的反馈，AMP 被设计为
- 为发布者保留最大的品牌和用户体验灵活性，
- 支持发布者的商业模式，不受平台的干扰，
- 维持发布者对数据的访问，
- 同时匹配封闭平台的用户体验，并引入创新功能，例如保护隐私的即时加载内容。
我们使 AMP 开源，因为我们希望与发布商和网络生态系统建立一个反馈循环。替代内容交付框架为发布商提供了一种快速交付内容并提供一致用户体验的方式，但它们受到限制，因为它们各自仅适用于一个平台。我们的目标是通过改善我们合作的发布商的内容体验来整体改善网络。AMP 的最早版本专注于让发布商能够创建主要包含文本、图像和视频的静态内容页面。由于广告在确定性能方面发挥着重要作用，因此开发者预览提供了基本的广告支持，并计划快速扩展以适应更复杂的广告设置和额外的获利模式。
早期：倾听、学习和重复
在发布 AMP 的开发者预览后，我们很高兴看到来自世界各地的数千名发布商对该计划表示兴趣。虽然我们对这一回应感到鼓舞，但我们也知道 AMP 还有很长的路要走。开发一个与现有发布商业务模式兼容的新框架意味着要持续了解发布商的需求，包括花费大量时间来了解分析设置、广告策略和付费墙实施。
随着对该项目的兴趣不断增长，我们建立了定期工作组，发布商可以在其中与 Google 产品经理和工程师合作，开发一些 AMP 最需要的功能，例如 amp-analytics 或 付费墙支持。除了发布商之外，我们还需要与广告技术和分析提供商合作，因为它们与发布商的在线业务模式有着内在联系。随着时间的推移，越来越多的广告网络增加了对 AMP 的支持：如今，240 个不同的广告网络和 80 个分析提供商支持 AMP。
在 AMP 野生的前几年里，我们继续与网络生态系统中涉及的各方合作，并在解决 AMP 的一些最大差距方面取得了重大进展。2016 年，我们宣布了 AMP For Ads 项目，该项目解决了我们从发布商那里听到的一些有关其网页上的广告性能缓慢的反馈。我们同年推出了对 实时博客 的支持，这满足了早期发布商要求 AMP 支持更动态的内容体验的关键要求。
批评如何使 AMP 变得更好
虽然我们在最初几年致力于 AMP 工作时取得了巨大进展，但这一进展并非没有受到批评。这些批评主要集中在两个方面：对 AMP URL 及其对发布商流量的潜在影响的担忧，以及发布商有资格在 Google 搜索中的头条新闻功能中展示的 AMP 要求。虽然我们可能在第一次尝试时并没有让 AMP 变得完美无缺，但我们始终致力于使用可用工具为网络提供最佳服务，并与发布商和用户紧密而勤奋地合作，让 AMP 变得更好。
URL 挑战很复杂。我们希望在网络上实现保护隐私的即时加载，并且基于当时可用的网络平台状态，我们使用了基于 iframe 的加载，这导致了次优的 google.com/amp/www.publisher.com/ 形状的 URL。我们很想在不更改 URL 的情况下实现相同的用户体验，但与大型软件项目常见的情况一样，我们面临着权衡，在这种情况下，权衡的是出色的 UX 和不可取的 URL 格式。
为了解决这个问题，我们迅速与浏览器供应商联系，以确保从 AMP 体验中共享的 URL 能够共享文档的规范 URL。虽然这并没有从根本上解决问题，但它为 URL 的一个核心用例提供了一个很好的解决方案：当用户共享 AMP 文档时，它将始终显示发布商 URL。与此同时，我们寻找一个长期解决方案，并与网络标准社区紧密合作。这项工作最终形成了一项称为已签名交换的技术，该技术于 2019 年 4 月在 Google 搜索中为 AMP 推出，在发布商 URL 下提供保护隐私的即时加载。
围绕 AMP 的另一个批评点是，它是一项参与 Google 搜索中的头条新闻轮播功能的必需技术。头条新闻旨在为用户提供与其他快速消费、以 UX 为重点的格式同样引人注目的新闻体验。我们预计用户会参与更多新闻文章，事实也的确如此。随着时间的推移，我们从开发人员那里得知，他们希望除了 AMP 之外还有其他选择来参与此功能，因此在 2018 年，我们着手通过为我们在应用程序层构建的内容建立网络标准，将我们从 AMP 学到的一切带到网络的其他部分。这项工作最终促成了 Google 最近围绕页面体验信号的公告，该公告提供了一条让所有网络内容都有资格包含在头条新闻轮播中的途径。
治理变更
在最初的两年里，AMP 从一个只有两位贡献者的微型开源项目发展成为一个拥有超过 700 位个人贡献者、在数百万个网站上运行的 10,000 多次提交的更大项目。AMP 的管理方式与当时许多其他开源项目类似，其中大多数决策实际上都是由项目的各个工作组做出的，但最终决策权归我，即项目创建者所有。随着 AMP 的发展，很明显，这种简单的管理模式不再适用于具有如此广泛影响力的开源项目。
受此见解的推动，AMP 项目提出了一项新的管理模式，将对 AMP 进行重大更改的权力移交给了技术指导委员会，其中包括来自已承诺资源来构建 AMP 的其他多家公司的代表。成立了一个独立的咨询委员会，以代表 AMP 的许多其他利益相关者，例如使用 AMP 的发布商和平台。AMP 工作组变得更加正式，专注于 AMP 的某些方面，例如 UI、基础设施、可访问性等，并且这些组在决策过程中拥有明确的投入机制。此提案于 2018 年 11 月生效。
那年晚些时候，AMP 宣布打算转向基金会，这是我们在考察了Node.js和Kubernetes等其他成功开源项目的管理实践后做出的决定。转向基金会为 AMP 等项目提供了独立性，以维护自己的身份、技术重点和产品方向，同时获得关键支持服务，例如营销支持、法律支持等。在考虑了许多选择之后，OpenJS 基金会脱颖而出，成为 AMP 的理想归宿。
吸引开发者：一个全球社区
如果没有 AMP 社区的支持和贡献，AMP 项目不会接近今天的位置。仅仅在第一年，AMP 就看到超过 170 位贡献者将代码推送到 AMP 项目代码库。如今，AMP 拥有超过 1,100 位个人贡献者，其中绝大多数是非 Google 员工。在一年一度的AMP 贡献者峰会上，我们与构成我们开源社区一部分的数百名开发者进行了面对面的会面。今年，随着 AMP 进一步融入 OpenJS 基金会，我们首次参加OpenJS 的协作者峰会。
AMP 团队还借我们一年一度的 AMP 大会 与来自世界各地的开发者和合作伙伴建立了联系。我们曾先后在纽约、阿姆斯特丹和东京等地举办过大会，与数千名 AMP 爱好者面对面交流，或通过我们的直播分享 AMP 未来发展的最新动态。2018 年和 2019 年，我们还通过 AMP 路演 走上街头，让首尔、拉各斯、慕尼黑、雅加达等遥远城市的感兴趣的开发者有机会参加免费的为期一天的会议，帮助他们开始使用 AMP。
遗憾的是，今年由于全球疫情，我们不得不推迟 AMP 大会和 AMP 路演，但我们期待着未来以其他方式与 AMP 社区建立联系。
展望未来：超越 AMP
从 2015 年的一个小型开源项目开始，如今已发展成为一个为近 100 亿个在线页面提供支持的框架。在众多活跃的贡献者的支持下，我们已涉足 网站、广告、故事 和 电子邮件，为开发者打开了大门，让他们能够在网络上创造出美观、高性能的体验。AMP 背后的技术释放了为网络带来大量新功能的潜力，最终帮助确保发布商、商家和广告商能够以新的方式讲故事，以吸引不断变化的用户群。话虽如此，为了让用户更容易访问内容并支持发布商的成功，我们还有很多工作要做，我们对未来的挑战感到兴奋。
如今，AMP 正处于向 OpenJS 基金会过渡的最后阶段，这一过渡始于去年。这一期待已久的举措将继续加强 AMP 的开放治理模式，我们迫不及待地在基金会内进一步拓展我们的视野。要了解 AMP 的未来发展，请在 OpenJS 基金会于 6 月 23 日举办的数字会议 OpenJS World 上收听我的主题演讲。
由 AMP 技术指导委员会成员、谷歌首席工程师 马尔特·乌布尔 发布