performance-optimization

性能优化

让界面感觉即时响应，并诚实地衡量性能：找出用户等待的地方，针对每次等待决定是消除它（乐观 UI、预加载、批处理）还是掩盖它（骨架屏、渐进式加载），然后实施修复。**首要原则：感知延迟高于实际延迟——点击后立即响应的 3 秒操作，胜过会卡住界面的 1 秒操作；但绝不要假装能交付做不到的事（不编造进度数字，也不在回滚会让用户蒙受损失的情况下使用乐观 UI）。**交付按用户影响排序的审计结果，以及可运行的代码。

适用场景 / 不适用场景

适用于：感觉迟缓的交互、乐观 UI、Core Web Vitals 修复、预加载 / 预先加载、请求批处理 / 去重、布局偏移修复、感知性能策略。

若实际需求是以下内容，请改由其他技能处理：

• 选择 / 设计加载指示器 → skills/frontend-design/loading-states
• 非合成器属性导致的动画卡顿 → skills/frontend-design/interaction-physics（运动规范）或 skills/frontend-design/design-engineer-mindset（渲染管线、布局抖动）
• 乐观 UI 所需的失败 / 回滚提示 → skills/frontend-design/error-handling-recovery
• 后端 / 查询本身的延迟——请指出，但这超出本技能的前端范围

步骤 0 — 检查代码库，然后只询问尚未明确的信息

1. 找出数据层：原生 fetch / axios，还是数据库（TanStack Query、SWR、Apollo、RTK Query）。这决定实现策略——数据层库可通过自身 API 实现乐观更新和去重；手写的数据获取逻辑可能需要补充这些基础能力。
2. 找出等待模式：服务器响应前会禁用 UI 的变更操作、可以并行处理却串行执行的 await 链、对同一资源的重复获取，以及每次渲染都会重新获取数据的 effect。
3. 找出布局偏移来源：没有尺寸 / aspect-ratio 的图片、插入到现有内容上方的内容、缺少后备字体度量而发生切换的字体，以及未预留空间的广告 / 嵌入式内容容器。
4. 查找现有的衡量方式：web-vitals 包、Lighthouse CI、RUM / 分析工具。如果项目能在此环境中运行，请获取实际数据（Lighthouse 或性能分析），对比优化前后——绝不要引用未经实际测量的分数。
5. 如果问题是加载速度，请检查包体信号：构建输出大小、缺失的路由级代码分割，以及全局导入的重量级依赖。

向用户一次性询问（只问检查未能确认的内容）：哪些流程感觉慢（或者这是 Lighthouse / CWV 分数问题？），以及是否有现场数据（CrUX、分析数据）。如果问题已经很具体（“保存任务感觉卡顿”），就不要提问——对该流程进行性能分析并继续处理。

工作流程

1. 按延迟区间对每次等待进行分类

感知等待时间	处理方式
< 100ms	无需处理——感觉即时响应
100ms – 1s	立即提供本地反馈（按钮状态）——不要显示转圈指示器
1s – 10s	尽可能消除；否则用骨架屏 / 转圈指示器掩盖（参见 skills/frontend-design/loading-states）
> 10s	显示真实数字的进度，并在技术栈允许时将任务放到后台执行

2. 根据失败成本，为每种变更决定采用乐观还是悲观策略

• 乐观策略（立即更新 UI，在后台同步，失败时回滚）：失败成本低、成功概率高且易于撤销。点赞、开关、重新排序、向个人列表添加条目、重命名。
• 悲观策略（等待服务器确认，显示行内待处理状态）：不可逆或风险较高的操作——付款、发送（实际发出的电子邮件或消息）、无法撤销的删除，以及任何可能因服务器端验证而被拒绝的操作。
• 折中方案：采用悲观提交并提供撤销（立即删除，在调用服务器前提供 5–10 秒的“撤销”选项），既能带来即时响应感，也更安全。
• 每次乐观更新都必须具备：变更前的状态快照、失败时的精确回滚，以及用户可见的失败通知（通过 skills/frontend-design/error-handling-recovery 接入）。没有回滚的乐观 UI 是数据完整性缺陷，而非性能提升。

3. 消除等待，而不是掩盖等待

按优先级排序：

1. 并行化／批量处理请求——将串行的 await 链替换为 Promise.all 或批量端点；对正在处理的请求去重（数据库通常会自动处理）。
2. 提前预加载——在悬停时或接近视口时预取路由／数据（如果框架提供内置预取功能，请使用）。
3. 缓存并复用——导航时不要重新获取未改变的数据。
4. 然后再掩盖剩余的等待：已知布局使用骨架屏，图像使用模糊渐显，次要内容采用渐进增强，列表项采用交错入场（交错总时长不超过约 300–400ms）。实现方式：references/patterns.md。

