性能优化 on Saiga

让 AI 帮我做前端性能分析报告

wuwenzen@outlook.com (wuwj) — Wed, 01 May 2024 00:00:00 +0000

前端做性能优化，两个常见痛点：

报表很数据化，非技术同学看不懂
每次写性能报告都很花时间：看指标 → 找问题 → 翻译成大家听得懂的结论

于是试了一件事：

我负责把数据准备好，AI 帮我写一份「结构化的性能分析报告」，我只做最后校对。

1. 输入与输出长啥样？

1.1 输入数据

主要有两部分：

Lighthouse JSON 报告
- 性能得分
- LCP / CLS / TBT / TTI 等指标
- 各种「机会」与「诊断」信息
真实用户监控数据（RUM）（可选）
- 最近一段时间的 LCP P75、FCP P75
- 不同地区/设备的耗时对比

1.2 期望输出

希望 AI 给我的报告包含：

一段 1～2 句话的性能整体概览
用人话解释关键指标的含义和当前水平
列出 3～5 个主要问题（按影响排序）
每个问题配上具体可执行的优化建议
告诉我「先做哪几件事最划算」

2. 先做精简：给 AI 的不是原始 JSON

原始 Lighthouse JSON 体积很大，直接给模型既浪费 Token，也容易让它迷路。
所以写了一个小脚本，把它整理成简版结构：

{
  "url": "https://example.com",
  "score": 0.72,
  "metrics": {
    "LCP": 3800,
    "CLS": 0.11,
    "FID": 25,
    "TTI": 4200
  },
  "opportunities": [
    {
      "title": "减少未使用的 JavaScript",
      "estimatedSavingsMs": 800
    },
    {
      "title": "消除阻塞渲染的资源",
      "estimatedSavingsMs": 600
    }
  ],
  "diagnostics": [
    "主线程工作过多",
    "部分图片未压缩"
  ],
  "rum": {
    "LCP_p75": 4200,
    "FCP_p75": 2100,
    "sampleCount": 120000
  }
}

这样输入既足够有信息量，又相对稳定。

一次性能优化实战：从 5s 到 1.5s 的页面加载

wuwenzen@outlook.com (wuwj) — Thu, 14 Jul 2022 00:00:00 +0000

有一次线上迭代后，陆续收到反馈：

「系统能用，就是打开慢了一截。」
「首页白屏时间变长了。」

监控一看，某个核心页面的首屏时间从 约 2s 抬升到了接近 5s。
这篇文章就是那次性能优化的实战复盘：我们如何量化问题、定位瓶颈、再一步步把首屏拉回到 1.5s 左右。

1. 先量化，而不是拍脑袋

第一步是搞清楚「慢」在哪：

首包下载？
JS 执行？
接口耗时？
还是一堆「非必要逻辑」抢在首屏执行？

我们主要用了三种手段：

Chrome DevTools Performance 看关键时序；
Lighthouse 跑实验室指标；
前端埋点 看真实用户数据（FMP/TTI 的简化近似）。

初步结论：

JS 资源总体体积较大，首屏要加载的 JS 超过 1MB（压缩后）；
首屏渲染完成前存在一段较长的 JS 执行（主线程被占用）；
首屏接口本身不是特别慢，但被一些不必要的请求夹在中间。

目标明确：瘦 JS、少阻塞、分优先级。

2. Bundle 拆分：让首屏只拿它真需要的

2.1 分析构建结果

接入 webpack-bundle-analyzer / Vite 插件之后，很快看到几个「大头」：

整个 UI 组件库全量引入；
某些图表库（在其他页面才用）被打进首屏 bundle；
若干工具库重复/未 Tree-shaking。

2.2 做的调整

组件库改为按需引入
- 把 import ElementUI from 'element-ui' 改成 babel 插件/手动按需；
- 打包结果里组件库体积明显下降。
路由级别代码拆分