性能即功能：impeccable optimize 命令的 UI 性能诊断、优化与验证实战指南

导读

impeccable 是一套把“具备设计系统素养的 AI 前端工程能力”编排进开发流程的技能体系，而 optimize 是其中负责"诊断并修复界面性能"的专项命令。本文以 optimize.md（发布版同见 skill/reference/optimize.md）为骨架，完整讲解这条命令背后的工作流：从先测量后动手的评估纪律，到加载、渲染、动画、框架与网络五大方向的优化策略，再到 Core Web Vitals 达标、性能监控与"前后对比"的验证闭环。读完你可以把"这段界面卡了/加载慢"这类含糊反馈，转成一套可测量、可定位、可验证的系统性优化流程，并知道何时把结果交接给 polish 完成最终打磨。

贯穿全文的唯一准则写在文档第一行：Performance is a feature——性能是一个功能，而不是可有可无的补丁；但前提是先找到"这一个界面"真正的瓶颈，修复它，再去测量。不要优化并不慢的东西。

1. optimize 在 impeccable 命令体系中的定位

在开始阅读优化细节前，先弄清这条命令的触发入口与适用语义。在 SKILL.md 的 Commands 表中，optimize [target] 被归入 Fix（修复） 类别，定义即 "Diagnose and fix UI performance"（诊断并修复 UI 性能）；其配套参考文档就是本文主题 optimize.md。

命令触发的元数据定义在 command-metadata.json 中：

• 职责范围：覆盖 loading speed（加载速度）、rendering（渲染）、animations（动画）、images（图片）与 bundle size（打包体积）；
• 触发关键词：当用户提到 slow、laggy、janky、performance、bundle size、load time，或表达 "想要更快、更流畅的体验" 时，应当路由到本命令；
• 参数形态：[target] 可选，用于把优化范围收敛到某个具体页面或组件。

需要特别强调的是：optimize 与体系的另一条命令 audit 互补但不重叠。audit（见 audit.md）是"只记录、不修复"的技术体检，其五个打分维度中第二个就是 Performance，会用 0-4 分评估布局抖动、昂贵动画、图片缺少懒加载、will-change 滥用、无用的依赖与多余的重渲染——这些正是 optimize 将要消灭的问题清单。而 routing.md 中给出的信号式路由建议是：先由 audit 产出性能问题证据，再由 optimize 动手修复，形成"审计发现 → 优化修复 → polish 收尾"的标准接力链。

2. 第一步永远是测量：Assess Performance Issues

optimize 不允许"凭感觉优化"。文档要求首先理解当前性能、定位问题，分两个层次展开。

2.1 测量当前状态

优化前必须采集一组"现状基线"：

• Core Web Vitals：LCP（Largest Contentful Paint）、INP（Interaction to Next Paint）、CLS（Cumulative Layout Shift）三项得分；
• 加载时间：Time to Interactive（TTI）、First Contentful Paint（FCP）；
• 打包体积：JavaScript、CSS、图片各自的体积；
• 运行时性能：帧率（frame rate）、内存占用（memory usage）、CPU 占用；
• 网络：请求数量、payload 大小、请求瀑布图（waterfall）。

2.2 定位瓶颈（四连问）

测量不是为了得到一堆数字，而是回答四个问题：

1. 哪里慢？——是首次加载、用户交互，还是动画？
2. 什么导致它慢？——大图？昂贵的 JavaScript？还是布局抖动（layout thrashing）？
3. 有多严重？——是可感知、令人烦躁，还是直接阻塞操作？
4. 影响了谁？——所有用户、仅移动端、还是慢速网络用户？

最后是全文唯一一处全大写标注的红线纪律（CRITICAL）：

Measure before and after. Premature optimization wastes time. Optimize what actually matters. （优化前后都要测量。过早优化浪费的是时间。请只优化真正重要的事情。）

在 audit.md 的 Performance 评分标准中，这一"先测量"原则也内化为评分依据：0 分意味着布局抖动、全链路无优化；1 分意味着没有懒加载、存在昂贵动画；2 分是部分优化但有缺口；3 分是基本优化到位；4 分才是"快、精简、优化良好"。这条评分带实际上就是 optimize 工作结束时的自我检验刻度。

