第1章前端性能瓶颈

1、前端性能瓶颈：为什么需要代码分割？

大家好，我是这门课的主讲人。今天咱们聊聊一个老生常谈、但又绕不开的话题——代码分割。

说实话，我刚入行那会儿，觉得前端项目嘛，打包成一个文件就完事了。直到我第一次接手一个大型后台管理系统……那个 JS 文件，足足有 3MB 多。用户打开页面，白屏了整整 5 秒。老板站在我身后，那眼神，我到现在都记得。

从那以后，我彻底明白了：代码分割不是锦上添花，而是刚需。

下面我从三个维度，掰开揉碎了讲讲，为什么我们需要它。

你想想看，一个用户打开你的网页，浏览器要干的第一件事是什么？下载 JS 文件。

假设你的项目有 200 个组件，全部打包成一个 bundle.js，大小 2MB。用户网络再好，也得花个 1-2 秒下载。要是碰上 3G 网络，或者信号不好的地铁里……嗯，用户可能直接就关掉页面了。

我做过一个统计：

看到了吧？加载时间直接差了一个数量级。代码分割的核心思路很简单：用户需要什么，就加载什么。不需要的代码，先放一放，等用户真正要用的时候再加载。

核心观点： 代码分割的本质，是把「一次性加载」变成「按需加载」。用户看到的第一个页面，只加载它自己需要的代码。

首屏渲染时间，说白了就是用户看到「有意义的内容」需要多久。

我记得有一次，一个电商项目上线前，测试发现首屏渲染时间高达 4.2 秒。排查下来，问题出在一个「用户评论」组件上。这个组件引了一个第三方的富文本编辑器，光这个编辑器就 500KB。

但问题是——用户打开首页，根本看不到评论啊！ 评论在页面底部，用户得往下翻两屏才能看到。

这就是典型的「加载了不需要的代码」。我们做了代码分割后，把这个评论组件单独拆出来，用 React.lazy 配合 Suspense 做懒加载。结果呢？首屏渲染时间降到了 1.1 秒。

为什么会这样？因为浏览器解析 JS 是阻塞渲染的。你加载的 JS 越多，浏览器就得花越多时间去解析、编译、执行。这段时间里，页面就是一片空白。

一个小技巧： 我个人习惯把「首屏必须用到的代码」控制在 100KB 以内。超过这个数，我就会考虑是不是有什么组件可以延迟加载。

用户体验这个东西，说起来有点玄，但说白了就是别让用户觉得卡。

你想想看，用户点击了一个按钮，结果页面卡住了 2 秒，然后才弹出对话框。这种体验，用户会怎么想？「这网站真慢。」

我曾经在一个项目中，遇到过一个「数据导出」功能。这个功能用到了一个很大的 Excel 处理库，打包后 800KB。用户点击「导出」按钮时，整个页面会卡住，因为浏览器正在加载并解析这个库。

我们怎么解决的？把导出功能做成一个单独的 chunk。用户点击按钮时，才去加载这个 chunk。加载过程中，显示一个 loading 动画。加载完成后，再执行导出逻辑。

这样一来，用户点击按钮后，页面不会卡住，只是 loading 图标转几圈。体验上好了不止一个档次。

避坑指南： 我曾经犯过一个错误——把所有懒加载的组件都放在一个 chunk 里。结果用户点击某个功能时，要加载一个 1MB 的大文件，反而更慢了。记住：懒加载的粒度要适中，不是越细越好。

代码分割解决的核心问题，其实就是三个字：别浪费。

说白了，代码分割就是把大包拆成小包，按需加载。这个思路听起来简单，但实际做起来，有很多细节和坑。接下来的章节，我会带大家一步步实战，从 Webpack 配置到 React/Vue 的懒加载实现，再到路由级别的代码分割。