- 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）
| 问题 | 常见原因 | 优化方向 |
|---|---|---|
| LCP 慢 | 大图、阻塞渲染、服务端慢 | 图片优化、优先关键资源、SSR/预取 |
| FCP 慢 | JS/CSS 阻塞、首屏依赖多 | 拆包、关键 CSS 内联、延迟非关键 |
| TTI 长 | 主线程长任务、大 bundle | 代码分割、懒加载、减少主线程工作 |
2. 体验稳定性（CLS / 卡顿）
| 问题 | 常见原因 | 优化方向 |
|---|---|---|
| CLS 高 | 无尺寸图片/字体、动态插入内容 | 宽高比/尺寸、font-display、预留占位 |
| 滚动/操作卡顿 | 重排多、长任务、大列表 | 虚拟列表、防抖节流、requestAnimationFrame、减少 reflow |
3. 资源与打包
| 问题 | 优化方向 |
|---|---|
| JS 体积大 | 按路由/按需拆包、tree-shaking、替换大依赖、分析 bundle |
| 图片大 | 格式（WebP/AVIF）、尺寸、懒加载、CDN |
| 请求多 | 合并、缓存策略、预连接/preload |
执行流程
1. 先定位用户的问题类型
不要一上来就输出所有优化方向，先判断用户卡在哪：
| 用户描述 | 实际问题 | 第一步 |
|---|---|---|
| 「首屏慢」「白屏时间长」 | 加载性能 | 问：有没有 Lighthouse 数据？LCP 是多少？是 SSR 还是 CSR？ |
| 「页面卡顿」「滚动不流畅」 | 运行时性能 | 问：卡顿发生在什么操作时？列表有多少条数据？ |
| 「打包体积大」「bundle 太大」 | 资源体积 | 直接让用户跑 npx @next/bundle-analyzer 或 vite-bundle-visualizer，看大模块再说 |
| 「LCP/FCP 差」「Core Web Vitals 不达标」 | 具体指标 | 问：哪个指标？多少分？在哪个页面？ |
| 没有数据，只是「感觉慢」 | 未量化 | 先让用户跑 Lighthouse，拿到数据再分析，不要凭感觉给优化建议 |
没有数据就不给优化方案——「感觉慢」可能是网络问题、可能是服务端问题、可能是前端问题，方向不同。
2. 拿到数据后，找真正的瓶颈
加载性能（LCP > 2.5s 或 FCP > 1.8s），按这个顺序排查：
- Network 瀑布图：最大的资源是什么？JS bundle 还是图片？
- 是否有渲染阻塞资源（
<script>没有async/defer，<link>阻塞）？ - 服务端响应时间（TTFB）是否超过 600ms？超了是服务端问题，不是前端能优化的
运行时卡顿，按这个顺序排查：
- Performance 录屏：有没有超过 50ms 的长任务？
- 卡顿时是否有大量 DOM 操作或重排？
- 列表是否超过 100 条且没有虚拟滚动？
bundle 体积，看分析报告：
- 有没有重复打包的依赖（如 lodash 被多个地方引入不同版本）？
- 有没有不应该进主包的大依赖（如 moment.js、echarts）？
- 路由是否做了代码分割？
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）再考虑分页