http://localhost:1313/tags/%E7%BC%93%E5%AD%98/ Recent content in 缓存 on Saiga Hugo zh-cn wuwenzen@outlook.com (wuwj) wuwenzen@outlook.com (wuwj) Thu, 14 Jul 2022 00:00:00 +0000 http://localhost:1313/posts/2022-07-14-performance-optimization-case/ Thu, 14 Jul 2022 00:00:00 +0000wuwenzen@outlook.com (wuwj) http://localhost:1313/posts/2022-07-14-performance-optimization-case/ <p>有一次线上迭代后，陆续收到反馈：</p> <blockquote> <p>「系统能用，就是打开慢了一截。」<br> 「首页白屏时间变长了。」</p> </blockquote> <p>监控一看，某个核心页面的首屏时间从 <strong>约 2s 抬升到了接近 5s</strong>。<br> 这篇文章就是那次性能优化的实战复盘：<strong>我们如何量化问题、定位瓶颈、再一步步把首屏拉回到 1.5s 左右。</strong></p> <hr> <h2 id="1-先量化而不是拍脑袋">1. 先量化，而不是拍脑袋</h2> <p>第一步是搞清楚「慢」在哪：</p> <ul> <li>首包下载？</li> <li>JS 执行？</li> <li>接口耗时？</li> <li>还是一堆「非必要逻辑」抢在首屏执行？</li> </ul> <p>我们主要用了三种手段：</p> <ol> <li><strong>Chrome DevTools Performance</strong> 看关键时序；</li> <li><strong>Lighthouse</strong> 跑实验室指标；</li> <li><strong>前端埋点</strong> 看真实用户数据（FMP/TTI 的简化近似）。</li> </ol> <p>初步结论：</p> <ul> <li>JS 资源总体体积较大，首屏要加载的 JS 超过 1MB（压缩后）；</li> <li>首屏渲染完成前存在一段较长的 JS 执行（主线程被占用）；</li> <li>首屏接口本身不是特别慢，但被一些<strong>不必要的请求</strong>夹在中间。</li> </ul> <p>目标明确：<strong>瘦 JS、少阻塞、分优先级。</strong></p> <hr> <h2 id="2-bundle-拆分让首屏只拿它真需要的">2. Bundle 拆分：让首屏只拿它真需要的</h2> <h3 id="21-分析构建结果">2.1 分析构建结果</h3> <p>接入 <code>webpack-bundle-analyzer</code> / Vite 插件之后，很快看到几个「大头」：</p> <ul> <li>整个 UI 组件库全量引入；</li> <li>某些图表库（在其他页面才用）被打进首屏 bundle；</li> <li>若干工具库重复/未 Tree-shaking。</li> </ul> <h3 id="22-做的调整">2.2 做的调整</h3> <ol> <li> <p><strong>组件库改为按需引入</strong></p> <ul> <li>把 <code>import ElementUI from 'element-ui'</code> 改成 babel 插件/手动按需；</li> <li>打包结果里组件库体积明显下降。</li> </ul> </li> <li> <p><strong>路由级别代码拆分</strong></p>