웹팩 구성을 최적화하는 방법

이번에는 웹팩 구성을 최적화하는 방법과 웹팩 구성을 최적화하기 위한 주의사항에 대해 알려드리겠습니다. 아래는 실제 사례입니다.

최근 프로젝트로 바쁜 인프라 구축 기간이 지나고, 과거를 되돌아보고 새로운 것을 배우는 효과가 있기를 바라면서 최근 웹팩 최적화 조치를 기록하려고 합니다.

이 프로젝트는 vue family 버킷을 사용하며, vue-cli를 기반으로 빌드 구성이 개선되었습니다. 원래 webpack 구성과 관련하여 vue-cli#2.0 webpack 구성 분석 기사를 읽을 수 있습니다. 이 기사에서는 기본적으로 파일의 각 코드 줄을 자세히 설명하므로 webpack을 더 잘 이해하는 데 도움이 됩니다.

꼼꼼히 정리해본 결과 기본적으로 인터넷에 떠도는 포인트를 기준으로 최적화가 이루어졌습니다

1. 외부 구성을 통해 공통 라이브러리 추출, cdn 참조

2. CommonsChunkPlugin 적절하게 구성

3. 별칭을 잘 활용

4. dllplugin 사전 컴파일 활성화

5. happypack 멀티 코어 빌드 프로젝트

외부

문서 주소 https://doc.webpack-china.org/configuration/externals/

가져온 특정 패키지가 번들로 패키징되는 것을 방지하고 대신 런타임 시 외부에서 이러한 외부 종속성을 가져옵니다.

CommonsChunkPlugin

문서 주소 https://doc.webpack-china.org/plugins/commons-chunk-plugin/

CommonsChunkPlugin 플러그인은 독립 파일(청크라고도 함)을 생성하기 위한 선택적 기능입니다. 이 파일에는 여러 항목 청크가 포함되어 있습니다. 공개 모듈. 공통 모듈을 분리하면 최종 합성 파일을 처음에 한 번 로드한 후 이후 사용을 위해 캐시에 저장할 수 있습니다. 새 페이지에 액세스할 때마다 더 큰 파일을 로드하는 대신 브라우저가 캐시에서 일반 코드를 신속하게 가져오기 때문에 속도가 향상됩니다.

resolve.alias

문서 주소 https://doc.webpack-china.org/configuration/resolve/#resolve-alias

모듈 가져오기를 더 쉽게 만들기 위해 가져오기 또는 require에 대한 별칭을 만듭니다. 예를 들어 src/ 폴더 아래에 있는 일부 공통 모듈은 다음과 같습니다.

그러나 내 자신의 연습을 통해 마지막 세 가지 사항이 내 프로젝트에 가장 최적화되어 있습니다. 이 기사에서는 주로 다음 사항을 자세히 설명합니다

프로젝트를 패키징하는 데 걸리는 시간은 기본적으로 약 40초인 것으로 나타났습니다. 다음 최적화 단계를 거치는 데 얼마나 시간이 걸릴까요?

1. dllplugin을 사용하여 사전 컴파일 및 참조

처음에 Dll을 참조하는 이유는 무엇입니까? 인터넷에서 일부 기사를 검색한 후 webpack의 dll을 사용하면 빌드 속도를 높이는 것 외에도 또 다른 이점이 있다는 것을 발견했습니다.

Dll은 패키징된 후에는 독립적으로 존재합니다. 포함된 라이브러리가 추가, 삭제 또는 업그레이드되지 않는 한 해시는 변경되지 않습니다. 따라서 온라인 DLL 코드는 버전 릴리스로 자주 업데이트될 필요가 없습니다. Dll을 사용하여 패키징한 파일은 기본적으로 독립된 라이브러리 파일이므로 이러한 유형의 파일의 특징 중 하나는 크게 변경되지 않는다는 것입니다. 일반적으로 이러한 라이브러리 파일을 app.js로 패키징하면 다른 비즈니스 파일의 변경 사항이 빌드의 캐시 최적화에 영향을 미치므로 매번 npm 패키지에서

관련 파일을 다시 검색해야 합니다. DLL을 사용한 후 포함된 라이브러리가 업그레이드되지 않은 한, 늘리거나 줄여서 다시 포장할 필요가 없습니다. 이는 또한 빌드 속도를 향상시킵니다.

Dll을 사용하여 프로젝트를 최적화하는 방법

먼저 dll의 구성 파일

을 만들고 프로젝트에 필요한 타사 라이브러리를 도입합니다. 이러한 유형의 라이브러리의 특징은 버전 릴리스에 따라 자주 업데이트할 필요가 없으며 장기적으로 안정적이라는 것입니다.

rreee 기본 구성 매개변수는 기본적으로 webpack과 동일합니다. 최적화에 대해 읽어본 사람이라면 누구나 그 의미를 이해할 것이라고 생각하므로 설명하지 않겠습니다. 그런 다음 코드를 실행하여 파일을 컴파일합니다. (내 구성 파일은 빌드에 위치하며, 프로젝트 경로에 따라 아래 경로를 변경해야 합니다)

