追求极致性能的Qwik

背景：

Builder.io的产品专注于电子商务，而电子商务热爱速度！

感官上提升速度需要考虑的两个维度：FCP和TTI

FCP（First Contentful Paint，首次内容绘制）当浏览器第一次渲染任何文字、图片，以及非空白的 canvas 或 SVG 的时间

产物：SSR

TTI（Time to Interactive，用户可交互时间）用于描述页面何时包含有用的内容，并且主线程何时空闲并且可以自由响应用户交互，包括注册事件处理程序。

产物：Qwik

简介:

Qwik是一个以 DOM 为核心的可恢复 Web 框架，旨在实现最佳的交互时间，专注于可恢复性和代码的细粒度延迟加载的SSR框架。

Qwik在服务器上开始执行，序列化为HTML,发送给客户端。序列化后的HTML中，除了包含qwikloader.js（1kb）以外，不包含任何js的加载及执行。当用户进行交互后，请求下载相应的交互代码，Qwik从服务器停止的地方恢复执行。

目标：

Qwik 的目标是提供即时应用程序，Qwik 通过两个主要策略实现了这一点：

1、尽可能长时间地延迟 JavaScript 的执行和下载。

2、在服务器端序列化应用程序和框架的执行状态，在客户端恢复。

分析：

Qwik 速度快不是因为它使用了聪明的算法，而是因为它的设计方式使得大多数 JavaScript 永远不需要下载或执行。它的速度来自于不做其他框架必须做的事情（例如水合作用-hydration）。

比较：

现有的SSR/SSG 应用在客户端启动时，它需要客户端上的恢复三条信息：

1、侦听器 - 定位事件侦听器并将它们安装在 DOM 节点上以使应用程序具有交互性；

2、组件树 - 构造数据并表现在组件树上。

3、应用程序状态 - 恢复应用程序状态。

这被称为水合作用。当前所有框架都需要此步骤以使应用程序具有交互性。

这个补水过程可以说是很昂贵的，主要因为以下两点：

1、框架必须下载与当前页面相关的所有组件代码。

2、框架必须执行与页面上的组件关联的模板，以重建侦听器位置和内部组件树。

而Qwik则不同，Qwik提出Resumable（可恢复）的概念，启动时则不需要这个补水的过程，也就大大缩减了客户端的启动时间。

0

Resumable：

指服务器暂停执行并在客户端恢复执行，而无需重新构建和下载所有应用程序逻辑。

为了实现这一点，Qwik需要解决3个问题：侦听器、组件树、应用程序状态

侦听器：

现有框架通过下载组件并执行来收集事件侦听器，然后将这些事件侦听器附加到 DOM上。

当前的方法存在以下问题：

1、需要快速下载模板代码。

2、需要立即执行模板代码。

3、需要急切地下载事件处理程序代码。

以上问题，会随着业务越来越复杂，造成代码量越来越大，从而对性能产生影响。

Qwik则通过将事件侦听序列化到 DOM 中+Qwikloader来解决上述问题

<button on:click="./chunk.js#handler_symbol">click me</button>

Qwik 仍然需要收集侦听器信息，但是这一步放到服务器去完成,将其序列化成HTML，以便后续进行恢复。

on:click 属性包含恢复应用程序的所有信息,该属性告诉 Qwikloader 要下载哪个代码块以及从该块中执行函数名。

渲染首屏中，在HTML中会插入侦听器的核心代码Qwikloader，小于 1kb，将在 1ms 内执行，首次渲染只有这一段js，使得首屏速度接近纯HTML页面，也是Qwik页面在 PageSpeed Insights 上得分 将近100 分的原因。

组件树：

现有框架，如果组件边界信息已被破坏