Webpack on Liangweidong's blog

前端工程化基石：Webpack 5 与 Babel 编译

Wed, 15 Aug 2018 00:00:00 +0800

为什么写这篇：Webpack 4 在 2018-02 正式发布（zero-config 概念），5 在 2018 之后逐步成为标准。即使 2024 年 Vite/Rspack 已经在性能上超越 Webpack，老项目的维护、monorepo 工具链、底层 loader 插件开发仍离不开它。理解 Webpack 的"打包图"思想，是所有前端工程化工具的根。

适用读者：刚开始接触前端构建工具的同学；想从零跑通"写 ES6 → 浏览器能跑"全流程的初学者。

前置知识：会写 npm install、了解 package.json、写过简单 HTML/JS。

1. 什么是 Webpack

Webpack 是一个静态模块打包器（static module bundler）。它从入口文件（entry）出发，递归解析所有 import/require，把 JS、CSS、图片、字体等所有静态资源当作"模块"处理，最终输出浏览器能直接加载的静态文件（bundle）。

核心思想：一切皆模块。import './style.css' 在 Webpack 眼里和 import './utils.js' 一样——只是需要不同的 loader 来"翻译"。

Webpack 4 大核心概念：

概念	一句话
Entry	入口，Webpack 从哪个文件开始构建依赖图
Output	打包后的文件输出到哪里
Loader	让 Webpack 能处理非 JS 文件（CSS/图片/TS/Vue 等）
Plugin	解决 loader 之外的所有事（压缩、热更新、清理 dist、环境变量注入…）

2. 最小可跑 demo

1
2
3
4
5


mkdir webpack-demo1 && cd webpack-demo1
npm init -y
npm install webpack webpack-cli --save-dev
npm install --save lodash
npx webpack

跑完会生成 dist/main.js。完整目录：

1
2
3
4
5
6
7
8


webpack-demo1/
├── dist/
│ └── main.js # 打包后的产物
├── node_modules/
├── package.json
├── package-lock.json
└── src/
 └── index.js # 你的入口文件

src/index.js：

1
2
3
4
5
6
7
8
9


import _ from 'lodash'

function component() {
 const element = document.createElement('div')
 element.innerHTML = _.join(['Hello', 'webpack'], ' ')
 return element
}

document.body.appendChild(component())

跑 npx webpack 时，Webpack 会自动：

把 src/index.js 当作入口
解析 import _ from 'lodash' → 把 lodash 整包也打进来
把 dist/main.js 作为默认输出

默认约定：Webpack 4+ 引入 zero-config 概念，不写 webpack.config.js 也能跑——entry 默认为 src/index.js，output 默认为 dist/main.js，mode 默认为 production。

3. Babel：让"新语法"跑到"老浏览器"

Babel 是一个 JavaScript 编译器（准确说叫"转译器" transpiler）：

输入：用下一代 JavaScript 语法（ES2015+、JSX、TypeScript）写的代码
输出：浏览器能兼容的 JavaScript 代码

1
2
3
4
5
6
7


// 输入（你写的）
const greet = (name) => `Hello, ${name}!`

// 输出（babel 编译后）
var greet = function greet(name) {
 return 'Hello, ' + name + '!'
}

Why：浏览器的 JavaScript 引擎对新语法的支持永远滞后于规范。2015 年 ES2015 发布时，主流浏览器（IE11、UC、老 Safari）都不支持 const / 箭头函数 / class。Babel 让开发者能写"未来语法"，由它编译到"老语法"。

3.1 Webpack 集成 Babel 7

1

npm install -D babel-loader @babel/core @babel/preset-env

webpack.config.js：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


module.exports = {
 module: {
 rules: [
 {
 test: /\.js$/,
 exclude: /node_modules/,
 use: {
 loader: 'babel-loader',
 options: {
 presets: ['@babel/preset-env']
 }
 }
 }
 ]
 }
}

@babel/preset-env 是"智能预设"——你告诉它目标浏览器范围（browserslist 配置），它自动决定要转译哪些语法。

