performance-optimization

性能优化

诊断 Web 性能问题并制定修复计划。与技术栈无关，基于 Core Web Vitals 和标准浏览器性能模式。

本技能比 qa-testing 和 seo-technical 中的性能检查更深入。当性能本身是目标时，请使用本技能。

---

适用场景

• 修复 Core Web Vitals（LCP、INP、CLS）
• 诊断页面加载缓慢的问题
• 缩小 JavaScript 包体积
• 优化图像、字体和其他资源
• 修复布局偏移、阻塞渲染的资源和卡顿
• 发布前性能验证
• 年度性能健康检查

不适用场景

• 发布后的常规 QA（使用 qa-testing）
• 包括索引和抓取在内的技术 SEO（使用 seo-technical）
• 常规 Bug 的代码审查（使用 code-review-web）

---

必需输入

• 要审查的网站或页面
• 具体的性能问题（如有）
• 目标指标（Core Web Vitals 阈值、Lighthouse 评分或自定义指标）
• 浏览器开发者工具访问权限
• 性能监控数据（如有，包含真实用户监控数据和实验室数据）

---

框架：Core Web Vitals

以下三项指标对用户体验和 SEO 的影响最大：

LCP（最大内容绘制）

衡量内容： 最大的可见内容元素完成渲染所需的时间。

目标：

• 良好：低于 2.5 秒
• 需要改进：2.5 至 4.0 秒
• 较差：超过 4.0 秒

LCP 较差的常见原因：

• 服务器响应时间过慢（TTFB 超过 800ms）
• JavaScript 或 CSS 阻塞渲染
• LCP 元素对应的图像体积过大且未优化
• 字体加载过晚，导致文本渲染延迟
• 在客户端渲染 LCP 元素

常见修复方法：

• 在服务器端渲染 LCP 元素（不在客户端渲染）
• 优化 LCP 图像（选择合适的格式和尺寸，并预加载）
• 减少阻塞渲染的资源（延迟加载非关键 CSS 和 JS）
• 使用现代图像格式（WebP、AVIF）
• 指定图像尺寸，跳过布局阶段

INP（下次绘制交互）

衡量内容： 对用户交互的响应能力。它取代 FID，成为标准的交互性指标。

目标：

• 良好：低于 200ms
• 需要改进：200 至 500ms
• 较差：超过 500ms

INP 较差的常见原因：

• 长时间运行的 JavaScript 阻塞主线程
• 事件处理程序过于繁重
• React/框架频繁重新渲染
• 事件处理程序中的同步操作
• DOM 过大，导致布局开销高

常见修复方法：

• 将长任务拆分为多个片段（使用 scheduler.yield() 或 setTimeout）
• 对开销较大的计算进行记忆化处理
• 对高频事件处理程序（滚动、鼠标移动、输入）使用防抖或节流
• 避免在事件处理程序中执行同步存储或 DOM 操作
• 减小 DOM 规模（理想情况下少于 1500 个元素）
• 尽可能使用 CSS 而非 JS 实现动画

CLS（累积布局偏移）

衡量内容： 页面加载过程中布局的跳动程度。意外的布局偏移会损害易用性。

目标：

• 良好：低于 0.1
• 需要改进：0.1 至 0.25
• 较差：超过 0.25

CLS 较差的常见原因：

• 图像未指定明确尺寸
• 广告、嵌入内容和 iframe 加载过晚
• 在现有内容上方动态注入内容
• Web 字体导致 FOIT/FOUT（不可见/未样式化文本闪烁）
• CSS 依赖由 JS 加载的数据

常见修复方法：

• 始终为图像和视频指定 width 和 height（或 aspect-ratio）
• 在广告和嵌入内容加载前预留空间
• 谨慎使用 font-display: optional 或 font-display: swap
• 避免在初次渲染后于首屏区域注入内容
• 预加载关键字体

---

Core Web Vitals 之外

首字节时间（TTFB）

服务器响应时间。TTFB 表现不佳会拖累其他所有指标。

**目标：**理想情况下低于 800 毫秒。

常见原因：

• 请求路径上的数据库查询缓慢
• N+1 查询模式
• 缺少缓存
• 服务器与用户之间的地理距离较远（没有 CDN）
• 无服务器架构中的冷启动

解决方法：

• 缓存数据库查询
• 使用 CDN 提供静态内容和可缓存的动态内容
• 优化关键路径上的查询
• 尽可能预渲染（SSG、ISR）
• 使用边缘函数提供低延迟的动态内容

包体积

发送到浏览器的 JavaScript。

目标：

• 典型页面的初始 JS 压缩后低于 170 KB
• 每个延迟加载的代码块压缩后低于 100 KB

常见的体积膨胀原因：

• 只用到一个函数，却导入整个库
• 为现代浏览器打包 polyfill
• 在生产环境中包含仅用于开发的代码
• 依赖重复（同一个库有多个版本）
• 客户端状态过大（Redux store 快照等）

解决方法：

• 对导入进行 Tree-shaking（使用 import { fn } from 'lib'，而非 import lib from 'lib'）
• 按路由拆分代码
• 延迟加载首屏以下的组件
• 审核依赖；替换体积较大的依赖（例如，将 moment.js 替换为 date-fns 或原生 Intl）
• 使用构建时包分析器发现体积膨胀
• 对不常用的功能使用动态导入

