---
name: fe-performance
description: |
  前端性能优化技能包，涵盖懒加载与代码分割、图片优化（WebP化）、Service Worker 缓存、首屏性能优化、Core Web Vitals 治理、Bundle 分析与瘦身。
  当需要优化前端加载速度、减小包体积、改善用户体验指标、配置缓存策略、或进行性能诊断时触发此技能。
  支持 Angular、Vue、React、原生 JS、Node.js 技术栈。
---

# 前端性能优化路由手册

按“症状 → 诊断 → 定位 → 修复 → 验证”的顺序执行。不要一次性并行改太多项，避免回归来源不明。

## 1. 快速诊断总流程（5~20 分钟）

1. 基线采集
   - 运行 `npx lighthouse http://localhost:4173 --view`
   - 在 Chrome DevTools `Performance` 录制一次冷启动与一次热启动。
   - 在 Network 面板确认是否启用缓存、HTTP/2/HTTP/3、压缩（br/gzip）。
2. 指标分桶
   - 首屏慢（FCP/LCP 差）
   - 可交互慢（TBT/INP 差）
   - 布局抖动（CLS 差）
   - 包体积大（JS/CSS 传输过大）
   - 离线/弱网重复加载（缓存策略差）
3. 按症状路由到对应参考文档（见下一节）。
4. 每完成一个修复，重复 Lighthouse 与真实设备复测。

## 2. 决策树（症状到文档）

### A. 首屏白屏久、LCP 超标

- 先读 `references/first-paint.md`
- 同时读 `references/image-optimization.md`
- 当 LCP 元素是大图时，优先图片链路；当 LCP 元素是文本/容器时，优先 Critical CSS、字体与资源提示。

### B. 首次加载 JS 体积大、路由切换卡

- 先读 `references/lazy-loading.md`
- 再读 `references/bundle-analysis.md`
- 当路由级 chunk 不合理时先做 code splitting；当第三方库过大时先做依赖替换与 tree shaking。

### C. INP 高、点击响应慢、长任务多

- 先读 `references/core-web-vitals.md`
- 再读 `references/lazy-loading.md`（减少首批执行 JS）
- 必要时读 `references/bundle-analysis.md`（定位重库导致主线程阻塞）。

### D. CLS 高、页面抖动

- 先读 `references/core-web-vitals.md`
- 再读 `references/image-optimization.md`（尺寸占位、响应式图片）
- 若由字体切换触发，回到 `references/first-paint.md` 的字体治理章节。

### E. 弱网/离线体验差、二次访问无提升

- 先读 `references/service-worker.md`
- 按资源类型拆分策略：静态资源 `CacheFirst`，HTML/API 视业务用 `NetworkFirst` 或 `StaleWhileRevalidate`。

### F. Lighthouse 分数波动大、改动后收益不稳

- 先读 `references/core-web-vitals.md`（监控与上报）
- 再读 `references/bundle-analysis.md`（构建产物可视化 + 回归对比）

## 3. 常见指标到行动映射

- 当 **LCP 超标**时，阅读 `references/first-paint.md` 和 `references/image-optimization.md`。
- 当 **INP 超标**时，阅读 `references/core-web-vitals.md` 和 `references/lazy-loading.md`。
- 当 **CLS 超标**时，阅读 `references/core-web-vitals.md` 和 `references/image-optimization.md`。
- 当 **JS 传输体积 > 300KB（gzip）**时，阅读 `references/bundle-analysis.md` 和 `references/lazy-loading.md`。
- 当 **二次访问仍慢**时，阅读 `references/service-worker.md`。
- 当 **字体闪烁、首屏样式延迟**时，阅读 `references/first-paint.md`。

## 4. 统一执行模板（每一项优化都复用）

1. 定义单一目标
   - 示例：`LCP 3.8s → 2.5s 内`。
2. 锁定瓶颈
   - 用 Lighthouse 诊断项 + DevTools 时间线定位具体资源/任务。
3. 执行最小改动
   - 一次只改一个方向：图片、拆包、缓存、关键渲染路径、第三方脚本。
4. 验证收益
   - 对比改动前后：指标、请求数、传输体积、主线程阻塞时间。
5. 防回归
   - 把关键阈值接入 CI（例如 Lighthouse CI、bundlesize）。

## 5. 文档读取顺序建议

- 冷启动慢：`first-paint.md` → `image-optimization.md` → `lazy-loading.md`
- 交互慢：`core-web-vitals.md` → `bundle-analysis.md`
- 离线与缓存：`service-worker.md`
- 大项目长期治理：`bundle-analysis.md` → `core-web-vitals.md`（监控闭环）

## 6. 交付检查清单

- 至少完成一次“实验组 vs 对照组”指标对比。
- 提供改动清单（配置、代码、构建参数）。
- 输出可复现命令（构建、分析、压测、审计）。
- 明确风险点（缓存更新、SSR 兼容、老设备回退策略）。

## 7. references 索引

- 懒加载与代码分割：`references/lazy-loading.md`
- 图片优化：`references/image-optimization.md`
- Service Worker 缓存：`references/service-worker.md`
- 首屏性能优化：`references/first-paint.md`
- Core Web Vitals 治理：`references/core-web-vitals.md`
- Bundle 分析与瘦身：`references/bundle-analysis.md`