【webpack】11.webpack高级优化（2）

小前端端
123 阅读12分钟

接着上次的继续，上次我们说到，高级优化我们一般从以下几方面入手

  1. 提升开发体验
  2. 提升打包构建的速度
  3. 减少代码体积
  4. 优化代码的运行性能

本文将细说3、4两方面

1.减少打包代码体积

1.1 Tree Shaking

开发时我们定义了一些工具函数库，或者引用第三方工具函数库或组件库。 如果没有特殊处理的话我们打包时会引入整个库，但是实际上可能我们可能只用上极小部分的功能。 这样将整个库都打包进来，体积就太大了。

Tree Shaking 是一个术语，通常用于描述移除 JavaScript 中的没有使用上的代码。

注意：它依赖 ES Module。

Webpack 已经默认开启了这个功能，无需其他配置

1.2 Babel

Babel 为编译的每个文件都插入了辅助代码，使代码体积过大！

Babel 对一些公共方法使用了非常小的辅助代码，比如 _extend。默认情况下会被添加到每一个需要它的文件中。

你可以将这些辅助代码作为一个独立模块，来避免重复引入。

我们可以用@babel/plugin-transform-runtime: 禁用了 Babel 自动对每个文件的 runtime 注入，而是引入 @babel/plugin-transform-runtime 并且使所有辅助代码从这里引用。

下载包

npm i @babel/plugin-transform-runtime -D

引入配置

image.png

1.3 Image Minimizer

开发如果项目中引用了较多图片，那么图片体积会比较大，将来请求速度比较慢。

我们可以对图片进行压缩，减少图片体积。注意：如果项目中图片都是在线链接，那么就不需要了。本地项目静态图片才需要进行压缩。

该如何压缩图片呢？，可以借助插件

image-minimizer-webpack-plugin: 用来压缩图片的插件

下载包

npm install imagemin-gifsicle imagemin-jpegtran imagemin-optipng imagemin-svgo -D

还有剩余的包需要下载，有两种模式

  • 无损压缩
npm install imagemin-gifsicle imagemin-jpegtran imagemin-optipng imagemin-svgo -D
  • 有损压缩
npm install imagemin-gifsicle imagemin-mozjpeg imagemin-pngquant imagemin-svgo -D

我们选择无损模式，然后进行相关的配置

image.png

2优化代码运行性能

2.1Code Split 代码分割

打包代码时会将所有 js 文件打包到一个文件中，体积太大了。我们如果只要渲染首页，就应该只加载首页的 js 文件，其他文件不应该加载。

所以我们需要将打包生成的文件进行代码分割，生成多个 js 文件，渲染哪个页面就只加载某个 js 文件，这样加载的资源就少，速度就更快。

代码分割（Code Split）主要做了两件事：

  1. 分割文件：将打包生成的文件进行分割，生成多个 js 文件。
  2. 按需加载：需要哪个文件就加载哪个文件。

（1）多入口

先创建一个项目目录

├── public
├── src
|   ├── app.js
|   └── main.js
├── package.json
└── webpack.config.js

下载包

npm i webpack webpack-cli html-webpack-plugin -D

写相关配置，这里面比较关键的就是，使用了多个入口文件，多入口打包，会输出多个文件

// webpack.config.js
const path = require("path");
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  // 单入口
  // entry: './src/main.js',
  // 多入口
  entry: {
    main: "./src/main.js",
    app: "./src/app.js",
  },
  output: {
    path: path.resolve(__dirname, "./dist"),
    // [name]是webpack命名规则，使用chunk的name作为输出的文件名。
    // 什么是chunk？打包的资源就是chunk，输出出去叫bundle。
    // chunk的name是啥呢？ 比如： entry中xxx: "./src/xxx.js", name就是xxx。注意是前面的xxx，和文件名无关。
    // 为什么需要这样命名呢？如果还是之前写法main.js，那么打包生成两个js文件都会叫做main.js会发生覆盖。(实际上会直接报错的)
    filename: "js/[name].js",
    clear: true,
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "./public/index.html",
    }),
  ],
  mode: "production",
};