const webpack = require('webpack');
const path = require('path');
module.exports = {
 entry: {
  //你需要引入的第三方库文件
  vendor: ['vue','vuex','vue-router','element-ui','axios','echarts/lib/echarts','echarts/lib/chart/bar','echarts/lib/chart/line','echarts/lib/chart/pie',
   'echarts/lib/component/tooltip','echarts/lib/component/title','echarts/lib/component/legend','echarts/lib/component/dataZoom','echarts/lib/component/toolbox'],
 },
 output: {
  path: path.join(dirname, 'dist-[hash]'),
  filename: '[name].js',
  library: '[name]',
 },
 plugins: [
  new webpack.DllPlugin({
   path: path.join(dirname, 'dll', '[name]-manifest.json'),
   filename: '[name].js',
   name: '[name]',
  }),
 ]
};

실행이 완료되면 동일한 디렉터리 수준에 두 개의 새 파일이 생성됩니다. 하나는 항목 종속성의 압축 코드가 포함된 dist 폴더에 생성된 verdor.js이고, 다른 하나는 dll 폴더에 있는 verdor-입니다. Manifest.json은 각 라이브러리를 번호로 색인화하고 이름 대신 ID를 사용합니다.

接下去你只要去你的webpack配置文件的里的plugin中添加一行代码就ok了。

const manifest = require('./dll/vendor-manifest.json');
...
...,
plugin:[
  new webpack.DllReferencePlugin({
    context: dirname,
    manifest,
  }),
]

这时候再执行webpack命令，可以发现时间直接从40秒锐减到了20s左右，整整快了一倍有木有(不知道是不是因为自己依赖库太多了才这样的，手动捂脸)。

2.happypack多线程编译

一般node.js是单线程执行编译，而happypack则是启动node的多线程进行构建，大大提高了构建速度。使用方法也比较简单。以我项目为例,在插件中new一个新的happypack进程出来，然后再使用使用loader的地方替换成对应的id

var HappyPack = require('happypack');
...
...
modules:{
  rules : [
    ...
    {
      test: /\.js$/,
      loader:[ 'happypack/loader?id=happybabel'],
      include: [resolve('src')]
    },
    ...
  ]
},
...
...
plugin:[
  //happypack对对 url-loader,vue-loader 和 file-loader 支持度有限，会有报错，有坑。。。
  new HappyPack({
     id: 'happybabel',
     loaders: ['babel-loader'],
     threads: 4,//HappyPack 使用多少子进程来进行编译
  }),
  new HappyPack({
     id: 'scss',
     threads: 4,
     loaders: [
        'style-loader',
        'css-loader',
        'sass-loader',
     ],
  })
]

这时候再去执行编译webpack的代码，打印出来的console则变成了另外一种提示。而编译时间大概从20s优化到了15s左右(感觉好像没有网上说的那么大，不知道是不是因为本身js比重占据太大的缘故)。

3.善用alias

3.配合resolve，善用alias

本来是没有第三点的，只不过在搜索网上webpack优化相关文章的时候，看到用人提到把引入文件改成库提供的文件(原理我理解其实就是1.先通过resolve指定文件寻找位置，减小搜索范围；2.直接根据alias找到库提供的文件位置)。

vue-cli配置文件中提示也有提到这一点，就是下面这段代码

resolve: {
  //自动扩展文件后缀名，意味着我们require模块可以省略不写后缀名
  extensions: ['.js', '.vue', '.json'],
  //模块别名定义，方便后续直接引用别名，无须多写长长的地址
  alias: {
   'vue$': 'vue/dist/vue.esm.js',//就是这行代码，提供你直接引用文件
   '@': resolve('src'),
  }
 },

然后我将其他所有地方关于vue的引用都替换成了vue$之后，比如

// import 'vue';
import 'vue/dist/vue.esm.js';

时间竟然到了12s，也是把我吓了一跳。。。

然后我就把jquery，axios，vuex等等全部给替换掉了。。。大概优化到了9s左右，美滋滋，O(∩_∩)O~~

4.webpack3升级

本来是没第四点，刚刚看到公众号推出来一篇文章讲到升级到webpack3的一些新优点，比如Scope Hoisting(webpack2升级到webpack3基本上没有太大问题)。通过添加一个新的插件

// 2017-08-13配合最新升级的webpack3提供的新功能，可以使压缩的代码更小，运行更快
...
plugin : [
  new webpack.optimize.ModuleConcatenationPlugin(),
]

不过在添加这行代码之后，构建时间并没有太大变化，不过运行效率没试过，不知道新的效果怎么样

好了基本上感觉就是以上这些效果对项目的优化最大，虽然没有到网上说的那种只要3~4秒时间那么变态，不过感觉基本8,9秒的时间也可以了。

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

Angular 4中显示CSS样式

vue综合组件通信使用案例

위 내용은 웹팩 구성을 최적화하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!