\r \r

前端性能优化（Frontend Performance）\r

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

触发场景\r

\r

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

分析维度\r

\r

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

\r | 问题 | 常见原因 | 优化方向 |\r |------|----------|----------|\r | LCP 慢 | 大图、阻塞渲染、服务端慢 | 图片优化、优先关键资源、SSR/预取 |\r | FCP 慢 | JS/CSS 阻塞、首屏依赖多 | 拆包、关键 CSS 内联、延迟非关键 |\r | TTI 长 | 主线程长任务、大 bundle | 代码分割、懒加载、减少主线程工作 |\r \r

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

\r | 问题 | 常见原因 | 优化方向 |\r |------|----------|----------|\r | CLS 高 | 无尺寸图片/字体、动态插入内容 | 宽高比/尺寸、font-display、预留占位 |\r | 滚动/操作卡顿 | 重排多、长任务、大列表 | 虚拟列表、防抖节流、requestAnimationFrame、减少 reflow |\r \r

3. 资源与打包\r

\r | 问题 | 优化方向 |\r |------|----------|\r | JS 体积大 | 按路由/按需拆包、tree-shaking、替换大依赖、分析 bundle |\r | 图片大 | 格式（WebP/AVIF）、尺寸、懒加载、CDN |\r | 请求多 | 合并、缓存策略、预连接/preload |\r \r

执行流程\r

\r

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

\r 不要一上来就输出所有优化方向，先判断用户卡在哪：\r \r | 用户描述 | 实际问题 | 第一步 |\r |---------|---------|-------|\r | 「首屏慢」「白屏时间长」 | 加载性能 | 问：有没有 Lighthouse 数据？LCP 是多少？是 SSR 还是 CSR？ |\r | 「页面卡顿」「滚动不流畅」 | 运行时性能 | 问：卡顿发生在什么操作时？列表有多少条数据？ |\r | 「打包体积大」「bundle 太大」 | 资源体积 | 直接让用户跑 npx @next/bundle-analyzer 或 vite-bundle-visualizer，看大模块再说 |\r | 「LCP/FCP 差」「Core Web Vitals 不达标」 | 具体指标 | 问：哪个指标？多少分？在哪个页面？ |\r | 没有数据，只是「感觉慢」 | 未量化 | 先让用户跑 Lighthouse，拿到数据再分析，不要凭感觉给优化建议 |\r \r 没有数据就不给优化方案——「感觉慢」可能是网络问题、可能是服务端问题、可能是前端问题，方向不同。\r \r

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

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

1. Network 瀑布图：最大的资源是什么？JS bundle 还是图片？\r
2. 是否有渲染阻塞资源（\x3Cscript> 没有 async/defer，\x3Clink> 阻塞）？\r
3. 服务端响应时间（TTFB）是否超过 600ms？超了是服务端问题，不是前端能优化的\r \r 运行时卡顿，按这个顺序排查：\r
4. Performance 录屏：有没有超过 50ms 的长任务？\r
5. 卡顿时是否有大量 DOM 操作或重排？\r
6. 列表是否超过 100 条且没有虚拟滚动？\r \r bundle 体积，看分析报告：\r
7. 有没有重复打包的依赖（如 lodash 被多个地方引入不同版本）？\r
8. 有没有不应该进主包的大依赖（如 moment.js、echarts）？\r
9. 路由是否做了代码分割？\r \r

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

\r 每个方案必须说明：改动量、预期收益、风险。\r \r 按这个顺序推荐，不要把大改动放在前面：\r \r 快速见效（1 天内，低风险）\r

• 图片加 width/height 属性（修 CLS）\r
• 字体加 font-display: swap（修 FCP）\r
• 非首屏图片加 loading="lazy"\r
• 首屏关键图片加 \x3Clink rel="preload">\r \r 中等改动（1-3 天，中等风险）\r
• 路由级代码分割（dynamic import）\r
• 大依赖按需引入（如 import { debounce } from 'lodash-es'）\r
• 长列表换虚拟滚动\r \r 大改动（需评估，高风险）\r
• CSR 改 SSR/SSG\r
• 换构建工具\r
• 架构级重构\r \r 不要把大改动作为首选推荐，除非快速方案已经做完且效果不够。\r \r

4. 给出验证方式\r

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

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

输出模板\r

\r

## 性能优化报告\r
\r
### 现状\r
- 指标或现象：…\r
- 主要瓶颈：…\r
\r
### 优化方案（按优先级）\r
| 方案 | 收益 | 成本 | 优先级 |\r
|------|------|------|--------|\r
| 1. … | … | … | 高/中/低 |\r
| 2. … | … | … | … |\r
\r
### 建议落地顺序\r
1. …\r
2. …\r
\r
### 验证方式\r
- 优化后建议复测：Lighthouse、Performance、关键操作耗时\r
```\r
\r
## 项目相关\r
\r
- Next.js：用 `dynamic` 懒加载、Image 组件、分析 `next/bundle-analyzer`\r
- React：避免在渲染里创建新对象/函数导致子组件无效重渲染，必要时 memo/useMemo/useCallback\r
- 长列表：优先虚拟滚动（如 react-window、tanstack-virtual）再考虑分页\r