webpack常用构建优化总览

更新日期: 2019-10-21阅读: 1.9k标签: 优化

简介

读了《深入浅出webpack》总结一下常用的webpack的构建优化策略,可通过以下手段来提升项目构建时的速度


更精准的loader规则

将loader规则写清楚

仅让需要处理的文件,进入loader处理环节,如下

    rules: [{
      // 正则尽量准确
      test: /\.js$/,
      // 使用缓存,缓存后在文件未改变时编译会更快(缓存查找原理见补充1)
      use: ['babel-loader?cacheDirectory'],
      // 指定需要处理的目录
      include: path.resolve(__dirname, 'src')
      // 理论上只有include就够了,但是某些情况需要排除文件的时候可以用这个,排除不需要处理文件
      // exclude: []
    }]


更精准的查找目录

将查找路径设置精确

理论上我们项目的第三方依赖均应在自己的工程的node_modules下,所以我们可以设置查找目录,减少node的默认查找(默认查找方式见补充2)

module.exports = {
    resolve: {
        // 指定当前目录下的node_modules目录
        modules: [path.resolve(__dirname, 'node_modules')]
    }
}


更精准的扩展名

数量更多类型的文件尽量放在前面

平时写代码,我们都习惯直接写文件名,而不去写扩展名,那么解析则按照下面属性进行解析

module.exports = {
    extensions: ['.js', '.jsx', '.ts', '.tsx'],
}

默认值

extensions: [".js", ".json"]


使用动态链接库预编译大模块

使用动态链接库,提前编译大模块

原理请见补充3

新建一个文件webpack_dll.config.js,内容如下

const path = require('path');
const webpack = require('webpack');

// 复用的大模块放在这里,这样每次都不需要重新编译了
const vendors = [
  'react',
  'react-dom',
  'lodash'
];

module.exports = {
  mode: 'development',
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: '[name].js',
    library: '[name]',
  },
  entry: {
    vendors,
  },
  plugins: [
    new webpack.DllPlugin({
      path: path.resolve(__dirname, './dist/manifest.json'),
      name: '[name]',
    }),
  ],
};

执行webpack --config webpack_dll.config.js进行首次编译(如果更新版本需要再次编译)

然后在你的webpack配置文件中引入manifest.json

  plugins: [
    new webpack.DllReferencePlugin({
      manifest: require('./dist/manifest.json')
    })
  ],


多进程处理文件

使用HappyPack同时处理多个loader编译任务

为了发挥多核CPU电脑的功能,利用HappyPack将任务分发给多个子进程并发执行

const path = require('path');
const HappyPack = require('happypack');
// 共享5个进程池
const happyThreadPool = HappyPack.ThreadPool({ size: 5 });

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    // noParse: [/react\.production\.min\.js$/],
    rules: [{
      test: /\.js$/,
      // 和下面插件id一直,happypack才可以找到
      use: ['happypack/loader?id=babel'],
      include: path.resolve(__dirname, 'src')
    }]
  },
  plugins: [
    // 插件可以实例化多个
    new HappyPack({
      // 与上面对应
      id: 'babel',
      // 实际要使用的loader
      loaders: ['babel-loader?cacheDirectory'],
      // 默认开启进程数
      threads: 3,
      // 是否允许happyPack打印日志
      verbose: true,
      // 共享进程数,如果你使用超过一个happyplugin,官方建议共享进程池
      threadPool: happyThreadPool
    })
  ],
};

原理见补充4


多进程压缩文件

使用ParallelUglifyPlugin多进程同时压缩文件

ParallelUglifyPlugin是在UglifyJS基础上,增加了多进出处理的能力,加快了压缩速度

import ParallelUglifyPlugin from 'webpack-parallel-uglify-plugin';
 
module.exports = {
  plugins: [
    new ParallelUglifyPlugin({
      test,
      include,
      exclude,
      cacheDir,
      workerCount,
      sourceMap,
      uglifyJS: {
      },
      uglifyES: {
      }
    }),
  ],
};


减少监听文件

减少监听文件

原理见补充5

当我们使用webpack的watch功能进行文件监听时,更好的方式是控制监听目录,如下,排除node_modules减少对该目录监听,减少编译所需要循环的文件,提高检查速度

module.export = {
    watchOptions: {
        ignored: /node_modules/
    }
}


其他没那么重要的优化

更精准的mainFields

默认的这个值查找方式见官网点击此处

看了下react和lodash,只有一个main,目前来看使用es6看来还不普遍,所以这个值目前可能不太重要

module.exports = {
    resolve: {
        mainFields: ['main']
    }
}

第三方库映射

为什么这个不重要,我发现react直接导出的index.js则是根据环境判断使用哪份代码,目测来看并不需要进行循环依赖的处理

通过依赖,则可以直接使用打包后代码,而不需webpack去循环依赖

  resolve: {
    mainFields: ["main"],
    alias: {
      'react': path.resolve(__dirname, './node_modules/react/cjs/react.production.min.js')
    }
  }

不使用inline模式的devServer

原理见补充6

默认情况下,应用程序启用内联模式(inline mode)。这意味着一段处理实时重载的脚本被插入到你的包(bundle)中,并且构建消息将会出现在浏览器控制台。

当使用inline模式时,devServer会向每个Chunk中注入一段重载的脚本代码,但是其实一个页面只需要一次,所以当Chunk过多时,可以将inline设置为false

