微话搭建优质 Web 应用其二：AMP 篇

在 18 年，有做主题为《微话搭建优质 Web 应用》的分享；有从策划、设计、编码、以及如何部署等角度来阐述；本篇，将从速度优化层面（借助 AMP and PWA），来探讨如何让 Web 应用，能在用户端快速触达。

何为 AMP ？

AMP is a web component framework to easily create user-first experiences for the web.（AMP （Accelerated Mobile Pages, 加速移动页面）是一个 Web 组件框架，可以轻松地为 Web 创建用户至上的体验。）

Whether you are a publisher, e-commerce company, storyteller, advertiser or email sender, AMP makes it easy to create great experiences on the web. Use AMP to build websites, stories, ads and emails.

推荐语：AMP 是一个开源的、基于 HTML的网络组件框架，可用于快速创建网站、故事、广告和电子邮件。它由谷歌公司推出、旨在提供了一种直接的方式来创建快速、平滑加载的网页，并将用户体验放在首位。基于 AMP 所创建的内容，开发者在获取受益同时，也会带来极大的商业价值。 ── 出自倾城之链 | AMP - a web component framework to easily create user-first web experiences - amp.dev。

AMP 专注于提高移动设备上网站的页面加载性能和浏览体验。结果，与其他 HTML 页面相比，我们得到了一个只有关键信息的普通页面，没有太多花哨的功能。它从通常的网站或应用程序中消除了 10 次对繁忙的信息搜索者来说不太有用的数据，以在尽可能快的时间内提供信息内容。

谷歌引用“AMP 旨在显着提高移动网络的性能。我们希望具有丰富内容（如视频、动画和图形）的网页与智能广告一起工作，并能即时加载，并希望该技术平台以任何方式独立。”

AMP 产生背景

Web 标准的不断发展，已经逐步解决了一些固有缺陷；但 JavaScript 仍是网络的重要组成部分，但它被前所未有地滥用。最重要的是，JavaScript 是在连接速度较慢且计算能力较低的移动设备上，呈现 Web 内容的主要性能瓶颈；不幸的是，JavaScript 性能问题很复杂，非几言可避之；欲要消除这些性能障碍，需要对站点进行彻底的手动审核。它需要自定义 JavaScript 开发来分析、减少和重构站点上的脚本。对于经常更新的站点，这是一个持续的过程。

不幸的是，许多网络作者并没有意识到这些问题，缺乏技术专长或资源来解决这些问题。今天的每个 Web 工程部门，都需要一位对 JavaScript 有深入了解的 Web 性能专家。但与所有的 Web 开发和 JavaScript 编程相比，Web 性能人群很小，因此劳动力短缺。由于大多数脚本由第三方编写或由第三方库代码组成，因此这不是单个站点可以解决的问题。这是整个网络生态系统的问题。

谷歌检查了混乱的网络性能情况，并寻找解决方案。谷歌认识到它不可能在一天内改变整个网络。在进行一番权衡之后，谷歌意识到“民主”方法（提出可行解决方案的专业知识和手段，引导网站所有者做出优化），无法迅速改变进程。所以谷歌尝试了一种“专制”的方法，即决定放弃所有拖慢网络速度的杂乱 JavaScript 代码；于是 Accelerated Mobile Pages (AMP) 诞生了（于 2015 年下半年，并在 Github 开源：ampproject/amphtml - The AMP web component framework.）。

AMP 的特点

减少页面加载时间并加快网站速度；
增强移动设备中的移动搜索引擎优化和关键字排名；
网站发布商可以完全控制视觉和业务设计；

AMP 的优缺点

AMP 的优点

网页很容易被缓存和加载；
支持所有广告格式；
页面加载时间减少到不到 1 秒，页面加载速度提高了 4 倍；
对于基于内容的网站（如新闻出版商），以及其他垂直内容的网站特别有用；
使用有效 AMP 版本的页面将显示为“热门故事”的预览，位于该主题的移动搜索结果中的其他结果上方。对于拥有 AMP 版本内容的发布商来说，这是一个巨大的机会，可以在首页上轻松看到，并且排名高于未采用该技术的发布商。

