项目性能优化之给dist文件夹中chunk-vendors.js做splitChunks分包，从而减少首屏加载时间

问题描述

我们项目做完，验收通过以后，就需要打包发布上线啦。于是我们执行命令：npm run build打dist包，打包完以后截图如下：

直接打包的chunk-vendors.js太大了

chunk-vendors.js文件太大了，所以我们需要将其优化一下，拆分一下

chunk-vendors.js是啥

chunk-vendors.js，顾名思义chunk(块/包)-vendors(供应商)，即为：不是自己写的模块包，也就是/node_modules项目目录的所有模块包。所以这个chunk-vendors.js文件大的原因其实就是，我们把第三方的包都打包在这一个文件上了，都糅在一块，肯定大啊，所以想办法把其做一个拆分。

使用optimization.splitChunks做分包

我们先看一下分包拆分以后打包的dist文件夹中的js文件大小

分包以后的效果图

这样的话，我们就把chunk-vendors.js文件由，原来的824kB拆分成一个个几十KB的包文件了，这样的话，生产环境加载的时候，就会快一些

splitChunks分包代码

我们以vue为例，在vue.config.js文件中加入以下代码。代码大家直接复制粘贴即可使用，也是笔者自己在生产环境中使用的哦。

    configureWebpack: config => {
        if (process.env.NODE_ENV !== 'production') return
        return {
            plugins: [
               // ......
            ],
            // 看这里：把chunk-vendors.js进行分包，提升资源加载速度，很有必要
            optimization: {
                /**
                 * runtimeChunk可选值有：true或'multiple'或'single'
                 * true或'multiple'会有每个入口对应的chunk。不过一般情况下
                 * 考虑到要模块初始化，设置为single就够多数情况下使用啦。
                 * 详情见官网：https://webpack.docschina.org/configuration/optimization/#optimizationruntimechunk
                 * */
                runtimeChunk: 'single',
                /**
                 * 以前是CommonsChunkPlugin，现在换成optimization.splitChunks。普通项目下方的配置就足够用啦
                 * 详情见官网：https://webpack.docschina.org/configuration/optimization/#optimizationsplitchunks
                 * */
                splitChunks: {
                    chunks: 'all', // 可选值：all，async 和 initial。all功能最强大，所以咱们就使用all
                    maxInitialRequests: Infinity, // 最大并行请求数，为了以防万一，设置无穷大即可
                    minSize: 20000, // 引入的模块大于20kb才做代码分割，官方默认20000，这里不用修改了
                    maxSize: 60000, // 若引入的模块大于60kb，则告诉webpack尝试再进行拆分
                    cacheGroups: {
                        vendors: {
                            test: /[\/]node_modules[\/]/, // 使用正则匹配node_modules中引入的模块
                            priority: -10, // 优先级值越大优先级越高，默认-10，不用修改
                            name(module) { // 设定分包以后的文件模块名字，按照包名字替换拼接一下
                                const packageName = module.context.match(/[\/]node_modules[\/](.*?)([\/]|$)/)[1]
                                return `npm.${packageName.replace('@', '')}`
                            },
                        },
                    },
                }
            }
        }
    },
复制代码

项目性能优化之用url-loader把小图片转base64，大图片使用image-webpack-loader压缩

问题描述

项目中常常会引入一些图片资源，什么jpg|jpeg|png|gif|ico之类的，正常情况下，我们需要做一下性能优化，看看如何大而化小、小而化了，提升生产环境资源加载速度。所以，本文记录一下大图片使用image-webpack-loader插件压缩一下、小图片使用url-loader转成base64格式，并比较前后优化差别。以下代码是笔者在生产环境使用的，亲测有效。大家直接复制粘贴即可

url-loader的使用

首先，url-loader和image-webpack-loader都依赖于file-loader，file-loader简言之就是一个资源加载模块，去找文件资源的loader，然后也可以给静态资源生成哈希值，即唯一标识身份证。一般不用配置。我们主要是通过url-loader和image-webpack-loader做相关对应项配置

下载url-loader和file-loader

cnpm i url-loader file-loader --save

使用url-loader转base64截图

未使用url-loader就是普通的图片加载，这里不赘述。我们主要是看转成base64的效果；因为下方还要说image-webpack-loader，所以代码放在最后

image-webpack-loader的使用

下载image-webpack-loader

这里大家注意，不要使用高版本的image-webpack-loader，否则可能出现错误，这里我使用的是6.0.0版本，大家可以使用这个版本。另外file-loader因为之前安装过了，所以，这里就不用安装了

cnpm i image-webpack-loader@6.0.0 --save

未使用image-webpack-loader截图

使用image-webpack-loader截图

对比两个图，我们可以看到使用image-webpack-loader压缩后，无论是大小还是加载时间，都优化了不少，所以这个loader还是可以的

两个loader的完整代码

以vue项目为例，在vue.config.js的chainWebpack加上以下代码即可

chainWebpack(config) {
    config.module.rule("images").test(/.(jpg|jpeg|png|gif|ico)$/) // 给这些图片类型做压缩
        .use("url-loader") // url-loader要搭配file-loader做图片压缩
        .loader("url-loader")
        .options({
            limit: 1024 * 12,// 小于12kb的图片压缩成base64，图片太大转成base64反而不太合适
            name: "static/img/[name].[ext]"//指定打包后的图片存放的位置，一般放在static下img文件夹里 name.ext分别为：文件名.文件后缀（按照原图片名）
        })
        .end() // 返回上一级 以便于继续添加loader
        .use('image-webpack-loader')
        .loader("image-webpack-loader")
        .options({
            disable: process.env.NODE_ENV == 'development' ? true : false, // 开发环境禁用压缩，生产环境才做压缩，提升开发调试速度
            mozjpeg: { quality: 60 }, // 压缩JPEG图像，压缩质量quality为60，范围0到100
            optipng: { enabled: true }, // 压缩PNG图像，enabled为true开启压缩
            pngquant: { quality: [0.65, 0.90], speed: 4 }, // 质量区间和速度就使用默认值吧
            gifsicle: { interlaced: false }, // Interlace gif for progressive rendering 默认false
            webp: { quality: 60 } // 压缩webp图片，压缩质量quality为60，范围0到100
        })
        .end() // 返回上一级 继续添加loader
        .enforce('post') // 表示先执行配置在下面那个loader，即image-webpack-loader
},
复制代码