module.export = {
    devServer: {
        inline: false
    }
}


补充

补充1-cacheDirectory原理

当有设置cacheDirectory时,指定的目录将用来缓存loader的执行结果。之后的 webpack 构建,将会尝试读取缓存,来避免在每次执行时,可能产生的、高性能消耗的Babel重新编译过程。如果设置了一个空值 (loader: 'babel-loader?cacheDirectory') 或者 true (loader: babel-loader?cacheDirectory=true),loader 将使用默认的缓存目录 node_modules/.cache/babel-loader,如果在任何根目录下都没有找到 node_modules 目录,将会降级回退到操作系统默认的临时文件目录。

补充2-node的默认查找方式

  1. 查找当前目录下的node_modules目录,看是否有匹配项,如有,命中文件
  2. 寻找父目录的下的node_modules,如有,命中文件
  3. 按照这个规则一直往父目录搜索直到到根目录下的node_modules

补充3-动态链接库思想

大量项目中可以复用的模块只需要被编译一次,在之后的构建过程中被动态链接库包含的模块将不会重新编译,而是直接使用动态链接库中的代码。(注:如果升级依赖的模块版本,需要重新编译动态链接库)

补充4-HappyPack原理

webpack构建中,需要大量的loader转换操作,很耗时,由于nodejs是单线程的,如果想更好利用cpu的多核能力,可以开启多个进程,同时对文件进行处理;可以看到在配置文件中,我们每次将文件交给happypack-loader去处理,然后由happypack去调度来执行文件的处理(happypack采用哪个loaders进行处理,是通过id知道的)

补充5-文件监听原理

webpack会从入口触发,将所有的依赖项放到一个list里边,然后每次修改文件内容,回去遍历整个list里边的文件,看是否有编辑时间的变化,如果有的话则进行编译

补充6-自动刷新原理

  • 向要开发的网页中注入代理客户端代码,通过代理客户端去刷新整个页面(默认)
  • 将要开发的网页放进一个iframe,通过刷新iframe去看刷新效果

链接: https://www.fly63.com/article/detial/6526

js中for循环优化总结_如何提高程序的执行效率

在程序开发中,经常会使用到for循环的,但是很多人写的for循环效率都是比较低的,下面就举例说明,并总结优化for循环的方法,来提高我们程序的执行效率。

网站打开速度优化_如何提高网页访问速度技巧方法总结

网站的加载速度不仅影响着用户体验,也会影响搜索引擎的排名,在百度推出“闪电算法”以来,将网站首屏打开速度被列入优化排名行列,作为前端开发的我们需要如果来优化网站的打开速度呢?下面就整理挖掘出很多细节上可以提升性能的东西分享给大家

JS性能优化之文档片段createDocumentFragment

DocumentFragments是DOM节点。它们不是主DOM树的一部分。通常的用例是创建文档片段,将元素附加到文档片段,然后将文档片段附加到DOM树。在DOM树中,文档片段被其所有的子元素所代替。因为文档片段存在于内存中,并不在DOM树中

深入浅出代码优化﹣if/else

对于代码裡面的 if else,我们可以使用逻辑判断式,或更好的三元判断式来优化代码。除了可以降低维护项目的成本之外,还可以提升代码可读性。就让我们从最简单的 if else 例子开始吧。

微信小程序性能优化入门指南

小程序从发布到现在也已经有将近两年的时间,越来越来多的公司开始重视小程序生态带来的流量,今年也由于小程序平台对外能力的越来越多的开放以及小程序平台的自身优化,越来越多的开发者也自主的投入到小程序的开发当中

网络串流播放_HTML5如何优化视频文件以便在网络上更快地串流播放

无论你正在将 GIF 动图转换为 MP4 视频,还是手头已经有一大堆 MP4 视频,你都可以优化文件结构,以使得这些视频更快地加载和播放。通过重组 atoms 将 moov 放到文件开头,浏览器可以避免发送额外的 HTTP range request 请求来搜寻和定位 moovatom

​web项目优化_Web 服务器性能与站点访问性能优化

要优化 Web 服务器的性能,我们先来看看 Web 服务器在 web 页面处理上的步骤:Web 浏览器向一个特定的服务器发出 Web 页面请求; Web 服务器接收到 web 页面请求后,寻找所请求的 web 页面,并将所请求的 Web 页面传送给 Web 浏览器; 显示出来

前端性能优化之重排和重绘

浏览器下载完页面所有的资源后,就要开始构建DOM树,于此同时还会构建渲染树(Render Tree)。(其实在构建渲染树之前,和DOM树同期会构建Style Tree。DOM树与Style Tree合并为渲染树)

微信小程序代码优化总汇

写篇文章的目的,是以开放小程序代码的层面的优化。包括:条件判断将wx:if换成了hidden 、页面跳转请销毁之前使用的资源、列表的局部更新、小程序中多张图片懒加载方案、Input状态下隐藏input,应预留出键盘收起的时间

我是如何将页面加载时间从6S降到2S的?

生活在信息爆炸的今天,我们每天不得不面对和过滤海量的信息--无疑是焦躁和浮动的,这就意味着用户对你站点投入的时间可能是及其吝啬的(当然有一些刚需站点除外)。如何给用户提供迅速的响应就显得十分重要了

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!