图像优化

图像通常占页面体积的 60% 到 80%。

最佳实践：

• 现代格式：支持 WebP 的地方都使用 WebP，支持 AVIF 的地方则使用 AVIF
• 响应式图像：使用 srcset 适配不同的视口尺寸
• 延迟加载：对首屏以下的图像使用 loading="lazy"
• 指定尺寸：避免 CLS
• 使用合适的尺寸：不要为 800px 的显示尺寸发送 4000px 的图像
• LCP 图像：预加载，绝不延迟加载

字体加载

Web 字体常常会延迟文本渲染并导致 CLS。

最佳实践：

• 自托管字体（避免第三方阻塞）
• 预加载关键字体（<link rel="preload" as="font">）
• 对非关键字体使用 font-display: swap
• 对字体进行子集化，移除未使用的字形
• 尽可能使用可变字体
• 提供视觉效果相近的系统字体作为回退

第三方脚本

第三方脚本（分析、广告、聊天窗口）往往占用大部分性能预算。

逐一审核：

• 是否必需？
• 能否在页面交互后加载（延迟执行）？
• 能否在 Worker 中运行（不占用主线程）？
• 第三方服务本身是否够快？
• 是否有更轻量的替代方案？

一种常见情况：50% 的性能问题来自第三方脚本。

---

工作流

1. **建立基线。**运行 Lighthouse 扫描、WebPageTest 测试，或采集真实用户监控数据。记录当前的 Core Web Vitals。
2. **找出最严重的问题。**LCP、INP 或 CLS 中哪项不达标？先从它入手。
3. **具体诊断。**使用浏览器开发者工具（Performance 标签页、Network 标签页、Coverage 标签页）。找出指标不达标的实际原因。
4. **规划修复方案。**针对发现的每个问题，规划具体的变更，并估算影响和工作量。
5. **实施。**尽可能一次只做一项修复，以便更容易衡量效果。
6. **重新测量。**每项重大修复完成后，重新运行 Lighthouse 并检查真实用户监控数据。
7. **持续迭代。**性能问题很少能一次性解决。应规划持续监控和修复。

---

工具

实验室工具（按需运行）：

• Lighthouse（内置于 Chrome DevTools）
• PageSpeed Insights（在线）
• WebPageTest（在线，可配置更多选项）
• 浏览器 Performance 标签页（用于深入分析火焰图）

现场工具（真实用户数据）：

• Chrome 用户体验报告（CrUX）——任何网站的公开数据
• 真实用户监控（RUM）——你自己的用户数据（DataDog、New Relic、自定义工具等）
• Search Console Core Web Vitals 报告

实验室工具有助于诊断问题。现场工具提供的数据才是用户实际体验的真实依据。

---

失败模式

• 未测量就优化。 没有基线指标的性能优化只是表面功夫。务必先测量。
• 优化了错误的指标。 Lighthouse 分数很高，但真实用户指标很差，说明测试条件与用户实际情况不符。
• 过度优化。 花几周将 TTFB 缩短 10ms，却任由 CLS 高达 0.4。先解决最严重的问题。
• 只根据 Lighthouse 进行优化。 Lighthouse 在理想化条件下运行。务必检查现场数据。
• 只优化单个页面。 性能回退会逐渐蔓延到整个代码库。建立性能预算和 CI 检查。
• 认为每个字节都一样。 阻塞渲染的 100KB 脚本比延迟加载的 500KB 脚本影响更大。
• 过度执着于捆绑包大小。 捆绑包大小很重要，但执行时间更重要。一个解析耗时 5 秒的小捆绑包，不如一个运行迅速的大捆绑包。
• 忽视第三方服务。 “这是分析标签，不是我们的问题。”在用户眼中，第三方服务运行在你的域名上。你要对它们负责。

---

输出格式

默认输出为 performance-audit.md 中的性能报告。

结构：

1. 执行摘要
2. 方法（工具、条件、示例页面）
3. 当前状态（Core Web Vitals、Lighthouse 分数、RUM 数据）
4. 严重问题（Core Web Vitals 未通过项）
5. 重要问题（不理想但尚未失败）
6. 优化润色（超出要求的改进）
7. 修复路线图（按顺序排列）
8. 性能预算建议
9. 监控计划

对于复杂审计，请附上：

• 每页的 Lighthouse 导出结果
• 捆绑包分析输出
• 网络瀑布流截图
• 需要更改的具体代码片段

---

如果所需数据不可用

此技能的输出依赖于它无法自行生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法验证时，合规的输出应是交付内容，并明确说明数据缺口：需要什么、实际获取或验证了什么，以及哪些输出部分受到影响。绝不可编造、估算或插值所需数值来完成交付。明确说明数据缺口本身就是完整的答复。

---

参考文件

• references/audit-template.md - 完整的性能审计报告模板。
• references/optimization-checklist.md - 按优先级排列的常见优化速查清单。
• references/optimization-playbook.md - 针对常见 Core Web Vitals 问题（LCP、INP、CLS）的症状与修复方案手册。