3. 加载性能优化（Loading Performance）

首屏加载是最容易被用户感知的性能维度，文档从五个方面给出系统方案。

3.1 图片优化

• 使用现代格式：WebP、AVIF；
• 正确匹配尺寸：不要为 300px 的显示区域加载 3000px 的图片；
• 对首屏以下的图片启用懒加载（lazy loading）；
• 使用响应式图片（srcset、picture 元素）；
• 压缩图片：80-85% 的质量通常肉眼不可分辨；
• 用 CDN 加速分发。

文档给出了一个可直接落地的响应式图片模板：

<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"
/>

注意其中 sizes 与 srcset 的配合逻辑：srcset 声明候选图与真实像素宽度（400w/800w/1200w），sizes 告诉浏览器在不同视口下图片实际占用的 CSS 宽度，浏览器据此自行挑选最省流量的候选图。

3.2 削减 JavaScript 打包体积

• 代码分割（code splitting）：按路由或组件切分；
• Tree shaking：剔除未使用的代码；
• 移除未使用的依赖；
• 对非关键代码做懒加载；
• 对大型组件使用动态导入。

React 风格的懒加载示例：

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

3.3 CSS 优化

• 移除未使用的 CSS；
• 关键 CSS 内联，其余异步加载；
• 压缩 CSS 文件；
• 对相互独立的区域使用 CSS containment（contain）。

3.4 字体优化

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

@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 */
}

这里 font-display: swap 保证在 webfont 下载完成前先用回退字体渲染文本（避免不可见文本 FOIT），而 unicode-range 则把字体文件裁剪到 Basic Latin 字符集，显著缩小字体体积。

3.5 加载策略整体优化

• 关键资源优先：非关键脚本加 async/defer；
• 预加载关键资源（preload）；
• 预取用户可能访问的下一页（prefetch）；
• 用 Service Worker 提供离线与缓存能力；
• 升级到 HTTP/2 或 HTTP/3 以获得多路复用。

4. 渲染性能优化（Rendering Performance）

渲染性能问题通常表现为滚动卡顿、输入延迟或动画掉帧，核心症结大多是强制同步布局。

4.1 消除布局抖动（Layout Thrashing）

布局抖动指在循环里反复交替地"读布局属性 → 写样式"，每一次读（如 offsetHeight）都会强制浏览器同步执行一次布局计算（reflow），形成性能灾难。文档给出了正反两个对比片段：

// ❌ 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
});

优化原则很简单：先集中读完所有需要读取的值，再集中执行写入，把"读-写-读-写"改成"读读读-写写写"。这个反模式同时也是 audit.md 性能维度第一个要检查的项目。

4.2 渲染路径优化

• 用 CSS contain 隔离独立区域，阻止其内部变化向外部传播；
• 降低 DOM 深度——更扁平的结构更快；
• 减少 DOM 规模（更少的元素）；
• 长列表使用 content-visibility: auto；
• 超长列表做虚拟滚动（如 react-window、TanStack Virtual）。

4.3 减少 Paint 与 Composite 开销

• 用 transform 与 opacity 做可靠的运动（这两者走合成器，不触发布局与重绘）；
• 但当 blur、filter、mask、clip-path、阴影与颜色变化能带来有意义的打磨效果时，不要禁止使用它们——文档明确允许这些开销更大但观感更佳的效果存在，而不是一律规避；
• 不要随意动画布局驱动属性（width、height、top、left、margin）；
• 只在确知的昂贵操作上克制地使用 will-change；
• 限制模糊/滤镜/阴影效果的绘制区域——更小、更隔离的绘制更快。

这条"允许昂贵特效换取有意义打磨"的表述，是 impeccable 与纯教条式性能清单的关键区别：性能优化必须服务于视觉效果，而不是反过来阉割设计表达。

5. 动画性能优化（Animation Performance）

5.1 GPU 加速 vs CPU 绑定

动画属性选择直接决定帧率能否稳定在 60fps：

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

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