AMP 的缺点

由于 AMP HTML 旨在通过减少使用的不相关 JavaScript 和代码，来缩短有用内容的加载时间，因此存在一些视觉限制，例如：

除了现成的 AMP 库外，不允许使用 JavaScript（在最新的优化中，虽然可以通过 amp-script 来解决，但与编写复杂化，尤其是当与主流框架结合时）；
图像是通过延迟加载功能完成的，这意味着它们只有在您向下滚动到它们时，才会加载；
级联样式表的简化版本将是必要的（AMP 只能支持轻量级内容，但这可以缩短加载时间）；

创建 AMP 页面

虽然，AMP 可以与主流框架相结合，在实际操作中，因为 AMP 默认不允许使用 JavaScript，因此相对比较困难；也未寻到较好的脚手架；Next.js 框架倒是对了 AMP 的支持，详情请参见：next/amp。有在曼妙句子项目中，尝试接入 AMP，没有处理好自定义的 JavaScript（Vue 相关）代码，就会报错误："Custom JavaScript is not allowed."。更多相关错误，可以参见 AMP validation errors。

当然，基于 Google Search Console AMP，可以获得AMP 状态报告，该报告可帮助您修正会导致 AMP 网页无法使用 AMP 特有功能显示在 Google 搜索结果中的错误。

AMP 与 PWA 比较

这两种技术齐头并进，有助于减少页面加载时间和等待时间。
在 AMP 减少页面加载时间的同时，PWA 页面会尽快更新，让用户可以在无任何中断的情况下浏览和体验类似移动应用程序的网站。
AMP 可以快速将内容呈现在用户面前，而 PWA通过推送通知、添加到主屏幕按钮等功能实现丰富的用户体验和参与度。
AMP 包含简化的 CSS 和标准化的 JavaScript 和组件，而 PWA 包含 Service Worker、Web App Manifest、App Shell 等。
AMP 特别适用于静态内容繁重的网站，如博客、文章、新闻发布或食谱。PWA 最适合电子商务网站，因为 PWA 使网站的外观和感觉像移动应用程序。建议将它们用于站点和用户之间的安全连接的“https”站点。

合作大于竞争。您可以选择仅使用 AMP 来创建快速但简单的体验。您可以依靠渐进式 Web 应用程序来创建动态但速度较慢的用户体验。或者，您可以通过将两者结合到您的网页设计中来快速开始并保持快速。如今，AMP 与渐进式 Web 应用程序的使用，正变得越来越普遍，开发人员可以通过三种方式同时使用这两种应用程序。

AMP 和 PWA 如何相互关联？

PWA（Progressive Web Apps）和 AMP 页面，可以很好地协同工作。事实上，在许多情况下，它们以一种或另一种方式相辅相成。您可以从以下几个角度来了解：：

为您的 AMP 页面启用 PWA 功能；
创建从 AMP 到 PWA的引人入胜的超快速用户旅程；
使用 AMP 的强大功能简化您的 PWA；

AMP 如何工作？

Accelerated Mobile Pages 类似于任何其他 HTML 网页，但具有一组有限的允许技术功能，这些功能由开放源代码 AMP 规范定义和管理。与所有网页相同，Accelerated Mobile Pages 将在任何现代浏览器或应用 WebView 中加载。

AMP 文件利用各种技术和架构方法，优先考虑速度，为用户提供更快体验。AMP 开发者可以使用不断增长的丰富网络组件库，嵌入视频和社交帖子等富媒体对象、展示广告或收集分析数据。目标不是使内容的外观和风格同质化，而是在网页之间建立更通用的技术核心，以缩短加载时间。

