新时代的 SSR 框架破局者：qwik( 六 ) _SSR

无论是基于传统 Next 方案还是基于 qwik 这种惰性可恢复的方案，利用 prefetch 等预加载技术优先在网络空闲时加载响应重要的 JS 脚本都是非常有必要的，所以这点在我看来并不是特别重要的问题。
5）延迟加载会带来 bundle 数量的上升吗
qwik 推崇的延迟加载其实已经是一项非常成熟的构建技术了。无论是使用 webpack、rollup 又或是其他任何构建工具都存在延迟加载 & 代码分割的技术。
传统构建工具中关于代码分割会带来以下两点的困难：

需要开发人员自行去处理更加细粒度的代码分割，当然这并不是最主要的。因为目前我们可以利用 ?Magic Comments? 配合 ?Dynaic Imports? 来解决需要手动切入多个入口点的问题。

当然，这一系列事情比起魔法注释。因为 qwik 本身提倡的就是所谓的延迟加载，所以在框架内部已经帮我们足够智能的去处理这个过程。
但是需要注意的是这并不意味着开发者无法自主去控制这个过程。只是在使用框架的过程中，qwik 希望开发者更加专注于他们自身的业务逻辑。

当存在非常多的延迟加载时，传统构建工具会从一个大 bundle 分割成为无数个小的 bundle。

延迟加载模块的确会存在多个 small bundle 的问题，可是当我们拥有的 bundle 越多，其实我们就拥有更多的自由度去以各种各样的方式去拼装成为单个大的 bundle 。
qwik 中存在足够的方式提供给我们将多个小的 chunk 自由组合成为一个从而有效的减少细碎 chunk 的数量，当然这个点在传统构建工具中也是这样。
6）动态创建事件函数会造成内存泄漏吗
qwik 的设计思想在与每次事件触发时通过 qwikloader 来动态创建事件处理函数，相信有的同学存在疑问“那么多次触发事件会造成额外的开销吗” 。
qwik 的作者 miško hevery 在 ??Hydration is Pure Overhead?? 中明确的表示过 qwik 会在每次事件执行完毕后释放函数，相当于每次事件执行完毕都会进行一次“去水合”的过程。
所以，当你触发一次事件和无数次事件函数在执行过程中对于内存占用来说是相差无几的。
当然相较于传统 hydration 的方式（在页面首次渲染时在内存中记录所有状态），无疑 qwik 这种并不在内存中记录任何状态的方式恰恰对于内存的占用比 dyration 更加轻量化。
7）qwik 真的有那么快吗
说了那么多，那么 qwik 真的有那么快吗。

文章插图

上图是利用 qwik 搭建的 ??builder.io?? 官方网站，我相信 builder.io 的数据已经告诉我们答案了。
固然上述的数据并不仅仅只是单纯一个 qwik 框架带给网站的优化，一定会有代码层面或者构建层面等等方面的优化配合而来的数据。但是针对于 FCP 和 TTI 时间上的一致性这在一个中型 SSR 应用程序其实可以称得上是非常优秀了，我相信这足以说明了 qwik 的确名副其实。
二、结语我们可以看出来，qwik 的核心思路还是通过更加细粒的代码控制配合惰性加载事件处理程序以及事件委托来缩短首屏 TTI 。
文章中我们也讲到了 qwik 其实并不是因为使用了多么牛逼的算法导致它有多么快，而它的速度正是得益于它的设计思路，省略了传统 SSR 下首屏需要加载庞大的 JS 进行 hydration 的过程。
当然，我们对于 qwik 也仍是在学习阶段。后续会在公司里的更多项目尝试 qwik 之后也会和大家分享关于它的更多心得。
总而言之，qwik 的“无水合”设计思路目前看来的确会在框架层面带来巨大的性能提升。大家如果有机会的话也可以在项目中尝试一下 qwik，相信会给你带来意想不到的收益效果。

【新时代的 SSR 框架破局者：qwik】