共计 1715 个字符，预计需要花费 5 分钟才能阅读完成。
随着 vue3 的到来，vite 开始被各大 vue3 组件库应用，公司开始一个新我的项目，筹备尝试用 vite 试一波。
问题发现
当把公司新我的项目移植到 vite 后，启动十分快，但发现页渲染工夫慢了很多。
能够看到页面的首屏加载工夫是 3.34s，页面的渲染完工夫是 3.37s，下载总大小是 8.6MB，发送了 119 个申请；
再看看 webpack 的渲染工夫：
能够看到页面的首屏加载工夫是 1.05s，页面的渲染完工夫是 1.21s，下载总大小是 3.6MB，发送了 32 个申请；
vite 的首屏加载工夫是 webpack 的三倍，下载文件大小是 webpack 的两倍，申请数量也是三倍。vite 开发环境下，模块以原生 esm 的模式被浏览器加载，也就说模块的加载是用 es6 原生的模块加载机制，没有对代码进行打包压缩解决，所以服务启动很快。那带来的问题就是下载的 js 文件没有解决的过的源码，那文件大小天然要比 webpack 解决过的 js 文件大很多。
因而初步判断因为这个起因导致首屏加载工夫相差这么多。得出结论 vite 是就义了页面首次加载工夫来达到启动工夫快的目标。
峰回路转
于是我去网上寻找有没有好的解决方案，在 vite 的 issue 中找到相似的问题：
尤大大也答复了这个问题：
这个问题有两个细节：
- 我的项目启动后浏览器第一次加载才会慢。
- 这个慢是因为加载 less 的源码，按需编译中加载工夫其实是在 less 的编译上。
看看 vite 我的项目第二次加载：
能够看到页面的首屏加载工夫是 1.04s，页面的渲染完工夫是 1.09s，下载总大小是 8.6MB，发送了 120 个申请；
页面的渲染工夫和 webpack 我的项目的渲染工夫差不多，esm 的模式被浏览器加载和申请数量对页面的渲染工夫的影响不是次要的，也证实我的项目启动后浏览器第一次加载多出的工夫次要是在编译上。
尤大大在知乎答复中提到：“webpack 的打包模式在我的项目自身源码模块数量极大 (>1000) 的状况下还是有一点劣势的，因为浏览器在解决这个级别的并发申请上会产生阻塞（但通常来说如果你一个路由下模块数到这个级别阐明你代码宰割 / 按需加载没做好）。”意思是 esm 的模式被浏览器加载和申请数量对页面的渲染工夫的影响不是次要的。
剖析
浏览器第一次加载工夫比拟长的文件工夫分部：
waterfall 性能检测详解详解:
- Queueing 是排队的意思
- Stalled 是阻塞 申请拜访该 URL 的主机是有并发和连接数限度的, 必须要等之前的执行能力执行之后的, 这段时间的耗时
- DNS Lookup 是指域名解析所耗时间
- Initial connection 初始化连接时间, 这里个别是 TCP 3 次连贯握手工夫
- SSL https 特有, 是一种协定
- Request sent 发送申请所耗费的工夫
- Waiting 期待响应工夫, 这里个别是最耗时的
- Content Download 下载内容所须要耗费的工夫
加载 index.less 的工夫次要在 Waiting 阶段，Content Download 的工夫占比很少。期待响应工夫应该就是 vite 在编译的工夫。
我的我的项目也援用了组件库的 less 源码，改为援用组件库的 css 看下渲染工夫如何：
能够看到页面的首屏加载工夫是 1.13s，页面的渲染完工夫是 1.16s，下载总大小是 8.4MB，发送了 120 个申请；
渲染速度根本和 webpack 差不多。
论断
通过下面剖析能够确定 vite 开发模式启动，页面加载慢的起因是 less 编译导致。
这里反思下，因为对调试工具 waterfall 性能检测不相熟导致开始谬误的论断，走了一下弯路。有时候咱们通过实践推导进去的论断未必正确的，须要理论数据去证实但更须要去证伪。就像吴军老师说的：
“ 咱们每次给出的论断，都存在一种证伪的可能性，咱们能够设计出一种办法、一个试验，或者一个场景，去看看咱们的论断是不是还是成立，如果成立，咱们就维持现有的论断；如果不成立，咱们就批改现有论断。这就叫做证伪 。
迷信是一种做事件的办法，而不是特定的论断。采纳迷信办法失去的论断，绝对来讲，比拟经得起工夫和事实世界的测验。更重要的是，用迷信的办法求知，咱们能失去可累加的提高，因为每一次验证的过程都是能够反复，前面的工作也能够基于后面的工作开展。”这句话牢记心中。