package.json 加上 browserslist：

1
2
3
4
5
6
7
8


{
 "browserslist": [
 "> 1%",
 "last 2 versions",
 "not dead",
 "ie >= 11"
 ]
}

小贴士：现代项目（Chrome 90+、Node 18+）可以直接在 browserslist 里写 "defaults, not IE 11"，Babel 就只对真正需要的目标做 polyfill，bundle 体积能少 30%+。

4. 为什么需要 –save 和 –save-dev

这是新人最容易搞混的概念：

命令	写入 `package.json` 哪个字段	含义
`npm install --save`（`-S`）	`dependencies`	生产环境需要的包（运行时被打进 bundle）
`npm install --save-dev`（`-D`）	`devDependencies`	开发环境才需要的包（构建、测试、代码检查）

1
2


npm install webpack webpack-cli --save-dev # 构建工具，上线不需要
npm install lodash --save # 运行时要用 lodash

执行 npm install（不带包名）时，npm 会同时安装 dependencies 和 devDependencies 中的所有模块。生产环境（npm install --production 或 NODE_ENV=production）只装 dependencies。

小贴士：Vue/React 框架本身（vue、react、react-dom）要 --save，而 vue-loader、@babel/preset-env、webpack、eslint 都要 --save-dev。

5. 常见 loader / plugin 一览

类别	名称	用途
JS	`babel-loader`	配合 Babel 转译 JS/JSX/TS
	`ts-loader`	直接用 TypeScript 编译器
CSS	`css-loader`	把 CSS 变成 JS 模块（`import './style.css'`）
	`style-loader`	把 CSS 注入到 `<style>` 标签
	`postcss-loader`	自动加浏览器前缀、CSS 嵌套等
	`sass-loader` / `less-loader`	编译 SCSS / Less
图片/字体	`asset/resource` (Webpack 5 内置)	输出文件，导出 URL
	`asset/inline` (Webpack 5 内置)	内联为 base64（小图）
框架	`vue-loader`	解析 `.vue` 单文件组件
文件	`file-loader`（已废弃）	旧版输出文件（Webpack 5 用 asset/resource）
压缩	`terser-webpack-plugin`（Webpack 5 默认）	压缩 JS
	`css-minimizer-webpack-plugin`	压缩 CSS
	`compression-webpack-plugin`	生成 `.gz` 文件
其他	`html-webpack-plugin`	自动生成 HTML 并注入 bundle
	`clean-webpack-plugin` / `output.clean`	每次构建清空 dist
	`mini-css-extract-plugin`	CSS 抽离成独立文件（不再内联到 JS）
	`webpack-dev-server`	启动开发服务器 + HMR 热更新
	`webpack-bundle-analyzer`	可视化分析 bundle 体积

Webpack 5 重要变化：

资源模块（Asset Modules） 内置了 4 种类型（asset/resource / asset/inline / asset/source / asset），不再需要 file-loader / url-loader

持久化缓存 默认开启，构建速度提升 5-10 倍

Module Federation 微前端方案正式 GA

Tree Shaking 加强，对 CommonJS、sideEffects 字段支持更好

6. 从 Webpack 1 到 5：核心演进

版本	年份	关键特性
1.x	2014	第一版，配置繁琐但改变前端
2.x	2017	引入 tree shaking、scope hosting
3.x	2017	`Scope Hoisting`、魔法注释 `/* webpackChunkName */`
4.x	2018-02	zero-config（默认 entry/output）、mode、sideEffects
5.x	2020-10	资源模块、持久化缓存、Module Federation、长期缓存

大版本迁移痛点：Webpack 4 → 5 主要是 file-loader/url-loader/raw-loader 替换为 asset modules，以及 node-polyfill-webpack-plugin 处理内置模块的 polyfill（如 crypto、buffer）。

7. 常见问题与排错

7.1 报错 “Module not found”

99% 是路径写错。Webpack 5 默认不允许绝对路径，必须写相对路径或配 resolve.alias。