transform/opacity 的动画由合成器在 GPU 上完成，不触发布局与重绘；而 left、width 的改动会逐帧触发布局与重绘，完全占用主线程。

5.2 保持流畅的 60fps

• 每帧预算 16ms（1000ms ÷ 60fps）以内；
• JS 动画使用 requestAnimationFrame；
• 对滚动事件做 debounce/throttle；
• 能用 CSS 动画就不用 JS；
• 避免动画期间运行长时间 JavaScript。

5.3 用 Intersection Observer 代替滚动监听

IntersectionObserver 可以高效地侦测元素何时进入视口，是懒加载与入场动画的首选机制，比在 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
    }
  });
});

6. React 与框架层优化（React/Framework Optimization）

6.1 React 专属手段

• 用 memo() 包裹昂贵的组件；
• 用 useMemo() / useCallback() 缓存昂贵的计算与回调；
• 虚拟化长列表；
• 按路由代码分割；
• 避免在 render 中创建内联函数（会造成子组件无意义重渲染）；
• 使用 React DevTools Profiler 定位重渲染来源。

6.2 框架无关的通用原则

• 最小化重渲染次数；
• 对昂贵操作做防抖；
• 记忆化（memoize）计算值；
• 懒加载路由与组件。

无论底层是 React、Vue 还是 Svelte，这条优化清单的落点都是同一个：减少主线程上无意义的重复工作。

7. 网络优化（Network Optimization）

7.1 减少请求数量

• 合并小文件；
• 图标使用 SVG sprite；
• 内联小的关键资源；
• 移除不再使用的第三方脚本。

7.2 优化 API 调用

• 使用分页——不要一次性加载全部数据；
• 用 GraphQL 只请求需要的字段；
• 响应压缩（gzip、brotli）；
• 设置 HTTP 缓存头；
• 静态资源走 CDN。

7.3 面向慢速连接优化

• 基于连接状况自适应加载（navigator.connection）；
• 乐观 UI 更新（optimistic UI，先渲染预期结果再同步服务端）；
• 请求优先级管理；
• 渐进增强（progressive enhancement）。

8. Core Web Vitals 三项核心指标达标

性能优化的"验收标准"最终要落到用户感知最强的三项 Core Web Vitals 上。文档给出的达标线为：LCP < 2.5s、INP < 200ms、CLS < 0.1。

8.1 LCP（Largest Contentful Paint，< 2.5s）

最大内容绘制衡量首屏主体内容何时渲染完成，重点手段：

• 优化 hero 大图（往往是 LCP 元素）；
• 内联关键 CSS；
• 预加载关键资源；
• 使用 CDN；
• 服务端渲染（SSR）。

8.2 INP（Interaction to Next Paint，< 200ms）

交互到下一帧绘制的延迟衡量页面响应交互的速度，重点手段：

• 拆分长任务（long tasks）；
• 延迟加载非关键 JavaScript；
• 重度计算丢给 Web Workers；
• 缩短 JavaScript 执行时间。

8.3 CLS（Cumulative Layout Shift，< 0.1）

累计布局偏移衡量页面视觉稳定性，重点手段：

• 给图片和视频预设尺寸；
• 不要在已有内容上方注入内容；
• 使用 CSS aspect-ratio；
• 为广告/嵌入内容预留空间；
• 避免会造成布局位移的动画。

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

用 aspect-ratio 提前声明宽高比，是预防图片加载完成后把下方内容"顶下去"的最简洁手段，也是 impeccable 在最终 polish 阶段检查图片布局抖动时会复核的点（见 polish.md 中"Prevent image layout shift"一项）。

9. 性能监控：工具、指标与纪律

9.1 推荐工具

• Chrome DevTools：Lighthouse 审计与 Performance 面板；
• WebPageTest：真实环境的多点测试；
• Core Web Vitals（Chrome UX Report）：真实用户数据；
• Bundle 分析器（如 webpack-bundle-analyzer）：看清打包构成；
• 性能监控服务（Sentry、DataDog、New Relic 等）：线上持续追踪。

9.2 关键指标清单

