高级前端面试题（1）

vue 中的 spa 应用如何优化首屏加载速度?

优化首屏加载可以从这几个方面开始：

• 请求优化：CDN 将第三方的类库放到 CDN 上，能够大幅度减少生产环境中的项目体积，另外 CDN 能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。
• 缓存：将长时间不会改变的第三方类库或者静态资源设置为强缓存，将 max-age 设置为一个非常长的时间，再将访问路径加上哈希达到哈希值变了以后保证获取到最新资源，好的缓存策略有助于减轻服务器的压力，并且显著的提升用户的体验
• gzip：开启 gzip 压缩，通常开启 gzip 压缩能够有效的缩小传输资源的大小。
• http2：如果系统首屏同一时间需要加载的静态资源非常多，但是浏览器对同域名的 tcp 连接数量是有限制的(chrome 为 6 个)超过规定数量的 tcp 连接，则必须要等到之前的请求收到响应后才能继续发送，而 http2 则可以在多个 tcp 连接中并发多个请求没有限制，在一些网络较差的环境开启 http2 性能提升尤为明显。
• 懒加载：当 url 匹配到相应的路径时，通过 import 动态加载页面组件，这样首屏的代码量会大幅减少，webpack 会把动态加载的页面组件分离成单独的一个 chunk.js 文件
• 预渲染：由于浏览器在渲染出页面之前，需要先加载和解析相应的 html、css 和 js 文件，为此会有一段白屏的时间，可以添加loading，或者骨架屏幕尽可能的减少白屏对用户的影响体积优化
• 合理使用第三方库：对于一些第三方 ui 框架、类库，尽量使用按需加载，减少打包体积
• 使用可视化工具分析打包后的模块体积：webpack-bundle- analyzer 这个插件在每次打包后能够更加直观的分析打包后模块的体积，再对其中比较大的模块进行优化
• 提高代码使用率：利用代码分割，将脚本中无需立即调用的代码在代码构建时转变为异步加载的过程
• 封装：构建良好的项目架构，按照项目需求就行全局组件，插件，过滤器，指令，utils 等做一 些公共封装，可以有效减少我们的代码量，而且更容易维护资源优化
• 图片懒加载：使用图片懒加载可以优化同一时间减少 http 请求开销，避免显示图片导致的画面抖动，提高用户体验
• 使用 svg 图标：相对于用一张图片来表示图标，svg 拥有更好的图片质量，体积更小，并且不需要开启额外的 http 请求
• 压缩图片：可以使用 image-webpack-loader，在用户肉眼分辨不清的情况下一定程度上压缩图片

vue组件中写 name 选项有哪些好处

• 可以通过名字找到对应的组件（ 递归组件：组件自身调用自身 ）
• 可以通过 name 属性实现缓存功能（keep-alive）
• 可以通过 name 来识别组件（跨级组件通信时非常重要）
• 使用 vue-devtools 调试工具里显示的组见名称是由 vue 中组件 name 决定的

webpack有哪些常见的 Loader 和 Plugin？

Loader:

• babel-loader：将ES6+的代码转换成ES5的代码。
• css-loader：解析CSS文件，并处理CSS中的依赖关系。
• style-loader：将CSS代码注入到HTML文档中。
• file-loader：解析文件路径，将文件赋值到输出目录，并返回文件路径。
• url-loader：类似于file-loader，但是可以将小于指定大小的文件转成base64编码的Data URL格式
• sass-loader：将Sass文件编译成CSS文件。
• less-loader：将Less文件编译成CSS文件。
• postcss-loader：自动添加CSS前缀，优化CSS代码等。
• vue-loader：将Vue单文件组件编译成JavaScript代码。

Plugin:

• HtmlWebpackPlugin：生成HTML文件，并自动将打包后的javaScript和CSS文件引入到HTML文件中。

• CleanWebpackPlugin：清除输出目录。

• ExtractTextWebpackPlugin：将CSS代码提取到单独的CSS文件中。

• DefinePlugin：定义全局变量。

• UglifyJsWebpackPlugin：压缩JavaScript代码。