4. 根据真实阈值修复测得的 Web 核心指标

Web 核心指标的“良好”阈值（现场数据的第 75 百分位）：

• LCP ≤ 2.5s——最大内容绘制。修复方法：优先加载／预加载 LCP 图像、服务器渲染关键内容、减少阻塞渲染的资源、拆分代码。
• INP ≤ 200ms——交互响应能力（于 2024 年 3 月取代 FID）。修复方法：拆分较长的主线程任务、延后非紧急工作、避免在处理程序中同步读取布局。
• CLS ≤ 0.1——布局稳定性。修复方法：为所有媒体指定尺寸，为异步内容预留空间（骨架屏也能满足此项），使用带有回退字体指标的 font-display 策略。

不要编造数据：只报告实测值，注明是实验室数据还是现场数据；如果无法在当前环境中测量，请交付修复内容并提供用户验证说明。

5. 验证

用与之前相同的方式重新测量（使用相同工具、相同页面，并注明限流设置）。对于乐观流程，强制触发失败并确认已精确回滚且显示了通知。对于 CLS 修复，在网络限流条件下重新加载并观察是否发生偏移。

必需的输出格式

交付以下两项：

1. 代码——实现乐观变更（如项目中已有数据库，则通过该数据库实现）、并行化／批量处理／去重请求、加载等待的掩盖处理，以及 Web 核心指标修复。

2. 性能审计（Markdown）：

## Summary
One paragraph: what felt/measured slow, root causes, what changed.

## Measurements
| Metric | Before | After | Threshold | Source (lab/field, tool) |
| LCP | 4.1s | 2.2s | ≤2.5s | Lighthouse, throttled |
| INP | — | — | ≤200ms | not measurable here — verify via [tool] |
| CLS | 0.34 | 0.05 | ≤0.1 | Lighthouse |
(only rows you actually measured; never invented)

## Findings & fixes (ranked by user impact)
| # | Finding | Evidence | Fix | Status |
| 1 | Task save blocks UI ~800ms | network tab | optimistic update + rollback | implemented |
| 2 | 4 serial awaits on dashboard load | code | Promise.all | implemented |
| 3 | Hero image no dimensions → CLS | measured 0.34 | aspect-ratio + preload | implemented |

## Mutation strategy table
| Mutation | Strategy | Why | Rollback/undo |
| Like toggle | optimistic | trivial reversal | snapshot restore |
| Checkout | pessimistic | irreversible charge | n/a — inline pending |

## Not done / recommended next
[Backend latency, infra, CDN items outside frontend scope]

质量标准（交付前检查）

• 所有声称的数据均已实际测量；已注明实验室数据还是现场数据；无法测量的指标已标明
• 每次乐观更新都具备快照、精确回滚和用户可见的失败通知
• 付款、已发送的消息或无法撤销的破坏性操作均未采用乐观处理
• 独立请求之间不再存在串行的 await 链
• 所有修改代码中的图像／嵌入内容均已预留尺寸
• 未向用户展示编造的进度百分比或时间估计
• 掩盖处理遵循 prefers-reduced-motion；交错时长受到限制
• 修复项按用户影响排序，而非按实现难易程度排序

严格禁止：不要仅为一项优化而添加数据获取库，却不说明其中的权衡；不要使用损害真实用户体验的技巧来追逐 Lighthouse 分数（例如延迟加载 LCP 图像、让即时内容闪现骨架屏）；不要仅仅为了“感觉更快”而移除现有的加载反馈。

集成

• skills/frontend-design/loading-states → 负责决定此技能无法消除的等待期间显示哪个指示器；应与其配合使用——预留空间是共同的 CLS 工作。
• skills/frontend-design/error-handling-recovery → 为每个乐观更新提供回滚失败提示。
• skills/frontend-design/design-engineer-mindset → 负责渲染管线的深入优化（布局抖动、帧预算），适用于修复 INP／卡顿所需的主线程工作。
• skills/frontend-design/interaction-physics → 其仅使用合成器动画的规则可避免本技能原本需要修复的卡顿。

参考资料

• references/patterns.md — 乐观创建／删除／切换及回滚、数据库说明、骨架屏／模糊渐显／渐进式／交错式遮罩、预先加载、请求批处理与去重代码，以及 CWV 测量指南。实施修复时请阅读。