• LCP、INP、CLS（Core Web Vitals；INP 已于 2024 年 3 月取代 FID）；
• Time to Interactive（TTI）；
• First Contentful Paint（FCP）；
• Total Blocking Time（TBT）；
• Bundle size；
• Request count（请求数）。

9.3 测量纪律（IMPORTANT）

在真实设备、真实网络条件下测量。 桌面 Chrome + 高速网络的结果不代表真实用户体验。移动设备的 CPU 与网络带宽都远弱于桌面，只测桌面等于忽略大多数用户。

10. 六条"永不"清单（NEVER）

文档以绝对禁令的形式划定优化行为的边界，防止"为了优化而优化"伤及产品质量与用户：

• 不测量就优化——这是过早优化（premature optimization）；
• 为了性能牺牲可访问性（accessibility）；
• 优化过程中破坏功能；
• 到处滥用 will-change——它会在每个元素上创建合成层、占用显存；
• 对首屏以上内容做懒加载——首屏资源应当优先，而不是延迟；
• 只抠微优化而忽略主要问题——永远先优化最大的瓶颈；
• 忘记移动端性能——移动设备通常 CPU 更弱、网络更慢。

注意前三条（不牺牲 a11y、不破坏功能）与其他禁令不同，它们不是"技巧层面的反对"，而是硬性边界：性能优化永远不能以可访问性或功能完整性为代价。这与 impeccable 的整体价值观一致——在 audit.md 中 Accessibility 始终排在五个维度的第一位。

11. 验证改进并收尾交接（Verify Improvements）

优化不验收就不算完成。文档要求逐项验证：

• 前后指标对比：比较优化前后的 Lighthouse 分数；
• 真实用户监控：跟踪真实用户的体验改善；
• 多设备验证：在低端 Android 上测试，而不是只测旗舰 iPhone；
• 慢速网络：节流到 3G 网络体验一遍；
• 无回归：确认既有功能仍然正常工作；
• 用户感知：它是否感觉上更快了？

最后是工作流的交接句——文档明确写道：

When the user-facing numbers move, hand off to /impeccable polish for the final pass. （当用户可感知的数字开始改善后，将工作交接给 /impeccable polish 做最终一轮打磨。）

这条交接逻辑与整个命令链的设计吻合：optimize 负责把"慢"修成"快"、把数字修到达标；而 polish.md 会在最终验证清单中复核 console errors、layout shift、interaction latency 与 image loading，做面向发布的质量收口。用 audit.md 推荐的命令接力顺序表达就是：audit 发现问题 → optimize 修复性能 → polish 最终打磨 → 重跑 audit 看到分数提升。

12. 把 optimize 落实为一份可复用的优化清单

总结全文，一次规范的 /impeccable optimize [target] 应遵循以下执行序列，可直接复制为团队性能优化的标准作业流程：

1. 基线测量：采集目标页面的 LCP / INP / CLS、TTI / FCP、bundle 体积、帧率与请求瀑布图（对应 optimize.md 的 Assess 部分）；
2. 瓶颈定位：用"哪里慢 / 为何慢 / 多严重 / 影响谁"四问收敛问题优先级；
3. 逐域修复：按加载（图片、JS、CSS、字体、加载策略）→ 渲染（布局抖动、DOM 规模、paint 区域）→ 动画（transform/opacity、60fps、IntersectionObserver）→ 框架层（memoization、代码分割）→ 网络（请求合并、缓存、分页）的顺序推进，每一处修改都对照第 10 节的 NEVER 清单自检；
4. 达标验收：对照 Core Web Vitals 阈值（LCP < 2.5s、INP < 200ms、CLS < 0.1）在低端 Android + 3G 节流的真实环境复测；
5. 交接打磨：用户可感知的数字改善后，将结果交给 /impeccable polish 完成最后的统一质检与发布收尾。

这套方法论既可以作为 impeccable 技能的用户手册，也可以脱离工具独立用作任何前端项目的性能优化作战地图——毕竟它的核心思想放之四海而皆准：性能是功能，先测量，再修复，后验证，最后用可感知的结果说话。