• HotModuleReplacementPlugin：热模块替换，用于在开发环境下实现热更新。

• MiniCssExtractPlugin：与ExtractTextWebpackPlugin类似，将CSS代码提取到单独的CSS文件中。

• BundleAnalyzerPlugin：分析打包后的文件大小和依赖关系。

Loader和Plugin的区别

功能不同：

Loader本质是一个函数，它是一个转换器。webpack只能解析原生js文件，对于其他类型文件就需要loade进行转换。

Plugin它是一个插件，用于增强webpack功能。webpack在运行的生命周期中会广播出许多事件，Plugin 可以监听这些事件，在合适的时机通过 webpack 提供的 API 改变输出结果 。

用法不同：

Loader的配置是在module.rules下进行。类型为数组，每⼀项都是⼀个 Object ，⾥⾯描述了对于什么类型的⽂件（ test ），使⽤什么加载( loader )和使⽤的参数（ options ） 。

Plugin的配置在plugins下。类型为数组，每一项是一个 Plugin 的实例，参数都通过构造函数传入。

如何减少打包后的代码体积

• 代码分割（Code Splitting）：将应用程序的代码划分为多个代码块，按需加载
• Tree Shaking：配置Webpack的Tree Shaking机制，去除未使用的代码
• 压缩代码：使用工具如UglifyJS或Terser来压缩JavaScript代码
• 使用生产模式：在Webpack中使用生产模式，通过设置mode: 'production'来启用优化
• 使用压缩工具：使用现代的压缩工具，如Brotli和Gzip，来对静态资源进行压缩
• 利用CDN加速：将项目中引用的静态资源路径修改为CDN上的路径，减少图片、字体等静态资源等打包

vite比webpack快在哪里

