impeccable 前端性能优化实战指南：用 `/optimize` 命令定位、修复与验证界面性能瓶颈

本指南以 impeccable 技能体系中 optimize.md 为骨架，讲解如何针对"当前这一个界面"完成端到端的性能优化：先量化现状，再定位真正的瓶颈并修复，最后重新测量验证。你将掌握加载、渲染、动画、框架、网络与 Core Web Vitals 六条优化战线的具体手法，并理解它在 impeccable 命令流（audit → optimize → polish）中的承接关系——它不是泛泛的性能知识清单，而是设计语言里"Performance is a feature"（性能本身就是特性）的可执行操作手册。

开宗明义：性能是特性，不是加分项

impeccable 对性能优化的第一要求是不优化没变慢的东西。整份 optimize 文档以一个反直觉的原则开头：

Performance is a feature. Identify the actual bottleneck for THIS interface, fix it, then measure. Don't optimize what isn't slow.

这句话的三层含义贯穿全文：

1. 性能是特性——加载速度、滚动流畅度、交互响应是被用户直接感知的产品属性，与视觉质量同级；
2. 针对"这一个界面"——不是背一套优化模板，而是先找出该界面的真实瓶颈（首屏慢？交互卡？动画掉帧？）；
3. 改完必须测——优化没有完成，直到前后数据对比证明了改善。

在技能体系中，optimize 属于 SKILL.md 命令表的 Fix（修复）类别，命令签名是 /impeccable optimize [target]，用于"诊断并修复 UI 性能"。它的邻居是同一类别的 clarify（UX 文案）与 adapt（设备适配），三者共同构成"发现问题后动手修"的阶段；而性能问题的"发现"由 audit 承担（见下文）。

从 command-metadata.json 中可以看到该命令的触发词定义：当用户提到 slow、laggy、janky、performance、bundle size、load time，或者希望"更快、更顺滑"时，应路由到 optimize：

"optimize": {
  "description": "Diagnoses and fixes UI performance across loading speed, rendering, animations, images, and bundle size. Use when the user mentions slow, laggy, janky, performance, bundle size, load time, or wants a faster, smoother experience.",
  "argumentHint": "[target]"
}

第一步：先评估，后动手——量化当前性能

优化的前置动作是理解现状并找出问题，共两个阶段。

阶段一：度量当前状态（Measure current state）

度量维度	关注指标
Core Web Vitals	LCP、INP、CLS 得分
加载时间	Time to Interactive（TTI）、First Contentful Paint（FCP）
包体积	JavaScript、CSS、图片各自的大小
运行时性能	帧率（frame rate）、内存占用、CPU 占用
网络	请求数量、Payload 大小、Waterfall（请求瀑布）

阶段二：定位瓶颈（Identify bottlenecks）

对每个可感知的卡顿，连续追问四个问题：

• 什么慢？ 初始加载？交互响应？动画滚动？
• 什么引起的？ 大图？昂贵的 JavaScript？Layout thrashing（布局抖动）？
• 有多严重？ 可感知？恼人？还是直接阻塞操作？
• 影响了谁？ 所有用户？仅移动端？仅慢速网络用户？

CRITICAL（关键红线）：改动前必须测，改动后必须复测。过早优化（premature optimization）浪费时间；"优化真正重要的东西"才是正路。这正是 impeccable 全程"bounded passes"（有边界的验证轮次）哲学的体现——SKILL.md 要求"build fully, inspect once, fix everything in one batch, stop polishing"，避免陷入无限自测循环。

第二步：制定系统化优化策略

瓶颈分类明确后，按六大战线逐个击破。每一条都对应可落地的代码级手段。

加载性能（Loading Performance）

图片优化是首屏收益最大的方向之一：

• 使用现代格式（WebP、AVIF）；
• 正确设置尺寸——不要在 300px 的显示位上加载 3000px 的图；
• 首屏以下图片懒加载；
• 响应式图片（srcset + picture 元素）；
• 压缩图片（80–85% 质量在人眼上通常无感知差异）；
• 用 CDN 加速分发。

原文档给出了一个可直接复制的响应式 Hero 图模板，注意 loading="lazy"、sizes 与三个 w 描述符的配合：

<img
  src="hero.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 400px) 400px, (max-width: 800px) 800px, 1200px"
  loading="lazy"
  alt="Hero image"
/>

削减 JavaScript 包体积：

• Code splitting：按路由、按组件拆分；
• Tree shaking：删除未使用代码；
• 移除未使用的依赖；
• 非关键代码懒加载；
• 大组件用动态 import()。

// Lazy load heavy component
const HeavyChart = lazy(() => import('./HeavyChart'));

CSS 优化：清除未使用的 CSS；关键 CSS 内联、其余异步加载；压缩 CSS 文件；对相互独立的区域使用 CSS containment。

字体优化是常被忽略的加载杀手：

