尧图网站建设 
impeccable optimize 性能优化实战面向真实瓶颈的 UI 诊断、测量与修复指南【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本文面向在本项目 impeccable一套让 AI 设计与开发代理更懂设计的“设计语言/技能”中使用/impeccable optimize命令的场景完整讲解其对应能力文档 optimize.md 中先测量、后优化、再验证的 UI 性能优化方法论如何评估性能现状、锁定真实瓶颈如何在加载、渲染、动画、框架与网络五个层面系统施治以及如何用 Core Web Vitals 与回归验证收尾。读完你既能按命令直接驱动 AI 完成一次性能修复也能把整套诊断框架用于任何前端界面。optimize是 impeccable 技能体系中的Fix修复类命令。从命令元数据看它的定位是Diagnoses and fixes UI performance across loading speed, rendering, animations, images, and bundle size见 .trae-cn/skills/impeccable/scripts/command-metadata.json当用户提到 slow、laggy、janky、performance、bundle size、load time或希望界面更快更流畅时即触发。技能入口 SKILL.md 中命令表将其与audit诊断打分但不直接修复、polish最终润色等命令并置构成审计 → 优化 → 打磨的完整流水线。下文以能力文档为骨架逐层展开其全部操作要点并补充仓库源码中的佐证与关联上下文。一、核心理念性能本身就是一个功能特性优化文档开篇就给出纪律性总纲Performance is a feature. Identify the actual bottleneck for THIS interface, fix it, then measure. Dont optimize what isnt slow.翻译为可执行原则就是三点性能是产品功能的一部分不是事后的锦上添花针对这一个界面的真实瓶颈动手——拒绝套用清单式优化先搞清楚慢在哪不优化不慢的东西——没有测量依据的提前优化是浪费时间premature optimization。这与同仓库 audit.md 中的性能维度评分标准0Severe issues…4Excellent互为表里audit负责把性能问题以 P0–P3 严重度记录成报告并推荐修复命令而optimize负责真正动手修复。audit 的性能维度检查清单layout thrashing、昂贵动画、缺失懒加载、will-change滥用、bundle 体积、多余渲染恰好就是本文档优化策略的问题清单来源。二、评估现状测量是第一优先级的动作任何优化都从理解当前性能开始绝不能跳过。文档要求先测五类指标测量面具体指标Core Web VitalsLCP最大内容绘制、INP交互到下一帧、CLS累积布局偏移加载时间可交互时间TTI、首次内容绘制FCP包体体积JavaScript、CSS、图片尺寸运行时性能帧率、内存占用、CPU 占用网络请求数量、载荷大小、瀑布流waterfall随后回答瓶颈四问把模糊的慢收敛为具体的问题哪里慢首屏加载交互响应动画掉帧什么导致的大图高开销 JS布局抖动layout thrashing有多严重可感知令人烦躁还是直接阻塞操作影响谁所有用户仅移动端仅弱网用户文档在此处特别标注CRITICAL必须测量改造前与改造后的数据。Measure before and after. Premature optimization wastes time.优化只针对实际重要的环节——这也是本方法论与按模板逐条过优化项的根本区别。三、加载性能让首屏更快到达1. 图片优化图片通常是页面体量与 LCP 的最大来源策略层层递进使用现代格式 WebP / AVIF压缩率更高、质量损失小尺寸匹配——不要在 300px 的展示区加载 3000px 的原图首屏以下图片懒加载用srcset/picture提供响应式图片压缩到 80%–85% 质量文档注明该区间内人眼通常无感知使用 CDN 就近分发。文档给出的标准响应式写法可直接套用img srchero.webp srcsethero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w sizes(max-width: 400px) 400px, (max-width: 800px) 800px, 1200px loadinglazy altHero image /注意srcset按w描述符 sizes媒体条件协同工作loadinglazy只应加在首屏以下内容上见后文 NEVER 清单。2. 削减 JavaScript 包体代码分割Code splitting按路由或按组件切分Tree shaking删除未使用代码移除未使用的依赖非关键代码懒加载大组件使用动态import// Lazy load heavy component const HeavyChart lazy(() import(./HeavyChart));3. CSS 优化删除未使用的 CSS 规则关键 CSS 内联、其余异步加载压缩 CSS 文件用 CSS containment 隔离独立区域的样式影响参见渲染性能章节。4. 字体优化字体是 CLS 与 FCP 的常见隐藏元凶文档给出的要点与完整font-face示例使用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: U0020-007F; /* Basic Latin only */ }5. 加载策略编排关键资源优先非关键资源加async/defer用link relpreload预加载关键资产用prefetch预取用户下一步可能打开的页面用 Service Worker 实现离线与缓存依赖 HTTP/2 或 HTTP/3 的多路复用降低连接开销。仓库佐证impeccable 的扩展侧同样把性能当作可检测、可路由问题的来源——开发工具面板把layout-transition类问题映射到animate, optimize修复命令见 extension/devtools/panel.js说明检测出问题 → 路由到对应修复命令正是本技能的设计闭环。四、渲染性能减少强制回流与重复工作1. 消除布局抖动Layout Thrashing读写分离是渲染性能的第一课。交替读写会强迫浏览器在每个读操作前执行同步布局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 });先批量收集所有读取再一次写入浏览器只需完成一次布局计算。2. 结构级渲染优化用 CSScontain隔离独立区域的样式/布局影响范围尽量压平 DOM 深度flatter is faster减少 DOM 元素总量长列表用content-visibility: auto跳过屏幕外渲染超长列表用虚拟滚动react-window、TanStack Virtual 等。3. 减少 Paint 与 Composite这部分文档给出了一条值得特别强调的平衡原则可靠的运动应使用transform与opacity但当 blur、滤镜、mask、clip-path、阴影与颜色渐变能带来有意义的精致感时也应允许它们存在。这体现了 impeccable 一贯的立场——性能指南不是禁用特效的教条而是为可感知的质感付费为无意义的代价买单避免随意动画布局驱动属性width、height、top、left、marginwill-change只用于已知的高开销动画且必须克制它会创建新图层、占用内存滥用反而更慢昂贵 paint 区域blur/filter/shadow要更小、更孤立——把模糊作用域收缩到局部而非整屏。五、动画性能把帧预算控制在 16ms 内1. GPU 加速 vs CPU 绑定/* ✅ GPU-accelerated (fast) */ .animated { transform: translateX(100px); opacity: 0.5; } /* ❌ CPU-bound (slow) */ .animated { left: 100px; width: 300px; }transform/opacity走合成器compositorGPU 管线left/width会触发布局与绘制全程占用主线程。2. 保持 60fps每帧预算约 16msJS 驱动动画使用requestAnimationFrame滚动处理器做 debounce/throttle优先用 CSS 动画动画期间避免长时间运行的 JS 阻塞主线程。3. 用 Intersection Observer 替代滚动监听判断元素是否进入视口是懒加载/入场动画的常见需求Intersection Observer 由浏览器底层异步报告比高频滚动回调高效得多// 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 专用手段昂贵组件用memo()包裹避免无谓重渲染useMemo()/useCallback()缓存昂贵计算与稳定回调长列表虚拟化路由级代码分割渲染过程中避免内联创建函数会导致子组件每次重渲染用 React DevTools Profiler 定位重渲染热点。框架无关手段最小化重渲染次数、昂贵操作 debounce、缓存计算结果memoize、懒加载路由与组件。七、网络优化请求更少、载荷更小减少请求数合并小文件、用 SVG sprite 管理图标、内联小型关键资产、移除无用的第三方脚本。API 与传输优化分页而非一次拉全量数据用 GraphQL 只请求需要的字段响应压缩gzip、brotli配置 HTTP 缓存头静态资源上 CDN。面向弱网基于navigator.connection做自适应加载、乐观 UI 更新先响应用户操作再同步结果、请求优先级管理、渐进增强兜底——慢速连接下仍保证核心内容可用。八、Core Web Vitals 专项达标三大核心指标都有明确的量化目标threshold与对应打法LCP 2.5s最大内容绘制优化 hero 大图、内联关键 CSS、preload 关键资源、上 CDN、必要时 SSR/服务端渲染让最大内容尽早出现。INP 200ms交互到下一帧拆分长任务long tasks、延迟执行非关键 JS、把重计算移入 Web Worker、压缩 JS 执行时间——目标是让任何一次用户交互后都能在 200ms 内完成绘制。文档注明INP 自 2024 年 3 月起取代 FID成为正式 Core Web Vital。CLS 0.1累积布局偏移给图片、视频预留尺寸不要向已有内容上方注入新内容用 CSSaspect-ratio预留占位为广告/嵌入内容保留空间避免引发布局偏移的动画。/* Reserve space for image */ .image-container { aspect-ratio: 16 / 9; }九、监控工具与关键指标文档列出的工具栈覆盖实验室测量 真实用户测量两个层面Chrome DevToolsLighthouse、Performance 面板WebPageTest多地理位置、多网络条件的实验室测量Core Web Vitals / Chrome UX Report真实用户数据包体分析器如 webpack-bundle-analyzer生产监控Sentry、DataDog、New Relic 等 RUM 方案。追踪的关键指标LCP / INP / CLS、TTI、FCP、TBTTotal Blocking Time、包体大小、请求数。⚠️ 文档特别强调必须在真实设备 真实网络条件下测量——桌面 Chrome 配合高速网络的测量结果不具代表性。移动端设备性能更弱、网络更慢是最容易暴露问题的场景。十、NEVER 清单优化中的绝对禁区文档用一组明确的禁令划出优化工作的边界其中多条直接呼应本仓库其他能力文档的原则不测量就优化提前优化是浪费为性能牺牲可访问性——性能与 a11y 不能二选一优化时破坏既有功能——功能正确性永远优先到处用will-change——每处都会新建图层、占用内存应该只在确知昂贵且必要的动画上使用给首屏内容加懒加载——会推迟 LCP只抠微优化而忽略大问题——先修最大的瓶颈忘记移动端——通常设备更慢、连接更差。十一、验证改进没有回归的更快才算完成优化完成后必须回到测量台前后对比指标对比改造前后的 Lighthouse 分数这就是先测量后优化的闭环真实用户监控跟踪真实用户的体验变化多设备验证在低端 Android 上测试而不只是旗舰 iPhone弱网验证节流到 3G 体验回归检查确认功能没有被优化破坏用户感知是否真的感觉更快了最后一句是工作交接点当用户可感知的指标真正开始变化后把工作交给/impeccable polish做最终润色该交接命令在 SKILL.md 与 optimize.md 中有明确约定。这再次印证了整套技能的协作模型audit发现问题 →optimize修复性能 →polish收尾质感各有边界、依次接力避免无限自我打磨。十二、在本仓库中如何调用与核对该能力文档的当前版本位于 .trae-cn/skills/impeccable/reference/optimize.md英文原版对应 skill/reference/optimize.md两份内容结构一致命令注册与触发词见 .trae-cn/skills/impeccable/scripts/command-metadata.json 的optimize条目slow、laggy、janky、performance、bundle size、load time等都是建议触发词在命令体系中调用方式为/impeccable optimize [target]其中[target]指页面、组件或具体特性与/impeccable optimize在 README.md 中的速览表一一对应命令路由表中optimize被归类在Fix类目下见 SKILL.md其同级工作流为audit输出带 P0–P3 严重度的性能诊断见 audit.md 的性能维度打分 0–4optimize接手修复polish收尾。实操建议接到界面卡顿/加载慢/掉帧类需求时按本文框架执行——先在 DevTools Lighthouse 与 Performance 面板记录 LCP/INP/CLS 及请求瀑布作为基线再用瓶颈四问锁定最大问题通常是图片或主线程长任务按加载 → 渲染 → 动画 → 框架 → 网络的顺序逐层施治每完成一步就回测一次所有用户可见指标确认改善后再交给 polish 做最终打磨。坚持针对 THIS interface 的真实瓶颈修复、并测量前后差异才是本文档方法论的核心价值所在。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 impeccable optimize 性能优化实战：面向真实瓶颈的 UI 诊断、测量与修复指南
impeccable optimize 性能优化实战面向真实瓶颈的 UI 诊断、测量与修复指南【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本文面向在本项目 impeccable一套让 AI 设计与开发代理更懂设计的“设计语言/技能”中使用/impeccable optimize命令的场景完整讲解其对应能力文档 optimize.md 中先测量、后优化、再验证的 UI 性能优化方法论如何评估性能现状、锁定真实瓶颈如何在加载、渲染、动画、框架与网络五个层面系统施治以及如何用 Core Web Vitals 与回归验证收尾。读完你既能按命令直接驱动 AI 完成一次性能修复也能把整套诊断框架用于任何前端界面。optimize是 impeccable 技能体系中的Fix修复类命令。从命令元数据看它的定位是Diagnoses and fixes UI performance across loading speed, rendering, animations, images, and bundle size见 .trae-cn/skills/impeccable/scripts/command-metadata.json当用户提到 slow、laggy、janky、performance、bundle size、load time或希望界面更快更流畅时即触发。技能入口 SKILL.md 中命令表将其与audit诊断打分但不直接修复、polish最终润色等命令并置构成审计 → 优化 → 打磨的完整流水线。下文以能力文档为骨架逐层展开其全部操作要点并补充仓库源码中的佐证与关联上下文。一、核心理念性能本身就是一个功能特性优化文档开篇就给出纪律性总纲Performance is a feature. Identify the actual bottleneck for THIS interface, fix it, then measure. Dont optimize what isnt slow.翻译为可执行原则就是三点性能是产品功能的一部分不是事后的锦上添花针对这一个界面的真实瓶颈动手——拒绝套用清单式优化先搞清楚慢在哪不优化不慢的东西——没有测量依据的提前优化是浪费时间premature optimization。这与同仓库 audit.md 中的性能维度评分标准0Severe issues…4Excellent互为表里audit负责把性能问题以 P0–P3 严重度记录成报告并推荐修复命令而optimize负责真正动手修复。audit 的性能维度检查清单layout thrashing、昂贵动画、缺失懒加载、will-change滥用、bundle 体积、多余渲染恰好就是本文档优化策略的问题清单来源。二、评估现状测量是第一优先级的动作任何优化都从理解当前性能开始绝不能跳过。文档要求先测五类指标测量面具体指标Core Web VitalsLCP最大内容绘制、INP交互到下一帧、CLS累积布局偏移加载时间可交互时间TTI、首次内容绘制FCP包体体积JavaScript、CSS、图片尺寸运行时性能帧率、内存占用、CPU 占用网络请求数量、载荷大小、瀑布流waterfall随后回答瓶颈四问把模糊的慢收敛为具体的问题哪里慢首屏加载交互响应动画掉帧什么导致的大图高开销 JS布局抖动layout thrashing有多严重可感知令人烦躁还是直接阻塞操作影响谁所有用户仅移动端仅弱网用户文档在此处特别标注CRITICAL必须测量改造前与改造后的数据。Measure before and after. Premature optimization wastes time.优化只针对实际重要的环节——这也是本方法论与按模板逐条过优化项的根本区别。三、加载性能让首屏更快到达1. 图片优化图片通常是页面体量与 LCP 的最大来源策略层层递进使用现代格式 WebP / AVIF压缩率更高、质量损失小尺寸匹配——不要在 300px 的展示区加载 3000px 的原图首屏以下图片懒加载用srcset/picture提供响应式图片压缩到 80%–85% 质量文档注明该区间内人眼通常无感知使用 CDN 就近分发。文档给出的标准响应式写法可直接套用img srchero.webp srcsethero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w sizes(max-width: 400px) 400px, (max-width: 800px) 800px, 1200px loadinglazy altHero image /注意srcset按w描述符 sizes媒体条件协同工作loadinglazy只应加在首屏以下内容上见后文 NEVER 清单。2. 削减 JavaScript 包体代码分割Code splitting按路由或按组件切分Tree shaking删除未使用代码移除未使用的依赖非关键代码懒加载大组件使用动态import// Lazy load heavy component const HeavyChart lazy(() import(./HeavyChart));3. CSS 优化删除未使用的 CSS 规则关键 CSS 内联、其余异步加载压缩 CSS 文件用 CSS containment 隔离独立区域的样式影响参见渲染性能章节。4. 字体优化字体是 CLS 与 FCP 的常见隐藏元凶文档给出的要点与完整font-face示例使用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: U0020-007F; /* Basic Latin only */ }5. 加载策略编排关键资源优先非关键资源加async/defer用link relpreload预加载关键资产用prefetch预取用户下一步可能打开的页面用 Service Worker 实现离线与缓存依赖 HTTP/2 或 HTTP/3 的多路复用降低连接开销。仓库佐证impeccable 的扩展侧同样把性能当作可检测、可路由问题的来源——开发工具面板把layout-transition类问题映射到animate, optimize修复命令见 extension/devtools/panel.js说明检测出问题 → 路由到对应修复命令正是本技能的设计闭环。四、渲染性能减少强制回流与重复工作1. 消除布局抖动Layout Thrashing读写分离是渲染性能的第一课。交替读写会强迫浏览器在每个读操作前执行同步布局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 });先批量收集所有读取再一次写入浏览器只需完成一次布局计算。2. 结构级渲染优化用 CSScontain隔离独立区域的样式/布局影响范围尽量压平 DOM 深度flatter is faster减少 DOM 元素总量长列表用content-visibility: auto跳过屏幕外渲染超长列表用虚拟滚动react-window、TanStack Virtual 等。3. 减少 Paint 与 Composite这部分文档给出了一条值得特别强调的平衡原则可靠的运动应使用transform与opacity但当 blur、滤镜、mask、clip-path、阴影与颜色渐变能带来有意义的精致感时也应允许它们存在。这体现了 impeccable 一贯的立场——性能指南不是禁用特效的教条而是为可感知的质感付费为无意义的代价买单避免随意动画布局驱动属性width、height、top、left、marginwill-change只用于已知的高开销动画且必须克制它会创建新图层、占用内存滥用反而更慢昂贵 paint 区域blur/filter/shadow要更小、更孤立——把模糊作用域收缩到局部而非整屏。五、动画性能把帧预算控制在 16ms 内1. GPU 加速 vs CPU 绑定/* ✅ GPU-accelerated (fast) */ .animated { transform: translateX(100px); opacity: 0.5; } /* ❌ CPU-bound (slow) */ .animated { left: 100px; width: 300px; }transform/opacity走合成器compositorGPU 管线left/width会触发布局与绘制全程占用主线程。2. 保持 60fps每帧预算约 16msJS 驱动动画使用requestAnimationFrame滚动处理器做 debounce/throttle优先用 CSS 动画动画期间避免长时间运行的 JS 阻塞主线程。3. 用 Intersection Observer 替代滚动监听判断元素是否进入视口是懒加载/入场动画的常见需求Intersection Observer 由浏览器底层异步报告比高频滚动回调高效得多// 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 专用手段昂贵组件用memo()包裹避免无谓重渲染useMemo()/useCallback()缓存昂贵计算与稳定回调长列表虚拟化路由级代码分割渲染过程中避免内联创建函数会导致子组件每次重渲染用 React DevTools Profiler 定位重渲染热点。框架无关手段最小化重渲染次数、昂贵操作 debounce、缓存计算结果memoize、懒加载路由与组件。七、网络优化请求更少、载荷更小减少请求数合并小文件、用 SVG sprite 管理图标、内联小型关键资产、移除无用的第三方脚本。API 与传输优化分页而非一次拉全量数据用 GraphQL 只请求需要的字段响应压缩gzip、brotli配置 HTTP 缓存头静态资源上 CDN。面向弱网基于navigator.connection做自适应加载、乐观 UI 更新先响应用户操作再同步结果、请求优先级管理、渐进增强兜底——慢速连接下仍保证核心内容可用。八、Core Web Vitals 专项达标三大核心指标都有明确的量化目标threshold与对应打法LCP 2.5s最大内容绘制优化 hero 大图、内联关键 CSS、preload 关键资源、上 CDN、必要时 SSR/服务端渲染让最大内容尽早出现。INP 200ms交互到下一帧拆分长任务long tasks、延迟执行非关键 JS、把重计算移入 Web Worker、压缩 JS 执行时间——目标是让任何一次用户交互后都能在 200ms 内完成绘制。文档注明INP 自 2024 年 3 月起取代 FID成为正式 Core Web Vital。CLS 0.1累积布局偏移给图片、视频预留尺寸不要向已有内容上方注入新内容用 CSSaspect-ratio预留占位为广告/嵌入内容保留空间避免引发布局偏移的动画。/* Reserve space for image */ .image-container { aspect-ratio: 16 / 9; }九、监控工具与关键指标文档列出的工具栈覆盖实验室测量 真实用户测量两个层面Chrome DevToolsLighthouse、Performance 面板WebPageTest多地理位置、多网络条件的实验室测量Core Web Vitals / Chrome UX Report真实用户数据包体分析器如 webpack-bundle-analyzer生产监控Sentry、DataDog、New Relic 等 RUM 方案。追踪的关键指标LCP / INP / CLS、TTI、FCP、TBTTotal Blocking Time、包体大小、请求数。⚠️ 文档特别强调必须在真实设备 真实网络条件下测量——桌面 Chrome 配合高速网络的测量结果不具代表性。移动端设备性能更弱、网络更慢是最容易暴露问题的场景。十、NEVER 清单优化中的绝对禁区文档用一组明确的禁令划出优化工作的边界其中多条直接呼应本仓库其他能力文档的原则不测量就优化提前优化是浪费为性能牺牲可访问性——性能与 a11y 不能二选一优化时破坏既有功能——功能正确性永远优先到处用will-change——每处都会新建图层、占用内存应该只在确知昂贵且必要的动画上使用给首屏内容加懒加载——会推迟 LCP只抠微优化而忽略大问题——先修最大的瓶颈忘记移动端——通常设备更慢、连接更差。十一、验证改进没有回归的更快才算完成优化完成后必须回到测量台前后对比指标对比改造前后的 Lighthouse 分数这就是先测量后优化的闭环真实用户监控跟踪真实用户的体验变化多设备验证在低端 Android 上测试而不只是旗舰 iPhone弱网验证节流到 3G 体验回归检查确认功能没有被优化破坏用户感知是否真的感觉更快了最后一句是工作交接点当用户可感知的指标真正开始变化后把工作交给/impeccable polish做最终润色该交接命令在 SKILL.md 与 optimize.md 中有明确约定。这再次印证了整套技能的协作模型audit发现问题 →optimize修复性能 →polish收尾质感各有边界、依次接力避免无限自我打磨。十二、在本仓库中如何调用与核对该能力文档的当前版本位于 .trae-cn/skills/impeccable/reference/optimize.md英文原版对应 skill/reference/optimize.md两份内容结构一致命令注册与触发词见 .trae-cn/skills/impeccable/scripts/command-metadata.json 的optimize条目slow、laggy、janky、performance、bundle size、load time等都是建议触发词在命令体系中调用方式为/impeccable optimize [target]其中[target]指页面、组件或具体特性与/impeccable optimize在 README.md 中的速览表一一对应命令路由表中optimize被归类在Fix类目下见 SKILL.md其同级工作流为audit输出带 P0–P3 严重度的性能诊断见 audit.md 的性能维度打分 0–4optimize接手修复polish收尾。实操建议接到界面卡顿/加载慢/掉帧类需求时按本文框架执行——先在 DevTools Lighthouse 与 Performance 面板记录 LCP/INP/CLS 及请求瀑布作为基线再用瓶颈四问锁定最大问题通常是图片或主线程长任务按加载 → 渲染 → 动画 → 框架 → 网络的顺序逐层施治每完成一步就回测一次所有用户可见指标确认改善后再交给 polish 做最终打磨。坚持针对 THIS interface 的真实瓶颈修复、并测量前后差异才是本文档方法论的核心价值所在。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考