1
2
3
4
5
6


// webpack.config.js
resolve: {
 alias: {
 '@': path.resolve(__dirname, 'src')
 }
}

7.2 报错 “Can’t resolve ‘vue’ in …”

依赖没装对版本，或在 vue.config.js 配了 externals 但忘记在 HTML 里用 CDN 引。先 rm -rf node_modules && npm install 排除 80% 情况。

7.3 构建慢 / 体积大

优化项	作用
`mode: 'production'`	自动启用 tree shaking + 压缩
`optimization.splitChunks`	把 node_modules 抽成 vendor，浏览器缓存更久
`externals: { vue: 'Vue' }`	通过 CDN 引入 Vue/React，业务 bundle 体积减半
`productionSourceMap: false`	不生成 .map 文件（生产环境不需要）
`terser-webpack-plugin` 配 `parallel: true`	多进程压缩
升级到 Webpack 5	持久化缓存，开机慢、增量快

7.4 浏览器缓存命中低

1
2
3
4


output: {
 filename: '[name].[contenthash:8].js',
 chunkFilename: '[name].[contenthash:8].chunk.js'
}

contenthash 是内容哈希——文件没变，文件名不变，浏览器强缓存命中；文件改了，文件名变，强制刷新。

小结：Webpack 学习路线

会用：跑通 npx webpack 跑一个 demo → 配 webpack.config.js 加上 babel/css-loader
会配：理解 entry/output/loader/plugin/mode 五大件
会调：会用 splitChunks / contenthash / analyzer 优化产物体积
会写 loader/plugin：读懂 Webpack 的 tapable 钩子系统，写一个自定义插件
会迁移：Webpack 4 → 5，老项目升级

下一步：2024 年起，更多新项目直接用 Vite（开发时按需 ESM、生产时 Rollup 打包），启动速度比 Webpack 快 10-100 倍。但 Vite 的生产构建底层还是 Rollup，且大量 Vite 插件的接口与 Webpack 兼容。本文讲的 loader/plugin 思想 100% 适用。

参考资料

高性能前端：HTTP 缓存 / CDN / gzip 与 Vue 首屏优化实战

Sat, 15 Apr 2017 00:00:00 +0800

为什么写这篇：2017 年 HTTP/2 全面铺开、vue-cli@3.4 默认开了很多性能优化（splitChunks、tree-shaking、terser）。本文把"代码 + 服务器 + 框架"三层优化串起来——一个真实项目把首屏从 10s 压到 2s。

适用读者：Vue 2/3 项目的性能优化负责人；想系统理解 HTTP 缓存 / CDN / gzip 的初中级前端。

前置知识：会用 vue-cli 启项目；知道 Nginx 配置文件长什么样。

前端性能优化的三层模型
代码层面：CSS 位置与请求数
代码层面：减少 HTTP 请求
代码层面：CDN 与外部资源
代码层面：Gzip 压缩
服务器层面：Nginx gzip 配置
服务器层面：HTTP/2 多路复用
服务器层面：缓存策略
Vue 实战：compression-webpack-plugin + externals + sourceMap
首屏时间从 10s 到 2s 的真实案例

1. 前端性能优化的三层模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


┌─────────────────────────────────────┐
│ Layer 1：代码层面（HTML/CSS/JS） │
│ - 样式表放 head、脚本放 body 底部 │
│ - 雪碧图 / 内联小图 / 合并脚本 │
│ - 使用外部 JS/CSS（可缓存） │
│ - 使用 CDN 引入公共库 │
└─────────────────────────────────────┘
 ↓
┌─────────────────────────────────────┐
│ Layer 2：服务器层面（Nginx） │
│ - 开启 gzip 压缩 │
│ - 开启 HTTP/2（需 HTTPS） │
│ - 强缓存（Expires / Cache-Control）│
│ - 协商缓存（ETag / Last-Modified）│
└─────────────────────────────────────┘
 ↓
