乐趣区

关于javascript:如何移除你项目中99的JS代码

大家好,我卡颂。

在前不久的 WWC22 中,builder.io的 CTO miško hevery(同时也是 Angular/AngularJS 的发明者)发表了一段充斥想象力的演讲。

在演讲中,他介绍了一款全栈 SSR 框架 —— Qwik,这款框架号称 能帮你移除我的项目中 99% 的 JS 代码

他是如何办到的,本文咱们来介绍下Qwik

欢送退出人类高质量前端框架群,带飞

性能差?码农不背锅

先来聊聊 Qwik 诞生的背景。

对于很多 2C web 利用(比方电商),首屏性能指标关乎用户留存,用户留存关乎赚多少钱。

所以,利用关上速度会影响赚钱。

然而,对于前端开发者,首屏性能指标并不容易优化。究其原因,并不是开发者不够致力。

让咱们来看两个性能指标。

如何优化 FCP

FCP(First Contentful Paint,首次内容绘制)测量 页面从开始加载到页面内容的任何局部在屏幕上实现渲染的工夫

以后 web 利用广泛采纳 前端框架 开发,这意味着会引入大量 JS 代码(框架自身代码、第三方依赖包的代码 ……)

HTML 开始解析到最终页面渲染,两头还要经验:

  1. 下载框架 JS 代码
  2. 执行框架 JS 代码
  3. 由框架实现页面渲染

这就导致 FCP 指标的降落。

为了优化 FCP,框架作者提出了SSR(Server Side Render,服务端渲染),在服务端生成首屏所需HTML,这就为FCP 省去了上述三个步骤所需工夫。

然而,TTI指标依然须要优化。

如何优化 TTI

TTI(Time to Interactive,用户可交互工夫)测量 页面变得齐全可交互所需工夫

次要掂量的是从下述 1 到 3 所需工夫:

  1. 首先掂量 FCP 工夫
  2. 为页面中的元素绑定事件
  3. 对元素产生交互后,事件响应工夫在 50ms 内

应用 SSR 后,尽管 FCP 升高,然而框架 hydrate(注水,即框架使页面可能响应交互)所需工夫对TTI 会有影响。

可见,性能瓶颈的源头在 JS 代码。

React18Selective Hydration 通过 让用户交互的局部优先 hydrate来优化 TTI 指标。

然而,Qwik更极其,他的指标是 —— 干掉所有不必要的 JS 耗时,这里的耗时包含两局部:

  • JS作为动态资源加载的耗时
  • JS运行时的耗时

超超超细粒度 hydrate

如果说传统 SSR 的粒度是 整个页面

那么 React18Selective Hydration的粒度是 产生交互的组件

那么 Qwik 的粒度是 组件中的某个办法

举个例子,上面是 HelloWorld 组件(能够发现,Qwik采纳相似 React 的语法):

对应页面渲染成果:

关上浏览器 Network 面板,这个页面会有多少 JS 申请呢?

因为这是个动态的组件,没有逻辑,所以答案是:没有 JS 申请。

再来看看经典的计数器 Counter 组件,相比 HelloWorld,减少了 点击按钮状态变动的逻辑,代码如下:

对应页面渲染成果:

关上浏览器 Network 面板,这个页面会有多少 JS 申请呢?

答案还是:没有 JS 申请。

留神这两个组件的代码中,定义组件应用的是 component$,有个$ 符号。

Counter 中,onClick$回调也有个 $ 符号。

Qwik 中,后缀带 $ 的函数都是 懒加载 的。

hydrate的粒度有多细,就取决于 $ 定义的多细。

比方在 Counter 中,onClick$$ 后缀,那么点击回调是懒加载的,所以首屏渲染不会蕴含 点击后的逻辑 对应的 JS 代码。

在点击按钮后,会发动 2 个 JS 申请,第一个申请返回的是 点击后的逻辑

第 2 个 JS 申请返回的是 组件从新 render 的逻辑

这两段代码执行后,Counter变为 1。

审查元素会发现,点击前,button on:click属性中保留了 逻辑所在的地址

点击后,会从对应地址下载 JS 代码,执行对应逻辑。

从优良到极致

是不是感觉曾经优化到极致了?还没。

对于一些在页面中长期存在的、须要 JS 驱动的模块(比方轮播图),在模块展示前,模块对应 JS不是必要的。

比方上面这个钟的示例,页面中有个长长的列表,超过一屏高度,在列表底部有个钟。

上面是列表滚到底的样子:

Clock 组件的 useClientEffect$ 中定义 时钟指针摆动的逻辑

Qwik中也存在相似 ReactuseEffect,但在 Qwik 中这个 Hook 能够在服务端 / 客户端执行。

为了辨别,useClientEffect 只在客户端执行的 useEffect

加了 $ 后缀,代表他是 懒加载的

具体成果是:当页面滚动到钟露出之前,useClientEffect$对应 JS 代码都不会申请。

当钟露出后,会发动两个 JS 资源申请:

  • useClientEffect的逻辑
  • Clock组件从新渲染的逻辑

如果审查元素,在钟露出前,指针对应元素都是不动的:

当钟露出,加载并执行 JS 代码后,才开始执行动效:

对数据 hydrate

在传统 SSR 中,数据其实被初始化了两次:

  1. 页面首次渲染,此时服务端导出的 HTML 中曾经携带了首屏渲染的数据
  2. 框架 hydrate 后,数据再转化为框架内的状态供后续渲染

Qwik 中,页面初始化时会存在 typeqwik/jsonscript 标签用于存储 以后页面中被激活的状态对应数据

什么叫 被激活 呢?

比方,上面是一篇文章的评论区,这是首屏渲染后的样子:

这些评论数据会呈现在 qwik/json 保留的数据中么?

不会,因为没有交互激活他们。

咱们发现,有一条评论被折叠了,点击后会开展这条评论:

点击这个行为会申请:

  • 点击逻辑对应的 JS 代码
  • 这条评论对应组件的从新渲染逻辑

此时,评论数据才会呈现在 qwik/json 中,因为点击交互激活了这个数据。

所以在 Qwik 中,如无必要,数据不会被初始化两次。

HTML中存在 未激活的数据 qwik/jsonscript标签中保留了 激活的数据,这个个性会带来一个很有意思的成果:

复制调试工具中 Elements 面板下的 DOM 构造 后,再在新页面中粘贴,就能复现 页面以后的交互状态(比方,输入框内依然保留之前输出的内容):

换做其余框架,只能复现 页面初始时的状态

交互时再申请 JS 不会卡么?

有同学可能会问,如果在网络不好的状况下,交互时再申请 JS 代码不会让交互变得卡顿么?

Qwik容许你指定 哪些组件可能是用户大概率会操作的(比方电商利用中,购物车按钮被点击的概率高)。

这些组件逻辑对应 JS 代码会prefetch,在不影响首屏渲染的前提下被预申请:

并且这些组件 prefetch 的程序是能够调整的。

这意味着能够追踪用户行为,以 用户交互的频率 为指标,作为组件 prefetch 优先级的根据,启发式晋升利用性能。

这才是真正的 以用户为导向 的性能优化,而且是全自动的。

总结

当今是个前端框架百花齐放的时代,不同框架都在寻找本人独特的卖点。

Qwik的卖点是:将 JS 代码的拆分从常见的 编译时 (比方webpack 分块)、运行时 (比方dynamic import),变为 交互时

JS 代码的极致拆分,只为达到一个目标 —— 在首屏渲染时,移除你我的项目中 99% 的 JS 代码。

你感觉这波操作怎么样?

退出移动版