name: 网络性能审计 description: 使用 Chrome DevTools MCP 审计网页性能。在要求审计、分析、调试或优化页面加载性能、Lighthouse 得分或网站速度时使用。 license: MIT

网络性能审计

使用 Chrome DevTools MCP 工具审计网页性能。此技能侧重于核心 Web 指标、网络优化和高级可访问性差距。

第一步：验证 MCP 工具可用

在开始前运行此步骤。 尝试调用 navigate_page 或 performance_start_trace。如果不可用，停止——chrome-devtools MCP 服务器未配置。

请用户将此添加到他们的 MCP 配置中：

"chrome-devtools": {
  "type": "local",
  "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
}

关键指南

自信断言：通过检查网络请求、DOM 或代码库验证声明——然后明确陈述发现。
推荐前验证：在建议移除前确认某物未使用。
量化影响：使用从洞察中估计的节省。不要优先考虑影响为 0ms 的更改。
跳过非问题：如果渲染阻塞资源有 0ms 估计影响，记下但不建议操作。
具体说明：说“将 hero.png (450KB) 压缩为 WebP”，而不是“优化图像”。
无情优先：如果站点 LCP 为 200ms 且 CLS 为 0，则已非常优秀——如实说明。

快速参考

任务	工具调用
加载页面	`navigate_page(url: "...")`
开始跟踪	`performance_start_trace(autoStop: true, reload: true)`
分析洞察	`performance_analyze_insight(insightSetId: "...", insightName: "...")`
列出请求	`list_network_requests(resourceTypes: ["Script", "Stylesheet", ...])`
请求详情	`get_network_request(reqid: <id>)`
可访问性快照	`take_snapshot(verbose: true)`

工作流

复制此清单以跟踪进度：

审计进度：
- [ ] 阶段 1：性能跟踪（导航 + 记录）
- [ ] 阶段 2：核心 Web 指标分析（包括 CLS 罪魁祸首）
- [ ] 阶段 3：网络分析
- [ ] 阶段 4：可访问性快照
- [ ] 阶段 5：代码库分析（如果是第三方站点，跳过）

阶段 1：性能跟踪

导航到目标 URL：
```
navigate_page(url: "<目标-url>")
```
使用重载启动性能跟踪以捕获冷加载指标：
```
performance_start_trace(autoStop: true, reload: true)
```
等待跟踪完成，然后检索结果。

故障排除：

如果跟踪返回空或失败，先用 navigate_page 验证页面是否正确加载
如果洞察名称不匹配，检查跟踪响应以列出可用洞察

阶段 2：核心 Web 指标分析

使用 performance_analyze_insight 提取关键指标。

注意： 洞察名称可能因 Chrome DevTools 版本而异。如果某个洞察名称无效，检查跟踪响应中的 insightSetId 以发现可用洞察。

常见洞察名称：

指标	洞察名称	查看内容
LCP	`LCPBreakdown`	最大内容绘制时间；TTFB、资源加载、渲染延迟的分解
CLS	`CLSCulprits`	导致布局偏移的元素（无尺寸的图像、注入内容、字体交换）
渲染阻塞	`RenderBlocking`	阻止首次绘制的 CSS/JS
文档延迟	`DocumentLatency`	服务器响应时间问题
网络依赖	`NetworkRequestsDepGraph`	延迟关键资源的请求链

示例：

performance_analyze_insight(insightSetId: "<从跟踪获取的id>", insightName: "LCPBreakdown")

关键阈值（优秀/需要改进/差）：

TTFB: < 800ms / < 1.8s / > 1.8s
FCP: < 1.8s / < 3s / > 3s
LCP: < 2.5s / < 4s / > 4s
INP: < 200ms / < 500ms / > 500ms
TBT: < 200ms / < 600ms / > 600ms
CLS: < 0.1 / < 0.25 / > 0.25
速度指数: < 3.4s / < 5.8s / > 5.8s

阶段 3：网络分析

列出所有网络请求以识别优化机会：

list_network_requests(resourceTypes: ["Script", "Stylesheet", "Document", "Font", "Image"])

查找：

渲染阻塞资源：在 <head> 中没有 async/defer/media 属性的 JS/CSS
网络链：由于依赖其他资源首先加载而延迟发现的资源（例如，CSS 导入、JS 加载的字体）
缺少预加载：未预加载的关键资源（字体、英雄图像、关键脚本）
缓存问题：缺少或弱的 Cache-Control、ETag 或 Last-Modified 头部
大负载：未压缩或过大的 JS/CSS 捆绑包
未使用的预连接：如果被标记，通过检查是否有任何请求发送到该源验证。如果零请求，它肯定未使用——建议移除。如果请求存在但加载晚，预连接可能仍有价值。

获取详细请求信息：

get_network_request(reqid: <id>)

阶段 4：可访问性快照

获取可访问性树快照：

take_snapshot(verbose: true)

标记高级差距：

缺少或重复的 ARIA ID
对比度差的元素（对照 WCAG AA：普通文本 4.5:1，大文本 3:1）
焦点陷阱或缺少焦点指示器
无可访问名称的交互元素

阶段 5：代码库分析

如果审计没有代码库访问权限的第三方站点，跳过。

分析代码库以了解可改进的地方。

检测框架和打包工具

搜索配置文件以识别堆栈：

工具	配置文件
Webpack	`webpack.config.js`, `webpack.*.js`
Vite	`vite.config.js`, `vite.config.ts`
Rollup	`rollup.config.js`, `rollup.config.mjs`
esbuild	`esbuild.config.js`, 包含 `esbuild` 的构建脚本
Parcel	`.parcelrc`, `package.json`（parcel 字段）
Next.js	`next.config.js`, `next.config.mjs`
Nuxt	`nuxt.config.js`, `nuxt.config.ts`
SvelteKit	`svelte.config.js`
Astro	`astro.config.mjs`

同时检查 package.json 中的框架依赖项和构建脚本。

树摇和死代码

Webpack：检查 mode: 'production', package.json 中的 sideEffects, usedExports 优化
Vite/Rollup：默认启用树摇；检查 treeshake 选项
查找：桶文件（index.js 重新导出），大量导入的实用程序库（lodash, moment）

未使用的 JS/CSS

检查 CSS-in-JS 与静态 CSS 提取
查找 PurgeCSS/UnCSS 配置（Tailwind 的 content 配置）
识别动态导入与热切加载

填充

检查 @babel/preset-env 目标和 useBuiltIns 设置
查找 core-js 导入（通常过大）
检查 browserslist 配置是否目标过宽

压缩和最小化

检查 terser、esbuild 或 swc 最小化
查找构建输出或服务器配置中的 gzip/brotli 压缩
检查生产构建中的源映射（应为外部或禁用）

输出格式

以以下形式呈现发现：

核心 Web 指标摘要 - 包含指标、值和评级（优秀/需要改进/差）的表格
顶级问题 - 优先排序的问题列表，附估计影响（高/中/低）
推荐 - 具体、可操作的修复方案，带代码片段或配置更改
代码库发现 - 检测到的框架/打包工具、优化机会（如无代码库访问，省略）