web-perf

web-perf 技能概览

web-perf 的作用

web-perf 技能帮助你借助 Chrome DevTools MCP 审计并提升页面速度，而不是只凭截图或一个 Lighthouse 分数去猜测。它聚焦 Core Web Vitals、基于 trace 的诊断、网络瀑布图、渲染阻塞、布局偏移、缓存，以及相关的可访问性/性能问题。

适合谁使用

如果你需要对真实网站做一次务实的性能排查，尤其是当你想解释为什么页面感觉慢、为什么某项指标回退、或者到底是哪个资源拖慢了加载时，就该用这个 web-perf 技能。它非常适合 Performance Optimization 场景，因为这类工作更看重证据，而不是泛泛建议。

它有什么不同

web-perf 的核心价值在于，它倾向于从当前文档和 DevTools 数据里实时检索，而不是依赖过时的经验模型。这样一来，它在处理依赖准确指标定义、trace 解读或当前工具行为的决策时更有优势。对于不需要性能追踪的宽泛 SEO 审计或设计评审，它就没那么合适。

如何使用 web-perf 技能

安装并验证环境

先通过你的 skills manager 运行 web-perf install 流程，然后在请求分析之前确认 Chrome DevTools MCP server 确实可用。这个技能需要 DevTools 访问权限；如果 MCP 工具缺失，工作流应该尽早停止，而不是编造结果。

提供一个“性能型”提示词

一个高质量的 web-perf usage 提示词，应当明确页面、症状，以及 agent 复现或检查所需的上下文。比如：“审计移动端首页，重点查看最新版本发布后 LCP 回退的问题。关注阻塞 CSS、首屏图片传输，以及 trace 证据。”这比“让这个站点更快”更好，因为它告诉技能要测什么、该看哪里。

先读对文件

先看 SKILL.md，再顺着仓库里链接的文档，了解检索来源、工具检查或分析步骤。这个仓库里没有额外的辅助文件夹，所以主要决策点都在技能文件本身。尤其要留意那些要求 agent 验证 MCP 工具、优先使用检索、并且以 trace 证据而不是假设为依据的部分。

使用与问题匹配的工作流

如果是诊断，要求给出基于 trace 的根因分析和一份简短修复清单。 如果是优化，要求先列出最可能带来最大收益的改进，而不是给你一份穷尽式检查表。 如果是排查回退，提供变更前后、URL、设备类型，以及你更关注 LCP、INP 还是 CLS。输入越具体，模型就越不需要猜 web-perf guide 该走哪条路径。

web-perf 技能 FAQ

web-perf 只适合 Lighthouse 式审计吗？

不是。它当然适用于 Lighthouse 相关工作，但更强的用法是借助 DevTools MCP 做基于 trace 的调试。也就是说，它不仅能帮你知道指标变了，还能帮你理解为什么变了。

我需要很懂 Chrome DevTools 吗？

不一定。这个技能对能清楚描述问题的新手也很有用。你不需要成为 trace 专家，但至少要提供足够上下文，让 agent 知道哪一个页面、哪种设备、哪类症状最重要。

什么时候不该用 web-perf？

当你想做的是通用前端重构、视觉设计评审，或者答案不依赖运行时证据时，就不要用它。如果你没法提供要检查的页面，或者没有可用的 DevTools MCP，这个技能就会被阻断。

它和普通提示词相比强在哪？

普通提示词通常停留在高层概述。web-perf 技能更可操作，因为它会推动你使用最新文档、明确的工具检查，以及可测量的原因，比如渲染阻塞、依赖链、布局偏移来源和缓存行为。对于 Performance Optimization 来说，它比一次性的聊天指令更强。

如何改进 web-perf 技能

提供可追踪的输入，不要只说模糊目标

想让 web-perf 的结果更好，最有效的方法是提供 URL、目标设备、测试条件，以及你最关心的指标。 “提升结账速度”太弱。 “在中端 Android、快速 4G 条件下，审计结账页在新版 hero banner 上线后的 LCP 和 CLS”要好得多。

提供变更窗口和怀疑对象

如果你知道改了什么，就直接说出来。发布说明、最近的 CMS 更新、新接入的第三方脚本，或者重新设计过的 hero，往往都能把排查方向引到正确位置。这样技能就能测试更可能的原因，而不是盲目扫完整个页面。

要求证据和优先级明确的修复路径

有用的 web-perf 输出，应该把已确认原因和可能原因区分开来，然后按用户影响和实现成本对修复项排序。如果第一次回答过于宽泛，就要求它给出前两个瓶颈、支撑这些判断的 trace 证据，以及能最小化风险并验证改进的变更方案。

用前后对比指标持续迭代

把第一次结果当作诊断，而不是结案。修复后，用相同的页面和条件重新跑一遍同样的 web-perf workflow，这样输出才能稳定对比 trace 证据和指标。这样做是把 web-perf guide 变成可重复优化循环的最快方式。