Frontend Performance

v1.0.1

Analyzes frontend performance issues (LCP, FCP, CLS, bundle size) and suggests prioritized, practical optimizations for loading and runtime efficiency.

1· 1.5k· 2 versions· 15 current· 16 all-time· Updated 8h ago· MIT-0
bywangzhiming@wangzhiming1999

Install

openclaw skills install frontend-performance

前端性能优化(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-analyzervite-bundle-visualizer,看大模块再说
「LCP/FCP 差」「Core Web Vitals 不达标」具体指标问:哪个指标?多少分?在哪个页面?
没有数据,只是「感觉慢」未量化先让用户跑 Lighthouse,拿到数据再分析,不要凭感觉给优化建议

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

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)再考虑分页

Version tags

latestvk975qxec2z6t090mc1a8r33yx58565ke