┌─────────────────────────────────────┐
│ Layer 3：Vue 专项（vue-cli 3+） │
│ - 拆 vendor（splitChunks） │
│ - externals 走 CDN │
│ - productionSourceMap: false │
│ - compression-webpack-plugin 预 gzip│
└─────────────────────────────────────┘

Why 三层都要做：单做某一层效果有限。代码层减体积（KB→KB）、服务器层减传输（KB→10%×KB）、框架层减请求数（多个 chunk 复用连接）。

2. 代码层面：CSS 位置与请求数

2.1 样式表放 head

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <title></title>
 <!-- ✅ 把 CSS 放 head，避免 FOUC（无样式内容闪烁） -->
 <link rel="stylesheet" href="example.css">
</head>
<body>
</body>
</html>

Why：浏览器渲染流水线是"解析 HTML → 遇到 CSS 阻塞渲染"。把 CSS 放最前面，能让浏览器一拿到 CSS 就开始构建 CSSOM，尽早完成首次绘制。

2.2 脚本放 body 底部

1
2
3
4
5
6


<body>
 <!-- 页面内容 -->

 <!-- ✅ 脚本放 body 底部，不阻塞页面渲染和图片下载 -->
 <script src="example.js"></script>
</body>

Why：<script> 标签默认阻塞——浏览器遇到 <script> 会停下后续的 HTML 解析，去下载并执行脚本。把脚本放底部（或加 defer / async）能避免这个阻塞。

2.3 使用外部 JS/CSS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<!-- ✅ 推荐：外部文件，可被浏览器缓存 -->
<link rel="stylesheet" href="example.css">
<script src="example.js"></script>

<!-- ❌ 不推荐：内联到 HTML 里，每次都重新下载 -->
<style>
 /* code */
</style>
<script>
 /* code */
</script>

例外：极小的关键 CSS（如首屏字体样式）可内联——critical CSS 提取是另一项优化技术。

3. 代码层面：减少 HTTP 请求

Why 重要：HTTP/1.1 时代浏览器对同一域名的并发请求数有限制（Chrome 6 个）。每个请求都有 TCP 握手、TLS 握手、HTTP 头开销。请求越少越好。

3.1 雪碧图（CSS Sprites）

把多个小图标合到一张 PNG，用 background-position 定位：

1
2
3


.icon-home { background: url(sprite.png) 0 0; }
.icon-user { background: url(sprite.png) -30px 0; }
.icon-cart { background: url(sprite.png) -60px 0; }

现代替代：SVG sprite / iconfont（Iconfont.cn / iconify）。SVG 可缩放、可改色、HTTP 请求少。

3.2 内联小图（base64）

1

<img src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/..." />

适用：小于 10KB 的图片（icon、二维码、小 logo） 不适用：大图（base64 比原图大 33%）

3.3 合并脚本与样式

1
2
3
4
5
6
7
8
9


拆得太细：
- /js/jquery.js
- /js/bootstrap.js
- /js/app.js
- /js/utils.js

合并后：
- /js/vendors.min.js
- /js/app.min.js

Webpack 自动化：mode: production 时 optimization.concatenateModules 自动合并。

4. 代码层面：CDN 与外部资源

4.1 为什么要用 CDN

CDN（Content Delivery Network）——把静态资源分发到全球各地的边缘服务器。用户访问时从最近的边缘节点拉资源，降低 RTT（往返时延）。

1
2
3


<!-- 从 CDN 引入 Vue / React -->
<script src="https://cdn.jsdelivr.net/npm/vue@3/dist/vue.global.js"></script>
<script src="https://unpkg.com/react@18/umd/react.production.min.js"></script>

4.2 公共 CDN 服务

服务	特点
jsDelivr	全球 750+ 节点，自动 gzip/brotli，支持 npm/GitHub
unpkg	npm 包直链，简单
BootCDN	国内公司维护，国内访问快
CDNJS	Cloudflare 维护

4.3 HTTP/2 优势