(一）、开发模式的差异

在开发环境中，Webpack 是先打包再启动开发服务器，而 Vite 则是直接启动，然后再按需编译依赖文件。（大家可以启动项目后检查源码 Sources 那里看到）

这意味着，当使用 Webpack 时，所有的模块都需要在开发前进行打包，这会增加启动时间和构建时间。

而 Vite 则采用了不同的策略，它会在请求模块时再进行实时编译，这种按需动态编译的模式极大地缩短了编译时���，特别是在大型项目中，文件数量众多，Vite 的优势更为明显。

Webpack启动

Vite启动

（二）、对ES Modules的支持

现代浏览器本身就支持 ES Modules，会主动发起请求去获取所需文件。Vite充分利用了这一点，将开发环境下的模块文件直接作为浏览器要执行的文件，而不是像 Webpack 那样先打包，再交给浏览器执行。这种方式减少了中间环节，提高了效率。

什么是ES Modules？

通过使用 export 和 import 语句，ES Modules 允许在浏览器端导入和导出模块。

当使用 ES Modules 进行开发时，开发者实际上是在构建一个依赖关系图，不同依赖项之间通过导入语句进行关联。

主流浏览器（除IE外）均支持ES Modules，并且可以通过在 script 标签中设置 type="module"来加载模块。默认情况下，模块会延迟加载，执行时机在文档解析之后，触发DOMContentLoaded事件前。

(3)、底层语言的差异

Webpack 是基于 Node.js 构建的，而 Vite 则是基于 esbuild 进行预构建依赖。esbuild 是采用 Go 语言编写的，Go 语言是纳秒级别的，而 Node.js 是毫秒级别的。因此，Vite 在打包速度上相比Webpack 有 10-100 倍的提升。

什么是预构建依赖？

预构建依赖通常指的是在项目启动或构建之前，对项目中所需的依赖项进行预先的处理或构建。这样做的好处在于，当项目实际运行时，可以直接使用这些已经预构建好的依赖，而无需再进行实时的编译或构建，从而提高了应用程序的运行速度和效率。

(4)、热更新的处理

在 Webpack 中，当一个模块或其依赖的模块内容改变时，需要重新编译这些模块。

而在 Vite 中，当某个模块内容改变时，只需要让浏览器重新请求该模块即可，这大大减少了热更新的时间。

CSS 工程化是为了解决以下问题：

1. 宏观设计：CSS 代码如何组织、如何拆分、模块结构怎样设计？
2. 编码优化：怎样写出更好的 CSS？
3. 构建：如何处理我的 CSS，才能让它的打包结果最优？
4. 可维护性：代码写完了，如何最小化它后续的变更成本？如何确保任何一个同事都能轻松接手？

以下三个方向都是时下比较流行的、普适性非常好的 CSS 工程化实践：

• 预处理器：Less、 Sass 等；
• 重要的工程化插件： PostCss；
• Webpack loader 等 。

基于这三个方向，可以衍生出一些具有典型意义的子问题，这里我们逐个来看：

（1）预处理器：为什么要用预处理器？它的出现是为了解决什么问题？ 预处理器，其实就是 CSS 世界的“轮子”。预处理器支持我们写一种类似 CSS、但实际并不是 CSS 的语言，然后把它编译成 CSS 代码：

那为什么写 CSS 代码写得好好的，偏偏要转去写“类 CSS”呢？这就和本来用 JS 也可以实现所有功能，但最后却写 React 的 jsx 或者 Vue 的模板语法一样。

随着前端业务复杂度的提高，前端工程中对 CSS 提出了以下的诉求：

• 宏观设计上：我们希望能优化 CSS 文件的目录结构，对现有的 CSS 文件实现复用；
• 编码优化上：我们希望能写出结构清晰、简明易懂的 CSS，需要它具有一目了然的嵌套层级关系，而不是无差别的一铺到底写法；我们希望它具有变量特征、计算能力、循环能力等等更强的可编程性，这样我们可以少写一些无用的代码；
• 可维护性上：更强的可编程性意味着更优质的代码结构，实现复用意味着更简单的目录结构和更强的拓展能力，这两点如果能做到，自然会带来更强的可维护性。

这三点是传统 CSS 所做不到的，也正是预处理器所解决掉的问题。预处理器普遍会具备这样的特性：

• 嵌套代码的能力，通过嵌套来反映不同 css 属性之间的层级关系 ；
• 支持定义 css 变量；
• 提供计算函数；
• 允许对代码片段进行 extend 和 mixin；
• 支持循环语句的使用；
• 支持将 CSS 文件模块化，实现复用。

（2）PostCss：PostCss 是如何工作的？我们在什么场景下会使用 PostCss？

它和预处理器的不同就在于，预处理器处理的是 类CSS，而 PostCss 处理的就是 CSS 本身。Babel 可以将高版本的 JS 代码转换为低版本的 JS 代码。PostCss 做的是类似的事情：它可以编译尚未被浏览器广泛支持的先进的 CSS 语法，还可以自动为一些需要额外兼容的语法增加前缀。更强的是，由于 PostCss 有着强大的插件机制，支持各种各样的扩展，极大地强化了 CSS 的能力。

PostCss 在业务中的使用场景非常多：

• 提高 CSS 代码的可读性：PostCss 其实可以做类似预处理器能做的工作；
• 当我们的 CSS 代码需要适配低版本浏览器时，PostCss 的 Autoprefixer 插件可以帮助我们自动增加浏览器前缀；
• 允许我们编写面向未来的 CSS：PostCss 能够帮助我们编译 CSS next 代码；

（3）Webpack 能处理 CSS 吗？如何实现？

• Webpack 在裸奔的状态下，是不能处理 CSS 的，Webpack 本身是一个面向 JavaScript 且只能处理 JavaScript 代 码的模块化打包工具；
• Webpack 在 loader 的辅助下，是可以处理 CSS 的。

如何用 Webpack 实现对 CSS 的处理：

• Webpack 中操作 CSS 需要使用的两个关键的 loader：css-loader 和 style-loader
• 注意，答出“用什么”有时候可能还不够，面试官会怀疑你是不是在背答案，所以你还需要了解每个 loader 都做了什么事情：

• css-loader：导入 CSS 模块，对 CSS 代码进行编译处理；

• style-loader：创建style标签，把 CSS 内容写入标签。