后台不只是“能跑就行”，后台也要有素质，有颜值，有速度。
毕竟现在都 2025 年了，谁的后台打开还要等 2 秒，那是要被用户捏爆魔丸的。
今天我们就用 Lighthouse + Chrome DevTools，把后台性能一步一步从 惨不忍睹 → 飞起到 90+ 。
不吹牛，只要按我下面这些步骤走，你的后台也能飞。
一、后台为什么要优化性能？
以前大家都觉得后台给内部用、性能无所谓。
现在不一样了：
- H5 管理后台可能随时在线上被嵌入
- SPA 后台页面越来越复杂
- React / Vite / 各种 UI 库占 JS 量巨大
- 客户会吐槽：“你这后台怎么这么卡？？？”
- 公司考核看 Lighthouse 得分（别问我怎么知道）
你不优化？
别人用你的后台会想给你一耳屎：
“你这后台跑得这么慢，是怎么写出来的？”
—— 亲爱的测试小姐姐
二、性能优化的第一步：跑 Lighthouse
Chrome → Inspect → Lighthouse → Generate report
你会看到：
- 性能（Performance）
- 可访问性（Accessibility）
- 最佳实践（Best Practices）
- SEO
我们今天重点讲 性能 Performance。
后台常见的“罪状”：
- 图片太大
- JS 太多太肥
- CSS 未使用太多
- 布局偏移 CLS 高
- 阻塞渲染的 JS/CSS
- 缓存配置差
下面我们来逐个击破。
三、常见性能瓶颈（以及如何把它们按死）
1️⃣ 图片太大（最典型，也是后台扣分王）
例如：
❌ 后台 logo.png = *** KB
后台首页还没开图，LCP 就被它拖死。
你可能以为：
“***KB 不大吧？”
兄弟，***KB 的 PNG = 性能灾难。
✔ 最快的解决方法：在线压缩
推荐 Google 官方压缩工具：
👉 squoosh.app
步骤：
-
上传你的 logo.png
-
左侧选择
Resize → 96 × 96（后台 logo 不需要超清） -
右侧选择格式
- WebP（兼容好）
- AVIF（体积最小）
-
下载 logo.webp（1～8KB）
最终效果：
| 原图 | 优化后 |
|---|---|
| *** KB PNG | 1–5 KB WebP |
| 节省 99% | Lighthouse 加 10–20 分 |
后台性能立刻起飞。
2️⃣ 布局偏移 CLS（视觉抖动）
Lighthouse 给你报：
避免布局偏移
CLS: 0.3（友好分：0.1 以下）
通常原因：
- 图片没写 width / height
- 动态内容加载突然撑开布局
- 弹窗 / 提示条 push 内容
解决方法：
给所有 img 加尺寸，或使用 aspect-ratio：
<img src="/banner.png" width="400" height="200" />
或：
img {
aspect-ratio: 2 / 1;
}
后台 CLS 直接从 0.3 → 0.05！
3️⃣ 强制重排（Reflow）
Chrome Performance 它会提示：
Avoid forced synchronous layout
常见原因：
offsetWidth / getBoundingClientRect()立即触发重排- 动画频繁修改 layout 属性
- 用到了巨大的 box-shadow / blur
解决：
✔ 把动态操作改成 transform
✔ 减少不必要的 layout 查询
✔ 大阴影换成伪元素模拟（性能暴涨）
4️⃣ 网络依赖关系树（阻塞 LCP）
后台常见问题：
- 主 JS 包超大
- 图标库打进 bundle（例如 entire FontAwesome）
- antd / element-plus 全量引入
- 没分包（code splitting）
Vite 项目中尤为常见。
最佳解决方案
- 使用按需加载的 UI 库
- 使用 lodash-es（比 lodash 小 60%）
- 公共组件拆分动态 import
- 后台路由页全部懒加载
示例：
const AdminTable = lazy(() => import('./AdminTable'));
首屏 bundle 可以从 800 KB → 200 KB。
5️⃣ 高效缓存生命周期（Cache-Control）
很多后台根本没配置 CDN 缓存。
Lighthouse 会提示：
Use efficient cache policy
最佳缓存策略（后台独立部署）：
Cache-Control: public, max-age=31536000, immutable
静态资源缓存一年，版本号变更自动重新拉取。
性能直接加 5～10 分。
6️⃣ 减少未使用的 JS
后台常见“罪魁祸首”：
- lodash 全量引入
- moment.js（2.8MB 巨无霸）
- 图标库（几十 KB）
- 大量无用组件引入
- 旧 polyfills
排查未使用的js，css，查看覆盖率
DevTools 右上角三点 (⋮) ↓ More tools（更多工具） ↓ Coverage（覆盖率）
✔ 用 lodash-es + ES module tree-shaking
import debounce from "lodash-es/debounce";
一下省 80% 体积。
✔ moment 换成 dayjs
7️⃣ 减少未使用的 CSS
使用 Tailwind 的项目也可能有此问题：
- 全局 CSS 过大
- UI 库样式未按需加载
解决：
✔ Tailwind 开启 purge（Next/Vite 默认开）
✔ 组件样式模块化（避免全局覆盖）
8️⃣ 渲染阻塞的 JS / CSS
Lighthouse 会提示：
Render-blocking resources
解决：
✔ 所有脚本都加 defer
<script src="/admin.js" defer></script>
✔ 所有非关键 CSS lazy 加载
四、使用 Performance 面板做最终诊断
Chrome → Performance → Record
能看到：
- LCP 元素
- Long Task（长任务）
- Reflow 次数
- 图片解码耗时
- Scripting 耗时
你可以清楚定位：
- LCP 由图片导致？
- 还是由 JS 导致？
- 还是渲染阻塞？
非常直观。
五、后台常见技术栈优化建议（Vite / React）
你的后台现在如果是：
- React + Vite
- antd
- lodash
- axios
那么请立即换：
✔ lodash-es（更快、更小、支持 tree shaking）
✔ dayjs（替换 moment）
✔ antd 的 CDN 或按需加载
✔ react-query / swr 做缓存（减少请求）
六、最终 90 分性能后台 Checklist（复制即用）
| 优化项 | 分数提升 |
|---|---|
| 图片换 WebP / AVIF | +20 |
| 主包体积压缩（分包/ lodash-es） | +15 |
| 使用 CDN 缓存策略 | +10 |
| 避免布局偏移（CLS < 0.1） | +10 |
| 消除阻塞渲染的脚本 | +10 |
| 删除未使用 CSS/JS | +10 |
| Tailwind Purge + 按需加载 UI | +5 |
| LCP preload | +5 |
做完这些，你后台性能得分：
从 40 分 → 90+ 分
不需要后端，不需要 DevOps，不需要 serverless
你自己一个前端就能搞定全部。
最后一句话
后台不是“能跑就行”。
后台也要飞，也要强，也要优雅，也要快。
你把后台性能调教好了——
用你后台的人都会说：
“这后台开起来比小程序还快，谁做的？牛逼！”，性能得分与后台接口关系也很大😶🌫️😶🌫️😶🌫️，让你的后台也做优化吧，正常来说，其实前端能做的优化并不多。