• font-display: swap 或 optional；
• 字体子集化（只保留需要的字符）；
• 预加载关键字体；
• 合适场景直接使用系统字体；
• 限制加载的字重数量。

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap; /* Show fallback immediately */
  unicode-range: U+0020-007F; /* Basic Latin only */
}

加载策略整体编排：关键资源优先（非关键资源 async/defer）；preload 关键资源；prefetch 可能的下一页面；用 Service Worker 做离线与缓存；通过 HTTP/2 或 HTTP/3 实现多路复用。

补充：impeccable 仓库自身在字体加载上就落地了这部分思路——command-metadata.json 所在目录携带 data/font-index.json 与 data/font-index-failures.json（.hermes/skills/impeccable/scripts/data/font-index.json），用于在排版命令中做字体索引与失败回退，可见"字体性能"在这个技能里是一个被显式工程化的主题。

渲染性能（Rendering Performance）

避免 Layout Thrashing 是渲染性能的第一戒律。其本质是：浏览器布局（reflow）是惰性的，读到 offsetHeight 等布局属性会强制同步刷新布局；若在读-写之间反复横跳，每一轮都强制一次完整布局，代价高昂。正确姿势是把读操作与写操作各自分批：

// ❌ Bad: Alternating reads and writes (causes reflows)
elements.forEach(el => {
  const height = el.offsetHeight; // Read (forces layout)
  el.style.height = height * 2; // Write
});

// ✅ Good: Batch reads, then batch writes
const heights = elements.map(el => el.offsetHeight); // All reads
elements.forEach((el, i) => {
  el.style.height = heights[i] * 2; // All writes
});

渲染手段清单：

• 独立区域用 CSS contain；
• 减小 DOM 深度（更扁平更快）；
• 减少 DOM 总量（更少的元素）；
• 长列表用 content-visibility: auto；
• 超长列表做虚拟滚动（react-window、TanStack Virtual）。

减少 Paint 与 Composite 的开销：impeccable 这里写得极有分寸——它不搞"只准用 transform/opacity"的教条，而是允许在能产生真正打磨价值时使用 blur、filter、mask、clip-path、shadow 与颜色变化：

• 可靠的运动首选 transform 与 opacity；但那些昂贵的视觉效果在能产生有意义的精致感时被允许使用；
• 避免随手动画化驱动布局的属性（width、height、top、left、margin）；
• will-change 只在已知昂贵操作时克制地使用；
• 把 blur/filter/shadow 的昂贵绘制区域约束到更小且隔离的范围（越小越隔离越快）。

这条与动画参考文档 animate.md 完全同调——后者同样强调"transform and opacity are reliable foundations, not the entire palette"，并追加了运行时纪律：按效果绘制代价设定预算、will-change 仅在已知动画期间施加、要在目标视口与真机上测量而非假定 transform 一定快。

动画性能（Animation Performance）

GPU 加速：合成器（compositor）能独立于主线程处理 transform/opacity，而 left/width 的每一次变化都会触发布局与绘制——二者不在一个数量级：

/* ✅ GPU-accelerated (fast) */
.animated {
  transform: translateX(100px);
  opacity: 0.5;
}

/* ❌ CPU-bound (slow) */
.animated {
  left: 100px;
  width: 300px;
}

维持 60fps 顺滑：目标每帧 16ms（1000ms / 60fps）；JS 动画用 requestAnimationFrame；滚动处理器做防抖/节流；能用 CSS 动画就不用 JS；动画期间避免长时间运行的 JavaScript。

Intersection Observer 是判断"元素是否进入视口"的高效替代（远优于在 scroll 回调里手动计算）：

// Efficiently detect when elements enter viewport
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      // Element is visible, lazy load or animate
    }
  });
});

React / 框架层优化（React/Framework Optimization）

React 专属手段：

• 昂贵组件用 memo()；
• 昂贵计算用 useMemo() 与 useCallback()；
• 长列表虚拟化；
• 路由级 code splitting；
• 渲染内避免内联函数创建（否则每次 render 都产生新引用，破坏 memo 与依赖比较）；
• 用 React DevTools Profiler 定位重渲染来源。

框架无关原则：最小化重渲染；昂贵操作用防抖；计算值做 memo；路由与组件懒加载。

网络优化（Network Optimization）

减少请求数：合并小文件；图标用 SVG sprite；内联小型关键资源；移除未使用的第三方脚本。

优化 API：分页（不要一次拉全部数据）；用 GraphQL 只请求所需字段；响应压缩（gzip、brotli）；HTTP 缓存头；静态资源上 CDN。

为慢速连接优化：基于连接状态自适应加载（navigator.connection）；乐观 UI 更新（先渲染预期结果，后台再同步）；请求优先级排序；渐进增强——保证无 JS 时核心内容仍可用。

第三步：对齐 Core Web Vitals 三座大山