最终打包后的js文件有2个。

（2）提取重复代码

如果多入口文件中都引用了同一份代码，我们不希望这份代码被打包到两个文件中，导致代码重复，体积更大。

我们需要提取多入口的重复代码，只打包生成一个 js 文件，其他文件引用它就好。

  1. 修改文件
  • app.js
import { sum } from "./math";

console.log("hello app");
console.log(sum(1, 2, 3, 4));
  • main.js
import { sum } from "./math";

console.log("hello main");
console.log(sum(1, 2, 3, 4, 5));
  • math.js
export const sum = (...args) => {
  return args.reduce((p, c) => p + c, 0);
};
  1. 修改配置文件
// webpack.config.js
const path = require("path");
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  // 单入口
  // entry: './src/main.js',
  // 多入口
  entry: {
    main: "./src/main.js",
    app: "./src/app.js",
  },
  output: {
    path: path.resolve(__dirname, "./dist"),
    // [name]是webpack命名规则，使用chunk的name作为输出的文件名。
    // 什么是chunk？打包的资源就是chunk，输出出去叫bundle。
    // chunk的name是啥呢？ 比如： entry中xxx: "./src/xxx.js", name就是xxx。注意是前面的xxx，和文件名无关。
    // 为什么需要这样命名呢？如果还是之前写法main.js，那么打包生成两个js文件都会叫做main.js会发生覆盖。(实际上会直接报错的)
    filename: "js/[name].js",
    clean: true,
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "./public/index.html",
    }),
  ],
  mode: "production",
  optimization: {
    // 代码分割配置
    splitChunks: {
      chunks: "all", // 对所有模块都进行分割
      // 以下是默认值
      // minSize: 20000, // 分割代码最小的大小
      // minRemainingSize: 0, // 类似于minSize，最后确保提取的文件大小不能为0
      // minChunks: 1, // 至少被引用的次数，满足条件才会代码分割
      // maxAsyncRequests: 30, // 按需加载时并行加载的文件的最大数量
      // maxInitialRequests: 30, // 入口js文件最大并行请求数量
      // enforceSizeThreshold: 50000, // 超过50kb一定会单独打包（此时会忽略minRemainingSize、maxAsyncRequests、maxInitialRequests）
      // cacheGroups: { // 组，哪些模块要打包到一个组
      //   defaultVendors: { // 组名
      //     test: /[\/]node_modules[\/]/, // 需要打包到一起的模块
      //     priority: -10, // 权重（越大越高）
      //     reuseExistingChunk: true, // 如果当前 chunk 包含已从主 bundle 中拆分出的模块，则它将被重用，而不是生成新的模块
      //   },
      //   default: { // 其他没有写的配置会使用上面的默认值
      //     minChunks: 2, // 这里的minChunks权重更大
      //     priority: -20,
      //     reuseExistingChunk: true,
      //   },
      // },
      // 修改配置
      cacheGroups: {
        // 组，哪些模块要打包到一个组
        // defaultVendors: { // 组名
        //   test: /[\/]node_modules[\/]/, // 需要打包到一起的模块
        //   priority: -10, // 权重（越大越高）
        //   reuseExistingChunk: true, // 如果当前 chunk 包含已从主 bundle 中拆分出的模块，则它将被重用，而不是生成新的模块
        // },
        default: {
          // 其他没有写的配置会使用上面的默认值
          minSize: 0, // 我们定义的文件体积太小了，所以要改打包的最小文件体积
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
      },
    },
  },
};

2.2Preload / Prefetch

我们前面已经做了代码分割，同时会使用 import 动态导入语法来进行代码按需加载（我们也叫懒加载，比如路由懒加载就是这样实现的）。

但是加载速度还不够好，比如：是用户点击按钮时才加载这个资源的，如果资源体积很大，那么用户会感觉到明显卡顿效果。