多路复用：一个 TCP 连接并行多个请求，告别"6 个并发限制"
头部压缩：HPACK 算法把重复 header 压缩 80%+
服务器推送：服务器主动把后续资源推给客户端（已弃用）

前置条件：必须配 HTTPS——HTTP/2 规范要求加密。

5. 代码层面：Gzip 压缩

5.1 为什么 gzip 能省 50%-70%

1
2


原始 JS： 300 KB
gzip 后： 90 KB （节省 70%）

原理：gzip 用 LZ77 + Huffman 编码，把重复的字符串（如变量名、关键字、空白）替换为指针。文本类资源（JS/CSS/HTML）压缩比 60-80%，图片/视频已压缩过再 gzip 收益小（不到 5%）。

5.2 浏览器支持

1

Accept-Encoding: gzip, deflate, br

gzip：所有浏览器支持
br（Brotli）：Chrome / Firefox / Safari，压缩比比 gzip 高 15-20%
deflate：兼容老 IE，已基本被 gzip 替代

5.3 在 Node.js 中间件启用

1
2
3


// Express
const compression = require('compression')
app.use(compression())

6. 服务器层面：Nginx gzip 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 开启 gzip
gzip on;
gzip_static on; # 优先用预压缩的 .gz 文件
gzip_min_length 1k; # 大于 1K 才压缩
gzip_buffers 4 16k;
gzip_http_version 1.1; # 1.1 起步才支持
gzip_comp_level 2; # 1-9，越高越费 CPU
gzip_types
 text/plain
 application/javascript
 application/x-javascript
 text/javascript
 text/css
 application/xml
 application/xml+rss;
gzip_vary on; # 配合 Vary 头，CDN 能分别缓存 gzip / br
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6]\."; # IE 6 及以下不支持

7. 服务器层面：HTTP/2 多路复用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 启用 HTTP/2（必须先配 HTTPS）
server {
 listen 443 ssl http2;
 server_name example.com;

 ssl_certificate /path/to/fullchain.pem;
 ssl_certificate_key /path/to/private.key;

 # 其余配置...
}

What “多路复用” 感受：HTTP/1.1 时代，加载 10 个 JS 文件要排队等 6 个并发槽（剩余 4 个等前 6 个完）；HTTP/2 时代，10 个 JS 文件可以同时下载——首屏时间可能从 3s 降到 1.5s。

8. 服务器层面：缓存策略

8.1 强缓存：Expires / Cache-Control

1
2
3
4
5


# 给静态资源加 1 天强缓存
location ~.*\.(svg|woff|js|css)$ {
 root /yourFilePath;
 expires 1d;
}

响应头：
1
expires: Thu, 30 May 2019 20:51:42 GMT
浏览器看到这个头，在到期前不再发请求，直接用本地缓存。

HTTP/1.1 推荐用 Cache-Control 替代 Expires（避免客户端/服务端时钟不同步）：

1
2
3


server {
 add_header Cache-Control max-age=72000; # 20000 小时 ≈ 833 天
}

最强缓存（10 年）：

1
2
3


location ~.*\.(js|css)$ {
 add_header Cache-Control "public, max-age=315360000";
}

8.2 协商缓存：ETag / If-None-Match

为什么需要协商缓存：强缓存过期后，浏览器必须问服务器"我缓存里这份还能用吗"——服务器返回 304 Not Modified（不返回 body）或 200 OK（新内容）。

1
2
3
4
5
6


请求：
If-None-Match: "abc123-etag"

响应（资源未变）：
HTTP/1.1 304 Not Modified
ETag: "abc123-etag"

Vue CLI 默认行为：每个静态资源都生成 ETag，文件名带 contenthash，过期后再请求自动 304。

8.3 强缓存 vs 协商缓存

策略	优点	缺点
强缓存	零请求	资源更新延迟（必须等过期）
协商缓存	实时更新	仍要发请求（带 If-None-Match）

最佳实践：

HTML 文件：不缓存或 no-cache（必须每次校验）

带 contenthash 的 JS/CSS：强缓存 1 年