此外，AMP 文件可在云端缓存，缩短内容到达用户移动设备的时间。通过 AMP 格式，内容制作者将 AMP 文件中的内容提供给第三方缓存。在这种类型的框架下，发布商和广告客户仍然控制内容，但平台可以轻松缓存或镜像内容，实现向用户的最佳传输速度。Google 已经免费提供 Google AMP Cache，并且所有 AMP 都将被 Google AMP Cache 缓存。其他公司也可以建立自己的 AMP 缓存。

综上所述，目标在于将有限的技术功能与围绕缓存构建的分发系统相结合，从而提高网页性能并推动受众发展。更多疑问，可参考 AMP Overview。

给快应用带来哪些启示？

在「发散」之前，先分享一则上个月新闻（2022.09）：Adobe 公司宣布，200 亿美元收购设计软件 Figma ：一款数字设计和原型制作工具，面向专业用户，于 2016 年问世；它有一个强力的竞争对手—— Sketch （原生应用），两者功能差不多；直到 2019 年，Sketch 的估值还超过 Figma。Figma 为什么赢了 Sketch？

Figma 并没有采用 JavaScript 编写，而是基于 Rust ，再编译成浏览器能理解的 WebAssembly 字节码格式，从而达到接近原生应用的性能。事实上，Figma 是业内 WebAssembly 最强的公司之一。一旦解决浏览器的性能瓶颈，达到能够接近原生应用的体验，Figma 胜出也就毫无悬念。

提及这则新闻，想表达的是，应用开发各平台之间，本就相互借鉴；如 Web 端流行的 Flex 布局、 Grid 布局、MVVM 框架等，后来的 Flutter 、 Swift-UI 、小程序都有所参考。OS 系统如果支持 WebAssembly（基于堆栈的虚拟机的二进制指令格式），便可以让你用任何你熟悉的编程语言开发「快应用」（如： Rust 、 Go ），而不局限于 JavaScript；如此一来，能享受很多有点：高效性能、低成本存储等。

发散点其一： Google AMP Cache 理念颇值参考；它是是一个经过验证的 AMP 文档的缓存网页，可供任何人使用。Google 产品（包括 Google 搜索）可从缓存中提供有效的 AMP 文档及其资源，以便在移动网站上提供快速的用户体验。

快应用在首次启动时候，经历了复杂的过程：RPK 下载、解压、签名校验、快应用引擎加载、v8 引擎解析出 DOM，经 j2v8 或其他方式，交给快应用引擎渲染出最终结果；预渲染（PreRender），是前端常见优化性能方案（OS 在构建时也做了类似处理）。如果参考 APM Cache 理念，在服务器端对合乎场景的应用，做预渲染并进行缓存，即能省却链路上几个步骤，从理论上来讲，可进一步优化首次启动速度（这对 RTOS 设备具有一定积极意义）。

发散点其二： Qwik 、一个 HTML 优先框架；它的设计是为了实现最快的页面加载时间，通过提供纯 HTML 和接近 0 的JavaScript，使你的页面成为互动的，无论你的网站或应用程序有多复杂。它通过 HTML 的可恢复性和超细粒度的代码加载，来实现这一目标。

Qwik 的目标是：干掉所有不必要的 JS 耗时（静态资源加载的耗时、以及 JS 运行时的耗时），从而快速实现网页可交互。如果说传统 SSR 的粒度是「整个页面」，SPA 的粒度在于「组件和页面」，那么 Qwik 的粒度则到了「组件中的某个方法」，这就导致在交互时再请求额外 JS。当然，Qwik 允许你指定「那些可能是用户大概率会操作的组件」，些组件逻辑对应 JS 代码会 prefetch，在不影响首屏渲染的前提下被预请求。

对于 RTOS 手表应用来讲，这个理念很值得借鉴。其存储空间较小，复杂型应用如果完整安装，层次较深页面、或使用频率较低的应用，其相关代码，很可能用户不会访问；如能基于 Qwik 这种理念，用户需要之时，再去获取；考虑好边界可能存在的问题，从理论上来说，可以为设备带来两点好处：提升性能、降低存储。

以上，仅是从 Web 领域视角，分享些应用优化的思想/理念；若觉欠妥，欢请雅正。