Webpack打包体积与速度优化

webpack打包时会将所有的依赖的第三方库打包在vendor文件中,当依赖的库比较多时,会导致vendor文件体积很大。

几种优化方式:

1.将不常变动的第三方库使用cdn的方式引入,写在script标签中,并且在webpack的配置文件中,配置external,webpack在打包的时候就不会打包进去。

2.dllplugin,将不经常变化的框架打包到dll中。

3.使用splitchunks进行代码的拆分。

打包速度方面的优化:

1.webpack默认使用uglify进行打包,是单线程的打包模式,可以使用异步的加载方式,happypack、parellelUglify多线程运行。

2.使用路由懒加载的方式,例如在vue-router的配置中,component属性使用按需加载的方式,const foo  = resolve => require(./foo.vue,resolve);

原文地址:https://www.cnblogs.com/bounceFront/p/9242785.html

时间: 2024-09-30 15:43:34

Webpack打包体积与速度优化的相关文章

webpack打包体积优化

webpack打包的体积越小,对于部署应用的网站来说,性能越好,加载速度越快. 1. 分析打包文件 1. 生成统计信息文件 首先需要通过webpack命令生成统计信息的文件.在package.json的脚本中添加命令 "scripts": { "stats": "webpack --config webpack.prod.js --profile --json > stats.json", //... } 上面的命令会在根目录下生成一个st

[转] Webpack 打包优化之体积篇

谈及如今欣欣向荣的前端圈,不仅有各类框架百花齐放,如Vue, React, Angular等等,就打包工具而言,发展也是如火如荼,百家争鸣:从早期的王者Browserify, Grunt,到后来赢得宝座的 Gulp, 以及独树一帜的 fis3, 以及下一代打包神器 Rollup :在 browserify,grunt,gulp,rollup,webpack 可以一窥其中部分对比.在本文要探究的是,当前打包工具绝对霸者 Webpack. Webpack Package optimization W

Webpack 打包优化之体积篇

谈及如今欣欣向荣的前端圈,不仅有各类框架百花齐放,如Vue, React, Angular等等,就打包工具而言,发展也是如火如荼,百家争鸣:从早期的王者Browserify, Grunt,到后来赢得宝座的 Gulp, 以及独树一帜的 fis3, 以及下一代打包神器 Rollup :在 browserify,grunt,gulp,rollup,webpack 可以一窥其中部分对比.在本文要探究的是,当前打包工具绝对霸者 Webpack. Webpack Package optimization W

webpack打包经验——处理打包文件体积过大的问题

前言 最近对一个比较老的公司项目做了一次优化,处理的主要是webpack打包文件体积过大的问题. 这里就写一下对于webpack打包优化的一些经验. 主要分为以下几个方面: 去掉开发环境下的配置 ExtractTextPlugin:提取样式到css文件 webpack-bundle-analyzer:webpack打包文件体积和依赖关系的可视化 CommonsChunkPlugin:提取通用模块文件 提取manifest:让提取的公共js的hash值不要改变 压缩js,css,图片 react-

Webpack打包效率优化篇

Webpack基础配置: 语法解析:babel-loader 样式解析:style-loader css解析:css-loader less解析:less-loader 文件解析:url-loader(file-loalder) 性能分析:webpack-bundle-analyzer 代码: var path = require('path'); var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyz

Webpack编译速度优化实战

当你的应用的规模还很小时,你可能不会在乎Webpack的编译速度,无论使用3.X还是4.X版本,它都足够快,或者说至少没让你等得不耐烦.但随着业务的增多,嗖嗖嗖一下项目就有上百个组件了,也是件很简单的事情.这时候当你再独立编前端模块的生产包时,或者CI工具中编整个项目的包时,如果Webpackp配置没经过优化,那编译速度都会慢得一塌糊涂.编译耗时10多秒钟的和编译耗时一两分钟的体验是迥然不同的.出于开发时的心情的考虑,加上不能让我们前端的代码编译拖累整个CI的速度这两个出发点,迫使我们必须去加快

基于CommonsChunkPlugin,webpack打包优化

前段时间一直在基于webpack进行前端资源包的瘦身.在项目中基于路由进行代码分离,http://www.cnblogs.com/legu/p/7251562.html.但是打包的文件还是很大,特别是通过CommonsChunkPlugin的async:true打包的chunk的公共包不可控.今天就通过CommonsChunkPlugin插件的理解,来优化这个问题 问题描述详细些,我们的打包是基于router进行的chunk分割,比如router有10个,router1,router2用到了ec

webpack打包优化并开启gzip

应用场景:项目使用webpack2.x进行打包,打包后静态资源通过nginx转发配置: 问题:webpack打包后的资源文件特别,特别大,没打包之前页面一个页面js有2M左右(其中已经抽离了css)? 优化一:一看js这么大肯定是没有关闭source-map,先将webpack配置文件中dev-tool:false, 优化二:使用compresion-webpack-plugin插件将静态资源压缩,并生成.gz文件,配置如下: 具体用法请参照:http://www.css88.com/doc/w

性能优化 - 查看 webpack 打包后所有的依赖关系(webpack 可视化工具)

查看 webpack 打包后所有组件与组件间的依赖关系,针对多余的包文件过大, 剔除首次影响加载的效率问题进行剔除修改,本次采用的是 ==webpack-bundle-analyzer(可视化视图查看器)== == 介绍1:webpack-bundle-analyzer(可视化)== 将捆绑内容表示为方便的交互式可缩放树形图 如下效果图: 模块功能: 意识到你的文件打包压缩后中真正的内容 找出哪些模块组成最大的大小 找到错误的模块 优化它! 最好的事情是它支持缩小捆绑!它解析它们以获得实际大小的