图片/字体：强缓存 30 天

接口数据：协商缓存或不缓存

9. Vue 实战：compression-webpack-plugin + externals + sourceMap

写作背景：vue-cli@3.4 + Vue 2.6.6。这套配置至今仍适用（Vue 3 改 Vite 后的 vite-plugin-compression 是同一思路）。

9.1 安装

1

npm install compression-webpack-plugin --save-dev

9.2 vue.config.js 完整优化配置

 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


const CompressionWebpackPlugin = require('compression-webpack-plugin')

const ENV = process.env.NODE_ENV || 'development'

module.exports = {
 configureWebpack: config => {
 if (ENV === 'production') {
 // 1. 预 gzip 压缩
 config.plugins.push(
 new CompressionWebpackPlugin({
 algorithm: 'gzip',
 test: /\.(js|css|html)$/,
 threshold: 10240, // 大于 10KB 才压
 minRatio: 0.8
 })
 )

 // 2. 外部 CDN 化（业务 bundle 不再包含 Vue / VueRouter / Axios）
 config.externals = {
 'vue': 'Vue',
 'vue-router': 'VueRouter',
 'axios': 'axios'
 }
 }
 },

 // 3. 关闭生产环境的 sourceMap（节省几百 KB + 防源码泄露）
 productionSourceMap: false
}

9.3 index.html 配合 externals

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<body>
 <div id="app"></div>

 <!-- 仅在生产环境引入 CDN，dev 时 webpack 自己注入 -->
 <% if (NODE_ENV === 'production') { %>
 <script src="https://cdn.bootcss.com/vue/2.6.10/vue.min.js"></script>
 <script src="https://cdn.bootcss.com/vue-router/3.0.2/vue-router.min.js"></script>
 <script src="https://cdn.bootcss.com/axios/0.18.0/axios.min.js"></script>
 <% } %>
</body>

注意：vue.config.js 里的 externals 键名要与 CDN 暴露的全局变量名大小写一致——'vue': 'Vue'（小写 vue 是 import 名，大写 Vue 是全局变量）。

9.4 为什么这样能把首屏从 10s 压到 2s

优化项	节省
预 gzip	静态资源体积 -70%
externals	业务 bundle 减半（~500KB → 250KB）
productionSourceMap: false	节省 200-500KB 隐藏文件
拆 vendor（vue-cli 默认）	利用浏览器强缓存
配合 nginx gzip + HTTP/2	传输再减 70%

作者实测：个人站点首页从 10s 降到 2s（4G 网络 + Chrome 70）。

10. 首屏时间从 10s 到 2s 的真实案例

阶段	体积	首屏时间	优化项
初始版本	1.2MB	10s	无
加 gzip	480KB	6s	nginx gzip on
加 CDN	320KB	4s	externals + bootcss
加 HTTP/2	320KB	3s	listen 443 ssl http2
强缓存 + 预 gzip	320KB	2s	完整组合

压测工具：

Chrome DevTools → Network 面板（看瀑布图、size、time）

Lighthouse（自动打分，给出优化建议）

WebPageTest.org（多地点、多浏览器测试）

curl -w '%{time_total}\n' -o /dev/null -s <URL>（CI 中压测接口）

小结

前端性能优化不是单点突破，是**“代码 + 服务器 + 框架"三层联动**。优先级：

先量后优：用 Lighthouse / WebPageTest 跑一次，定位瓶颈
后端优先：开 gzip + HTTP/2 + 强缓存，能秒减 70% 体积
代码层：拆 chunk + externals + 雪碧图
框架层：Vue 用 compression-webpack-plugin，React 用 vite-plugin-compression
持续监控：接 Sentry / 自建 RUM，监控真实用户的 FCP、LCP

下一步：本文专注"前端资源加载"层。Web Vitals 时代要看 LCP（Largest Contentful Paint）、CLS（Cumulative Layout Shift）、INP（Interaction to Next Paint）三大指标——单看"首屏时间"已经不够。