加速移动页面 (AMP):开放还是封闭?

还没有读者喜欢这篇文章。
Different cell phones

Opensource.com

几个月前,Google 宣布了一个新的开源项目,称为 加速移动页面 (AMP),承诺“显著提高移动 Web 的性能”,现在 Google 在 移动搜索结果的顶部展示 AMP 内容。随着 AMP 内容的数量持续增长,越来越多的人开始质疑 AMP 是否有利于开放网络,以及 AMP 是否是一个封闭的信息孤岛

AMP 项目最近一直占据我的思绪:我不仅是 Drupal 的新 AMP 模块的开发人员之一,我还是一个 直言不讳的自由软件倡导者和 Hacking Culture 的主持人,该节目深入采访开源和自由软件倡导者。我必须决定 AMP 是否代表了开放网络的积极变化。虽然我认为评估 AMP 的全部影响还为时过早,但我已经得出结论,这是一个朝着正确方向迈进的举动。

一个不容置疑的事实是,AMP 内容加载速度很快。 AMP 内容的平均加载速度是原来的 四倍,并且使用的 数据量减少了 10 倍 比非 AMP 页面。我们都希望在我们的设备上加载内容时看到这样的统计数据。

我们还应该承认,这不再仅仅是“Google 的加速移动页面项目”。 Google 创建了 AMP,但该公司已说服许多其他发布商和平台参与该项目。 目前的 合作伙伴 包括 LinkedIn、Medium、Brightcove、Vine、Pinterest、纽约时报、Vox Media、华盛顿邮报、卫报、BBC 和华尔街日报等。

与其他解决移动 Web 速度慢问题的方案不同,AMP 是一个 开源项目。该项目的代码 位于 GitHub 上。这是一个活跃的社区,有很多 开放问题,到目前为止,包括来自 100 多人 的贡献。该项目提供了关于 治理的明确信息,以及一个 行为准则(基于 Hoodie 社区准则),该准则将该项目描述为一个“积极、不断增长的项目和社区”,旨在提供一个“对每个人都安全的环境”。

该项目不仅仅是开源,还力求成为一个开放标准。 尽管以前尝试为移动设备构建网站(“m.”网站,有人记得吗?)的目标相似,但它们没有提供 AMP 所规定的那种严格规则。 任何人都可以实施 AMP 标准,并且已经被 PinterestTwitterGoogle 等公司使用。 因为它是一个标准,AMP HTML 可以在任何浏览器或应用程序中使用,使其成为比任何其他建议的计划(尤其是 Apple 和 Facebook 提出的计划)更“开放”的解决方案。

虽然 AMP 主要侧重于最大化速度,但它为发布商提供了其他专有解决方案所不具备的灵活性。 与 RSS 或 Apple News 等解决方案不同,在这些解决方案中,第三方(例如 Facebook 或 Apple 的设计师)控制内容的展示形式,而发布商可以决定其 AMP 内容的外观和风格,并且这些发布商可以完全控制页面上的元素。 在 Poynter 对 AMP 的分析中,发布商“可以控制他们的产品,他们可以控制提供产品。 他们可以控制产品的商业模式。 实际上,他们可以控制自己的命运。” 因此,我不同意将 AMP 描述为另一个封闭的信息孤岛

Google 的 AMP 缓存服务器存储 AMP 页面的缓存版本并在搜索结果中提供它们,这一事实与其他 CDN 缓存这些页面并没有什么不同。 像 Akamai 这样的公司对使用其 CDN 收取大量费用,而 Google 免费提供 AMP 缓存。 Google 的 AMP 缓存不仅加快了搜索结果的加载时间,还允许访问者 在轮播中滑动浏览 AMP 结果,只需轻轻一拂。 Google 的搜索结果轮播只是该标准的一种实现,发布商仍然可以控制。 Wired 杂志中的指责,即“AMP 通过改变 Web 的工作方式来加速 Web”让人感觉空洞,除非作者将 Google 的搜索结果等同于 Web。

AMP 对于像 Opensource.com 这样的网站意味着什么? Opensource.com 恰好是一个 Drupal 网站。 借助 新的 Drupal AMP 模块,为 Opensource.com 提供 AMP 的障碍大大减少了。 添加 AMP 将为 Opensource.com 文章(如本文)提供出现在 Google 移动搜索结果的顶部 的机会,并允许 AMP 内容在 社交 媒体 上更快地加载。 如果其他平台实施 AMP 标准,这些文章看起来会相同,加载速度也会更快。 所有这些都不会使 Opensource.com 依赖于 AMP,因为 AMP 只是作为来自同一服务器的非 AMP 内容的补充。 在这方面,AMP 内容让我想起了 David Weinberger 的博客,他以三种样式(“样式 1”、“样式 2”和“默认”)提供该博客,并允许访问者更改它。

我还没有准备好将 AMP 奉为 Web 的救世主,但我欣赏它背后的理念。 AMP 并不是要喂饱饥饿的人或为无家可归者提供住所,它只是让网页在手机上加载得更快。 如果不能教世界如何构建快速加载且在加载时不会跳动的网页,我看不到任何更好的加速移动 Web 的提议。 本质上,AMP 迫使人们构建快速加载的网站。 AMP 可能不是 copyleft 许可的强烈倡导者(AMP 是 Apache License 2.0)或不信任 Google 的人(在 AMP 项目治理文档中唯一提到的公司)的理想解决方案,但 AMP 感觉是最开放的解决方案。

我仍然对其他意见持开放态度。 如果不是 AMP,那是什么?

标签
User profile image.
Matthew Tift 是一位瑜伽老师和开发人员。 他是 Lullabot 的首席工程师,也是 Hacking Culture 的主持人,该节目探索有助于福祉的实践和技术。 Matthew 拥有威斯康星大学麦迪逊分校的音乐学博士学位。

3 条评论

非常有趣的文章。 感谢分享。

我对 AMP 的开源部分没有问题。 他们非常开放,并且确实认为围绕它正在建立一种伟大的社区精神和支持。

但是,我对 Google 在 SERP 中优先展示 AMP 页面存在疑问。 它迫使你使用这项技术。 我的网站速度很快,但现在我必须使用 AMP 来确保排名,尽管如此? 如果 Bing 将用 .NET 编写的结果置于其结果页面的更高位置,你会有什么感觉?

此外,编写 AMP 页面需要付出努力。 你必须内联 CSS,将页面剥离回几乎只有内容,并提供图像的高度和宽度。 如果任何网站这样做(他们必须为 AMP 这样做),它们都会很快。 那么为什么有必要在顶部添加额外的限制? 虽然他们正在添加的额外组件正在提供更多的激励 - 它几乎正在成为一个 Web 框架。

这是一个解决问题的有趣方案,但我仍然存在担忧。

如果感兴趣,可以在这里进一步阅读博客
https://www.tunetheweb.com/blog/do-we-really-need-google-amp/
https://www.tunetheweb.com/blog/implementing-accelerated-mobile-pages/

感谢 Matthew Tift 的这篇文章。 你回答了我一些关于 AMP 的问题!

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 授权。
© . All rights reserved.