优化最终要用行业标准指标来验收。文档给出三个目标值及对应手段，且明确注记了一个重要时间线事实：INP（Interaction to Next Paint）已于 2024 年 3 月取代 FID。

LCP（Largest Contentful Paint）目标 < 2.5s

• 优化 Hero 图片；
• 内联关键 CSS；
• 预加载关键资源；
• 使用 CDN；
• 服务端渲染。

INP（Interaction to Next Paint）目标 < 200ms

• 拆分长任务（long tasks）；
• 延迟非关键 JavaScript；
• 重计算交给 Web Worker；
• 削减 JavaScript 执行时间。

CLS（Cumulative Layout Shift）目标 < 0.1

• 图片与视频必须预设尺寸；
• 不要向既有内容上方注入内容；
• 用 CSS aspect-ratio；
• 为广告/嵌入内容预留空间；
• 避免会引发布局位移的动画。

/* Reserve space for image */
.image-container {
  aspect-ratio: 16 / 9;
}

这里与 polish 参考文档形成呼应——polish.md 的验证清单同样要求检查"layout shift、interaction latency 与 image loading"，因为布局位移既是性能指标也是视觉完稿质量的组成部分。

第四步：监控与度量——在真实环境里测

工具栈：

• Chrome DevTools（Lighthouse、Performance 面板）；
• WebPageTest；
• Core Web Vitals（Chrome UX Report / CrUX 真实用户数据）；
• Bundle 分析器（webpack-bundle-analyzer）；
• 线上性能监控（Sentry、DataDog、New Relic）。

关键指标一览：LCP、INP、CLS（Core Web Vitals；INP 于 2024 年 3 月取代 FID）、TTI、FCP、TBT（Total Blocking Time）、包体积、请求数量。

IMPORTANT（硬性提醒）：必须在真实设备与真实网络条件下测量。桌面 Chrome + 快速网络的结论不具备代表性——这也是为什么文档在验证环节特别点名低端 Android 与 3G 节流。

NEVER（绝对禁区）清单，每一条都值得贴在工位前：

• ❌ 不测量就优化（过早优化）；
• ❌ 为了性能牺牲可访问性；
• ❌ 优化过程中弄坏功能；
• ❌ 到处用 will-change（会创建新图层、消耗内存）；
• ❌ 懒加载首屏（above-the-fold）内容；
• ❌ 纠结微优化却无视重大问题（先修最大的瓶颈）；
• ❌ 忘记移动端性能（设备更慢、连接更慢）。

第五步：验证改进并交接

优化不是"改完即走"，文档要求用一套多维验证证明改动有效：

• 前后指标对比：比较 Lighthouse 得分；
• 真实用户监控：跟踪真实用户的改善；
• 不同设备：在低端 Android 上测，而不只是旗舰 iPhone；
• 慢速网络：节流到 3G 体验；
• 无回归：确认功能仍然完好；
• 用户感知：是否真的"感觉"更快？

最后一步是交接：当用户可见的数字发生变化时，交给 /impeccable polish 做最终完稿打磨。

optimize 在 impeccable 工作流中的位置

要正确使用这份指南，需理解它与相邻命令的分工：

1. audit（发现）：audit.md 是"代码级体检"，其中的 Performance 维度（0–4 分） 恰好就是 optimize 的输入清单——Layout thrashing、昂贵动画、图片未懒加载、will-change 滥用、包体积、多余重渲染与缺失 memo。audit 只诊断不修复，把问题按 P0–P3 分诊后，在 Recommended Actions 中优先推荐 /impeccable optimize 来承接性能类条目；
2. optimize（修复）：本文主题，承接 audit 的性能病灶，按"度量 → 定位 → 修复 → 复测"闭环执行；
3. polish（完稿）：数字达标后，polish.md 对全路径做视觉、状态、代码整洁度的最终质量把关（其 Trio/Verify 环节仍会复查 layout shift 与交互延迟，防止性能在完稿期回退）。

三者与 animate（animate.md，负责让动效"有目的且不掉帧"）、overdrive（技术野心上限）共同构成 impeccable 的"性能-动效"协同面。实践中，一次典型流程是：/impeccable audit 打出性能分与病灶清单 → /impeccable optimize [target] 逐条修复并按本文的验证清单复测 → 数字移动后 /impeccable polish 收尾。

结语：把性能优化当成一次有边界的工程

impeccable 的 optimize 参考资料真正想传达的方法论是：测量优先、瓶颈优先、真机优先、禁触红线、改后必验。任何一次 UI 性能优化都应先回答"这个界面到底哪里慢、慢多少、影响了谁"，再选择上面对应战线的武器；改完用 Core Web Vitals 与真实设备数据说话，最后把成果完好地交接给 polish。照此执行，性能就从一个模糊的焦虑变成一条可复现、可验证、可交接的工程流水线。