在前不久的WWC22中,builder.io
的CTO 「miško hevery」(同时也是Angular
/AngularJS
的发明者)发表了一段充满想象力的演讲。
![2f16bcd1175544825bb0bd31c5739c1c.png](https://i-blog.csdnimg.cn/blog_migrate/12da9db948cad25fb7f1ca1f8c7dea42.png)
在演讲中,他介绍了一款全栈SSR框架 —— Qwik
,这款框架号称「能帮你移除项目中99%的JS代码」。
![f48f661ccc728402e62264f13e7b10e2.png](https://i-blog.csdnimg.cn/blog_migrate/66384d3dc10255e617f082e9709cb25b.png)
他是如何办到的,本文我们来介绍下Qwik
。
性能差?码农不背锅
先来聊聊Qwik
诞生的背景。
对于很多2C web
应用(比如电商),首屏性能指标关乎用户留存,用户留存关乎赚多少钱。
所以,应用打开速度会影响赚钱。
然而,对于前端开发者,首屏性能指标并不容易优化。究其原因,并不是开发者不够努力。
让我们来看两个性能指标。
如何优化FCP
FCP
(First Contentful Paint,首次内容绘制)测量「页面从开始加载到页面内容的任何部分在屏幕上完成渲染的时间」。
当前web
应用普遍采用「前端框架」开发,这意味着会引入大量JS
代码(框架本身代码、第三方依赖包的代码......)
从HTML
开始解析到最终页面渲染,中间还要经历:
下载框架
JS
代码执行框架
JS
代码由框架完成页面渲染
这就导致FCP
指标的下降。
为了优化FCP
,框架作者提出了SSR
(Server Side Render,服务端渲染),在服务端生成首屏所需HTML
,这就为FCP
省去了上述三个步骤所需时间。
但是,TTI
指标仍然需要优化。
如何优化TTI
TTI
(Time to Interactive,用户可交互时间)测量「页面变得完全可交互所需时间」。
主要衡量的是从下述1到3所需时间:
首先衡量
FCP
时间为页面中的元素绑定事件
对元素产生交互后,事件响应时间在50ms内
使用SSR
后,虽然FCP
降低,但是框架hydrate
(注水,即框架使页面能够响应交互)所需时间对TTI
会有影响。
可见,性能瓶颈的源头在JS
代码。
React18
的Selective Hydration
通过「让用户交互的部分优先hydrate」来优化TTI
指标。
但是,Qwik
更极端,他的目标是 —— 干掉所有不必要的JS
耗时,这里的耗时包括两部分:
JS
作为静态资源加载的耗时JS
运行时的耗时
超超超细粒度hydrate
如果说传统SSR
的粒度是「整个页面」。
那么React18
的Selective Hydration
的粒度是「产生交互的组件」。
那么Qwik
的粒度是「组件中的某个方法」。
举个例子,下面是HelloWorld
组件(可以发现,Qwik
采用类似React
的语法):
![16b6c7c9be6ad6091b63a96a8a48498a.png](https://i-blog.csdnimg.cn/blog_migrate/8968a778713b5a20cc439dc8454a1ed8.png)
对应页面渲染效果:
![56539ecb4d0bbcc4ecc95a483719b6c2.png](https://i-blog.csdnimg.cn/blog_migrate/91b457ff93b34ea871e19761ef4bec7c.png)
打开浏览器Network
面板,这个页面会有多少JS
请求呢?
由于这是个静态的组件,没有逻辑,所以答案是:没有JS
请求。
再来看看经典的计数器Counter
组件,相比HelloWorld
,增加了「点击按钮状态变化的逻辑」,代码如下:
![5e5ed86e71985825db631fc0e7d54519.png](https://i-blog.csdnimg.cn/blog_migrate/6284bf2eea81070e392e53740081edec.png)
对应页面渲染效果:
![b80352db01db3966217e940bb83870b2.png](https://i-blog.csdnimg.cn/blog_migrate/6686e9c4cff1813ad51db653cd55d9ff.png)
打开浏览器Network
面板,这个页面会有多少JS
请求呢?
答案还是:没有JS
请求。
注意这两个组件的代码中,定义组件使用的是component$
,有个$
符号。
在Counter
中,onClick$
回调也有个$
符号。
在Qwik
中,后缀带$
的函数都是「懒加载」的。
hydrate
的粒度有多细,就取决于$
定义的多细。
比如在Counter
中,onClick$
带$
后缀,那么点击回调是懒加载的,所以首屏渲染不会包含「点击后的逻辑」对应的JS
代码。
在点击按钮后,会发起2个JS
请求,第一个请求返回的是「点击后的逻辑」:
![efca6de358bbb30ae4b6cc8553cd4979.png](https://i-blog.csdnimg.cn/blog_migrate/2c9c8695cff4360bbe72bbaae9bd865c.png)
第2个JS
请求返回的是「组件重新render的逻辑」:
![9c228528ada6da1fdc65e7d44dc362a3.png](https://i-blog.csdnimg.cn/blog_migrate/6402fd054cea79ca73012f997ac11134.png)
这两段代码执行后,Counter
变为1。
![8646b8820bb7717ea8446eead17a7f8c.png](https://i-blog.csdnimg.cn/blog_migrate/a8deb4368a2eb997edf99288fddd2795.png)
审查元素会发现,点击前,button
on:click
属性中保存了「逻辑所在的地址」:
![4632e37ac99a33b59ad9b2e425c6ef55.png](https://i-blog.csdnimg.cn/blog_migrate/5838fe464b83c74bbd819b2ea05f7e5d.png)
点击后,会从对应地址下载JS
代码,执行对应逻辑。
从优秀到极致
是不是觉得已经优化到极致了?还没。
对于一些在页面中长期存在的、需要JS
驱动的模块(比如轮播图),在模块展现前,「模块对应JS」不是必要的。
比如下面这个钟的示例,页面中有个长长的列表,超过一屏高度,在列表底部有个钟。
下面是列表滚到底的样子:
![ca420ebf3adbbc3570ad049d3da78de4.png](https://img-blog.csdnimg.cn/img_convert/ca420ebf3adbbc3570ad049d3da78de4.png)
在Clock
组件的useClientEffect$
中定义「时钟指针摆动的逻辑」:
![3da1ef92253cfab7748841d0ee9e448d.png](https://img-blog.csdnimg.cn/img_convert/3da1ef92253cfab7748841d0ee9e448d.png)
Qwik
中也存在类似React
的useEffect
,但在Qwik
中这个Hook
可以在服务端/客户端执行。
为了区分,useClientEffect
是「只在客户端执行的useEffect」。
加了$
后缀,代表他是「懒加载的」。
具体效果是:当页面滚动到钟露出之前,useClientEffect$
对应JS
代码都不会请求。
当钟露出后,会发起两个JS
资源请求:
useClientEffect
的逻辑Clock
组件重新渲染的逻辑
![819c1c5c23946d4b4f3c92b9fd4fc10d.png](https://img-blog.csdnimg.cn/img_convert/819c1c5c23946d4b4f3c92b9fd4fc10d.png)
如果审查元素,在钟露出前,指针对应元素都是不动的:
![d23f11e6356eb025d25b8e23163d6a44.png](https://img-blog.csdnimg.cn/img_convert/d23f11e6356eb025d25b8e23163d6a44.png)
当钟露出,加载并执行JS
代码后,才开始执行动效:
![40c40cf22e8757a31e5cf7f69beb6d50.png](https://img-blog.csdnimg.cn/img_convert/40c40cf22e8757a31e5cf7f69beb6d50.png)
对数据hydrate
在传统SSR
中,数据其实被初始化了两次:
页面首次渲染,此时服务端导出的
HTML
中已经携带了首屏渲染的数据框架
hydrate
后,数据再转化为框架内的状态供后续渲染
在Qwik
中,页面初始化时会存在type
为qwik/json
的script
标签用于存储「当前页面中被激活的状态对应数据」:
![13e4f896f569c4247caf93198d178338.png](https://img-blog.csdnimg.cn/img_convert/13e4f896f569c4247caf93198d178338.png)
什么叫「被激活」呢?
比如,下面是一篇文章的评论区,这是首屏渲染后的样子:
![10f4dd70be9a886a11d6bc3f5646f95d.png](https://img-blog.csdnimg.cn/img_convert/10f4dd70be9a886a11d6bc3f5646f95d.png)
这些评论数据会出现在qwik/json
保存的数据中么?
不会,因为没有交互激活他们。
我们发现,有一条评论被折叠了,点击后会展开这条评论:
![afc344f0bee937e326749e1f2a474569.png](https://img-blog.csdnimg.cn/img_convert/afc344f0bee937e326749e1f2a474569.png)
点击这个行为会请求:
点击逻辑对应的
JS
代码这条评论对应组件的重新渲染逻辑
此时,评论数据才会出现在qwik/json
中,因为点击交互激活了这个数据。
所以在Qwik
中,如无必要,数据不会被初始化两次。
HTML
中存在「未激活的数据」,qwik/json
的script
标签中保存了「激活的数据」,这个特性会带来一个很有意思的效果:
复制调试工具中「Elements面板下的DOM结构」后,再在新页面中粘贴,就能复现「页面当前的交互状态」(比如,输入框内仍然保留之前输入的内容):
![98d0e636d16c2f8425bf0b5e684b0b82.png](https://img-blog.csdnimg.cn/img_convert/98d0e636d16c2f8425bf0b5e684b0b82.png)
换做其他框架,只能复现「页面初始时的状态」。
交互时再请求JS不会卡么?
有同学可能会问,如果在网络不好的情况下,交互时再请求JS
代码不会让交互变得卡顿么?
Qwik
允许你指定「哪些组件可能是用户大概率会操作的」(比如电商应用中,购物车按钮被点击的概率高)。
这些组件逻辑对应JS
代码会prefetch
,在不影响首屏渲染的前提下被预请求:
![aa700a5c21826fa2d0702d0d49da0744.png](https://img-blog.csdnimg.cn/img_convert/aa700a5c21826fa2d0702d0d49da0744.png)
并且这些组件prefetch
的顺序是可以调整的。
这意味着可以追踪用户行为,以「用户交互的频率」为指标,作为组件prefetch
优先级的依据,启发式提升应用性能。
这才是真正的「以用户为导向」的性能优化,而且是全自动的。
总结
当今是个前端框架百花齐放的时代,不同框架都在寻找自己独特的卖点。
Qwik
的卖点是:将JS
代码的拆分从常见的「编译时」(比如webpack
分块)、「运行时」(比如dynamic import
),变为「交互时」。
对JS
代码的极致拆分,只为达到一个目的 —— 在首屏渲染时,移除你项目中99%的JS
代码。
你觉得这波操作怎么样?
- END -
关于奇舞团
奇舞团是360集团最大的大前端团队,代表集团参与W3C和ECMA会员(TC39)工作。奇舞团非常重视人才培养,有工程师、讲师、翻译官、业务接口人、团队Leader等多种发展方向供员工选择,并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。