我们想在浏览器空闲时间，加载后续需要使用的资源。我们就需要用上 Preload 或 Prefetch 技术

是什么

  • Preload：告诉浏览器立即加载资源。
  • Prefetch：告诉浏览器在空闲时才开始加载资源。

它们共同点：

  • 都只会加载资源，并不执行。
  • 都有缓存。

它们区别：

  • Preload加载优先级高，Prefetch加载优先级低。
  • Preload只能加载当前页面需要使用的资源，Prefetch可以加载当前页面资源，也可以加载下一个页面需要使用的资源。

总结：

  • 当前页面优先级高的资源用 Preload 加载。
  • 下一个页面需要使用的资源用 Prefetch 加载。

它们的问题：兼容性较差。

  • 我们可以去 Can I Useopen in new window 网站查询 API 的兼容性问题。
  • Preload 相对于 Prefetch 兼容性好一点。

#怎么用

下载包

npm i @vue/preload-webpack-plugin -D

配置

const PreloadWebpackPlugin = require("@vue/preload-webpack-plugin");

//在插件里
  new PreloadWebpackPlugin({
      rel: "preload", // preload兼容性更好
      as: "script",
      // rel: 'prefetch' // prefetch兼容性更差
    }),

2.3 Network Cache

将来开发时我们对静态资源会使用缓存来优化，这样浏览器第二次请求资源就能读取缓存了，速度很快。

但是这样的话就会有一个问题, 因为前后输出的文件名是一样的，都叫 main.js，一旦将来发布新版本，因为文件名没有变化导致浏览器会直接读取缓存，不会加载新资源，项目也就没法更新了。

所以我们从文件名入手，确保更新前后文件名不一样，这样就可以做缓存了。一般是在文件名中加入hash值，文件一改动，hash值就会变动，这样来保证更新前后的文件名不一致，浏览器就会重新更新资源。

  • fullhash（webpack4 是 hash）

每次修改任何一个文件，所有文件名的 hash 至都将改变。所以一旦修改了任何一个文件，整个项目的文件缓存都将失效。

  • chunkhash

根据不同的入口文件(Entry)进行依赖文件解析、构建对应的 chunk，生成对应的哈希值。我们 js 和 css 是同一个引入，会共享一个 hash 值。

  • contenthash

根据文件内容生成 hash 值，只有文件内容变化了，hash 值才会变化。所有文件 hash 值是独享且不同的。

用的话，一般是在输出文件路径以及名称的时候加入hash

  // [contenthash:8]使用contenthash，取8位长度
    filename: "static/js/[name].[contenthash:8].js", // 入口文件打包输出资源命名方式
    chunkFilename: "static/js/[name].[contenthash:8].chunk.js", // 动态导入输出资源命名方式

此时会出现一个新的问题，

  • 问题：

当我们修改 aa.js 文件再重新打包的时候，因为 contenthash 原因，aa.js 文件 hash 值发生了变化（这是正常的）。

但是 aa.js 文件的 hash 值也发生了变化，这会导致 main.js 的缓存失效。明明我们只修改 aa.js, 为什么 main.js 也会变身变化呢？

  • 原因：

    • 更新前：aa.xxx.js, main.js 引用的 aa.xxx.js
    • 更新后：aa.yyy.js, main.js 引用的 aa.yyy.js, 文件名发生了变化，间接导致 main.js 也发生了变化

  • 解决：

将 hash 值单独保管在一个 runtime 文件中。

我们最终输出三个文件：main、aa、runtime。当 aa 文件发送变化，变化的是 aa 和 runtime 文件，main 不变。

runtime 文件只保存文件的 hash 值和它们与文件关系，整个文件体积就比较小，所以变化重新请求的代价也小。

// 提取runtime文件
    runtimeChunk: {
      name: (entrypoint) => `runtime~${entrypoint.name}`, // runtime文件命名规则
    },

2.4 Core-js