项目性能优化之用compression-webpack-plugin插件开启gzip压缩，以vue为例

问题描述

本文以vue为例，记录一下，使用webpack插件compression-webpack-plugin开启gzip压缩的步骤流程，以及对比开启gzip压缩前后所需要的时间，得出结论：**这个插件的确能够做性能优化，减少加载的时间**react也是同一个道理，在此不赘述

前端配置之vue.config.js配置

第一步，下载compression-webpack-plugin

cnpm i compression-webpack-plugin@6.1.1 --save

注意，这里不能直接下载，需要下载低版本的。直接下载就是最新版的了，vue脚手架暂时不支持最新版的，所以就会报错：TypeError: Cannot read property 'tapPromise' of undefined。我这里下载是指定@6.1.1版本，是可以用的

第二步，vue.config.js使用

下方代码，直接复制粘贴使用即可

const CompressionPlugin = require('compression-webpack-plugin');//引入gzip压缩插件

// 暴露配置项，会被合并到webpack中去
module.exports = {
    chainWebpack(config) {
        // ......
    },
    configureWebpack: config => {
        // 开发环境不配置
        if (process.env.NODE_ENV !== 'production') return
        // 生产环境才去配置
        return {
            plugins: [
                new CompressionPlugin({ //此插件不能使用太高的版本，否则报错：TypeError: Cannot read property 'tapPromise' of undefined
                    // filename: "[path][base].gz", // 这种方式是默认的，多个文件压缩就有多个.gz文件，建议使用下方的写法
                    filename: '[path].gz[query]', //  使得多个.gz文件合并成一个文件，这种方式压缩后的文件少，建议使用
                    algorithm: 'gzip', // 官方默认压缩算法也是gzip
                    test: /.js$|.css$|.html$|.ttf$|.eot$|.woff$/, // 使用正则给匹配到的文件做压缩，这里是给html、css、js以及字体（.ttf和.woff和.eot）做压缩
                    threshold: 10240, //以字节为单位压缩超过此大小的文件，使用默认值10240吧
                    minRatio: 0.8, // 最小压缩比率，官方默认0.8
                    //是否删除原有静态资源文件，即只保留压缩后的.gz文件，建议这个置为false，还保留源文件。以防：
                    // 假如出现访问.gz文件访问不到的时候，还可以访问源文件双重保障
                    deleteOriginalAssets: false
                })
            ]
        }
    },
};
复制代码

这里配置完以后，暂时还不能使用，还需要后端做一下配置，这里后端以nginx为例

后端配置之nginx配置

下方代码，直接复制粘贴使用即可

    server {
        listen       80;
        server_name  localhost;
        location / {
            try_files $uri $uri/ /index.html;
            root C:/nginx-1.18.0/html/gzip/dist;
            index  index.html index.htm;
        }
        location /api/ {
            proxy_pass http://localhost:6666/;
        }
        
        # 主要是下方的gizp配置哦，直接复制粘贴就可以使用啦，亲测有效哦
        gzip on; # 开启gzip压缩
        gzip_min_length 4k; # 小于4k的文件不会被压缩，大于4k的文件才会去压缩
        gzip_buffers 16 8k; # 处理请求压缩的缓冲区数量和大小，比如8k为单位申请16倍内存空间；使用默认即可，不用修改
        gzip_http_version 1.1; # 早期版本http不支持，指定默认兼容，不用修改
        gzip_comp_level 2; # gzip 压缩级别，1-9，理论上数字越大压缩的越好，也越占用CPU时间。实际上超过2的再压缩，只能压缩一点点了，但是cpu确是有点浪费。因为2就够用了
                 # 压缩的文件类型 MIME类型，百度一下，一大把                                    # css             # xml             # 识别php     # 图片
        gzip_types text/plain application/x-javascript application/javascript text/javascript text/css application/xml application/x-httpd-php image/jpeg image/gif image/png application/vnd.ms-fontobject font/x-woff font/ttf;
                 # text                   # 早期js                 # js        # js的另一种写法                                                                                 # .eot字体                   # woff字体  # ttf字体
        gzip_vary on; # 是否在http header中添加Vary: Accept-Encoding，一般情况下建议开启       
    }
复制代码

未开启gzip压缩，加载时间图示

项目没有使用compression-webpack-plugin插件没开启的时候，我们发现时间能有好几百毫秒，加载资源时间是有点长了，未开启如下图：

开启gzip压缩，加载时间图示

gizp压缩多了一个.gz文件

注意开启gzip压缩以后，对应压缩文件中就会多了.gz的文件，比如字体压缩文件夹中：

当然别的js文件夹中也有.gz css文件夹中也有.gz 这里就不一一截图了，大家看自己的dist文件夹就可以看到了。接下来看开启了gzip压缩以后，到底优化了多少

看看最终性能优化如何

对比上方未开启gzip压缩以后，的确加载时间优化了不少。另外，从首屏加载而言，直观感受，也是快了一些。

响应头多了Content-Encoding: gzip

另外，如果开启gzip压缩，在http请求中，也可以看到响应头多了Content-Encoding: gzip，没开启gzip压缩是没这个的。如下图：