---

name: frontend-performance description: Analyzes and improves frontend performance: LCP, FCP, CLS, bundle size, lazy loading, and runtime efficiency. Use when 性能优化, 首屏慢, 卡顿, 打包体积, performance optimization, or improving Core Web Vitals.

前端性能优化（Frontend Performance）

围绕加载性能与运行性能，给出可落地的优化方案与优先级。

触发场景

• 用户说「性能优化」「首屏慢」「页面卡顿」「打包体积大」「LCP/FCP 差」
• 提供 Lighthouse 报告、Performance 录屏或具体慢的页面/操作

分析维度

1. 加载性能（LCP / FCP / TTI）

2. 体验稳定性（CLS / 卡顿）

3. 资源与打包

执行流程

1. 先定位用户的问题类型

不要一上来就输出所有优化方向，先判断用户卡在哪：

没有数据就不给优化方案——「感觉慢」可能是网络问题、可能是服务端问题、可能是前端问题，方向不同。

2. 拿到数据后，找真正的瓶颈

加载性能（LCP > 2.5s 或 FCP > 1.8s），按这个顺序排查：

1. Network 瀑布图：最大的资源是什么？JS bundle 还是图片？
2. 是否有渲染阻塞资源（<script> 没有 async/defer，<link> 阻塞）？
3. 服务端响应时间（TTFB）是否超过 600ms？超了是服务端问题，不是前端能优化的

运行时卡顿，按这个顺序排查：

1. Performance 录屏：有没有超过 50ms 的长任务？
2. 卡顿时是否有大量 DOM 操作或重排？
3. 列表是否超过 100 条且没有虚拟滚动？

bundle 体积，看分析报告：

1. 有没有重复打包的依赖（如 lodash 被多个地方引入不同版本）？
2. 有没有不应该进主包的大依赖（如 moment.js、echarts）？
3. 路由是否做了代码分割？

3. 给方案时，标清性价比

每个方案必须说明：改动量、预期收益、风险。

按这个顺序推荐，不要把大改动放在前面：

快速见效（1 天内，低风险）

• 图片加 width/height 属性（修 CLS）
• 字体加 font-display: swap（修 FCP）
• 非首屏图片加 loading="lazy"
• 首屏关键图片加 <link rel="preload">

中等改动（1-3 天，中等风险）

• 路由级代码分割（dynamic import）
• 大依赖按需引入（如 import { debounce } from 'lodash-es'）
• 长列表换虚拟滚动

大改动（需评估，高风险）

• CSR 改 SSR/SSG
• 换构建工具
• 架构级重构

不要把大改动作为首选推荐，除非快速方案已经做完且效果不够。

4. 给出验证方式

每个优化做完后，告诉用户怎么验证效果：

• 加载性能：Lighthouse 对比优化前后分数
• 运行时：Performance 录屏对比长任务数量
• bundle：bundle 分析报告对比体积

输出模板

## 性能优化报告

### 现状
- 指标或现象：…
- 主要瓶颈：…

### 优化方案（按优先级）
| 方案 | 收益 | 成本 | 优先级 |
|------|------|------|--------|
| 1. … | … | … | 高/中/低 |
| 2. … | … | … | … |

### 建议落地顺序
1. …
2. …

### 验证方式
- 优化后建议复测：Lighthouse、Performance、关键操作耗时

项目相关

• Next.js：用 dynamic 懒加载、Image 组件、分析 next/bundle-analyzer
• React：避免在渲染里创建新对象/函数导致子组件无效重渲染，必要时 memo/useMemo/useCallback
• 长列表：优先虚拟滚动（如 react-window、tanstack-virtual）再考虑分页