前言–vite是什么
Vite 是一个基于 ES Modules 的构建工具,它的主要特点是快速的冷启动和快速的热更新。Vite 的原理可以分为以下几个部分:
冷启动阶段:
Vite 在冷启动阶段会启动一个开发服务器,监听指定的端口。当浏览器请求项目中的模块时,Vite 会通过 URL 解析出模块的路径,并使用原生的 ES Modules 特性动态加载模块。此时,Vite 会将请求转发到真实的模块文件,并返回模块的内容。
热更新阶段:
当代码发生变化时,Vite 会使用 WebSocket 与浏览器建立连接,并通过 HMR(Hot Module Replacement)技术实现快速的热更新。具体地,Vite 会监听项目中的文件变化,并触发相关的构建任务。当构建任务完成后,Vite 会发送更新信号给浏览器,浏览器会重新加载相应的模块并更新页面。
构建阶段:
在生产环境下,Vite 会对项目进行构建和优化,并生成可部署的静态资源。具体地,Vite 会使用 Rollup 进行打包,并使用插件进行压缩、优化和代码分割等操作。在构建过程中,Vite 会利用缓存和增量构建等技术,以提高构建速度和效率。
Vite 的原理可以总结为:利用原生的 ES Modules 特性,在浏览器中动态加载模块,并通过 WebSocket 和 HMR 技术实现快速的热更新。在生产环境下,Vite 利用 Rollup 进行打包和优化,以生成可部署的静态资源。这种基于 ES Modules 的构建方式与传统的打包方式不同,它可以提高开发效率,加速构建速度,同时也更符合现代前端开发的趋势。
1.vite为啥比webpack快
Vite快主要体现在两个方面:快速的冷启动和快速的热更新。而vite之所以能如此优秀,完全基于他借助了浏览器对ESM规范的支持,采取了与Webpack完全不同的unbundle机制。
1.1 快速的冷启动
同一个小型项目,Webpack启动需要25s左右,而Vite只需要2s左右。
Webpack为什么慢
Webpack启动慢,主要是由于其内部的核心机制——bundle模式引发的。
Webpack通过这种 bundle机制,将项目中各种类型的源文件转化供浏览器识别的js、css、img
等文件,建立源文件之间的依赖关系,并将数量庞大的源文件合并为少量的几个输出文件。
bundle工作机制的核心部分分为两块:构建模块依赖图 - module graph 和将 module graph 分解为最终供浏览器使用的几个输出文件。
强大的 bundle 机制,也引发了构建速度缓慢的问题,而且项目规模越大,构建速度越是缓慢。其主要原因是构建 module graph 的过程中,涉及到大量的文件 IO、文件 transfrom、文件 parse 操作;以及分解 module graph 的过程中,需要遍历 module graph、文件 transform、文件 IO 等。这些操作,往往需要消耗大量的时间,导致构建速度变得缓慢。
开发模式下,dev server 需要 Webpack 完成整个工作链路才可以启动成功,这就导致构建过程耗时越久,dev server 启动越久。
为了加快构建速度,Webpack 也做了大量的优化,如 loader 的缓存功能、webpack5 的持久化缓存等,但这些都治标不治本,只要 Webpack 的核心工作机制不变,那dev server启动优化,基本上永远都达不到Vite那样的效果。
Vite为什么快
Vite 之所以在dev server启动方面,如此给力,是因为它采取了与 Webpack 截然不同的 unbundle 机制。
unbundle 机制,顾名思义,不需要做 bundle 操作,即不需要构建、分解 module graph,源文件之间的依赖关系完全通过浏览器对 ESM 规范的支持来解析。这就使得 dev server 在启动过程中只需做一些初始化的工作,剩下的完全由浏览器支持。
那有的同学就会问,源文件的resolve、load、transform、parse什么时候做呢 ?
答案是浏览器发起请求以后,dev server 端会通过 middlewares 对请求做拦截,然后对源文件做 resolve、load、transform、parse 操作,然后再将转换以后的内容发送给浏览器。
总结一下,unbundle 机制的核心:
1.模块之间的依赖关系的解析由浏览器实现
2.文件的转换由 dev server 的 middlewares 实现并做缓存
3.不对源文件做合并捆绑操作
1.2 快速的热更新
除了 dev server 启动外, Vite 在热更新方面也有非常优秀的表现。
修改原文件后,Webpack发生耗时大概 5 s 的重新编译打包过程, 而vite更是做到了毫秒级的效果。
Wabpack
dev server 启动以后,会watch源文件的变化。当源文件发生变化后,Webpack 会重新编译打包。这个时候,由于我们只修改了一个文件,因此只需要对这个源文件做 resolve、 load、 transfrom、parse 操作,依赖的文件直接使用缓存,因此 dev server 的响应速度比冷启动要好很多。
dev server 重新编译打包以后,会通过 ws 连接通知浏览器去获取新的打包文件,然后对页面做局部更新。
由于 Vite 采用 unbundle 机制,所以 dev server在监听到文件发生变化以后,只需要通过ws` 连接通知浏览器去重新加载变化的文件,剩下的工作就交给浏览器去做了。
2. Vite的缺点
和 bundle 机制有利有弊一样,unbundle 机制给 Vite 在dev server方面获得巨大性能提升的同时,也带来一些负面影响,那就是首屏和懒加载性能的下降。
首屏
由于unbundle机制,首屏期间需要额外做以下工作:
- 不对源文件做合并捆绑操作,导致大量的 http 请求;
- dev server 运行期间对源文件做 resolve、load、transform、parse 操作;
- 预构建、二次预构建操作也会阻塞首屏请求,直到预构建完成为止;
和 Webpack 对比,Vite 把需要在 dev server 启动过程中完成的工作,转移到了 dev server 响应浏览器请求的过程中,不可避免的导致首屏性能下降。
不过首屏性能差只发生在 dev server 启动以后第一次加载页面时发生。之后再reload页面时,首屏性能会好很多。原因是 dev server 会将之前已经完成转换的内容缓存起来。
懒加载
和首屏一样,由于 unbundle 机制,动态加载的文件,需要做 resolve、load、transform、parse 操作,并且还有大量的 http 请求,导致懒加载性能也受到影响。