过去我们使用 babel 对 js 代码进行了兼容性处理，其中使用@babel/preset-env 智能预设来处理兼容性问题。

它能将 ES6 的一些语法进行编译转换，比如箭头函数、点点点运算符等。但是如果是 async 函数、promise 对象、数组的一些方法（includes）等，它没办法处理。

所以此时我们 js 代码仍然存在兼容性问题，一旦遇到低版本浏览器会直接报错。所以我们想要将 js 兼容性问题彻底解决

#是什么

core-js 是专门用来做 ES6 以及以上 API 的 polyfill。

polyfill翻译过来叫做垫片/补丁。就是用社区上提供的一段代码，让我们在不兼容某些新特性的浏览器上，使用该新特性。

2.4 PWA

渐进式网络应用程序(progressive web application - PWA)：是一种可以提供类似于 native app(原生应用程序) 体验的 Web App 的技术。

其中最重要的是，在 离线(offline)  时应用程序能够继续运行功能。

内部通过 Service Workers 技术实现的。

npm i workbox-webpack-plugin -D

const WorkboxPlugin = require("workbox-webpack-plugin");

 new WorkboxPlugin.GenerateSW({
      // 这些选项帮助快速启用 ServiceWorkers
      // 不允许遗留任何“旧的” ServiceWorkers
      clientsClaim: true,
      skipWaiting: true,
    }),

main.JS

if ("serviceWorker" in navigator) {
  window.addEventListener("load", () => {
    navigator.serviceWorker
      .register("/service-worker.js")
      .then((registration) => {
        console.log("SW registered: ", registration);
      })
      .catch((registrationError) => {
        console.log("SW registration failed: ", registrationError);
      });
  });
}

3总结

我们从 4 个角度对 webpack 和代码进行了优化：

  1. 提升开发体验
  • 使用 Source Map 让开发或上线时代码报错能有更加准确的错误提示。
  1. 提升 webpack 提升打包构建速度
  • 使用 HotModuleReplacement 让开发时只重新编译打包更新变化了的代码，不变的代码使用缓存，从而使更新速度更快。
  • 使用 OneOf 让资源文件一旦被某个 loader 处理了，就不会继续遍历了，打包速度更快。
  • 使用 Include/Exclude 排除或只检测某些文件，处理的文件更少，速度更快。
  • 使用 Cache 对 eslint 和 babel 处理的结果进行缓存，让第二次打包速度更快。
  • 使用 Thead 多进程处理 eslint 和 babel 任务，速度更快。（需要注意的是，进程启动通信都有开销的，要在比较多代码处理时使用才有效果）
  1. 减少代码体积
  • 使用 Tree Shaking 剔除了没有使用的多余代码，让代码体积更小。
  • 使用 @babel/plugin-transform-runtime 插件对 babel 进行处理，让辅助代码从中引入，而不是每个文件都生成辅助代码，从而体积更小。
  • 使用 Image Minimizer 对项目中图片进行压缩，体积更小，请求速度更快。（需要注意的是，如果项目中图片都是在线链接，那么就不需要了。本地项目静态图片才需要进行压缩。）
  1. 优化代码运行性能

  • 使用 Code Split 对代码进行分割成多个 js 文件，从而使单个文件体积更小，并行加载 js 速度更快。并通过 import 动态导入语法进行按需加载，从而达到需要使用时才加载该资源，不用时不加载资源。

  • 使用 Preload / Prefetch 对代码进行提前加载，等未来需要使用时就能直接使用，从而用户体验更好。

  • 使用 Network Cache 能对输出资源文件进行更好的命名，将来好做缓存，从而用户体验更好。

  • 使用 Core-js 对 js 进行兼容性处理，让我们代码能运行在低版本浏览器。

  • 使用 PWA 能让代码离线也能访问，从而提升用户体验。

 

 

   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

  1. 运行指令
npx webpack

1

此时我们会发现生成 3 个 js 文件，其中有一个就是提取的公共模块。

avatar
文章
阅读
粉丝