网页性能审计

使用 Chrome DevTools MCP 工具对网页性能进行审计。本技能聚焦于核心网页指标（Core Web Vitals）、网络优化以及高层次的可访问性缺陷。

第一步：确认 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，则已属优秀水平——需明确指出。

速查表

工作流程

复制下方清单以跟踪审计进度：

Audit Progress:
- [ ] Phase 1: Performance trace (navigate + record)
- [ ] Phase 2: Core Web Vitals analysis (includes CLS culprits)
- [ ] Phase 3: Network analysis
- [ ] Phase 4: Accessibility snapshot
- [ ] Phase 5: Codebase analysis (skip if third-party site)

阶段 1：性能追踪

1. 导航至目标 URL：

   navigate_page(url: "")
   

2. 启用自动停止并强制刷新，启动性能追踪以捕获冷加载指标：

   performance_start_trace(autoStop: true, reload: true)
   

3. 等待追踪完成，随后获取结果。

故障排查：

• 若追踪返回空结果或失败，请先使用 navigate_page 确认页面是否成功加载
• 若洞察项名称不匹配，请检查追踪响应内容，列出当前可用的 insight 名称

阶段 2：核心网页指标分析

使用 performance_analyze_insight 提取关键指标。

注意： 洞察项名称可能因 Chrome DevTools 版本不同而异。若指定的 insightName 不生效，请从追踪响应中提取 insightSetId，进而查询当前支持的全部 insight。

常用 insight 名称：

示例：

performance_analyze_insight(insightSetId: "", 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
• Speed Index：< 3.4s / < 5.8s / > 5.8s

阶段 3：网络分析

列出全部网络请求，识别优化机会：

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

重点关注：

1. 渲染阻塞资源：位于 中且未设置 async/defer/media 属性的 JS/CSS
2. 网络依赖链：因依赖其他资源而延迟发现的资源（例如 CSS @import、JS 加载字体）
3. 缺失预加载：关键资源（字体、首屏图片、核心脚本）未配置
4. 缓存问题：缺少或弱效的 Cache-Control、ETag 或 Last-Modified 响应头
5. 过大负载：未压缩或体积过大的 JS/CSS 打包产物
6. 无效 preconnect：若工具标记为“未使用”，请核实该 origin 是否有任意网络请求。若请求数为零，则确属无效——建议移除；若存在请求但加载较晚，则 preconnect 仍可能有价值。

获取单个请求详细信息：

get_network_request(reqid: )

阶段 4：可访问性快照

获取可访问性树快照：

take_snapshot(verbose: true)

标记高层次缺陷：

• 缺失或重复的 ARIA ID
• 对比度不足的元素（按 WCAG AA 标准：常规文本 ≥ 4.5:1，大号文本 ≥ 3:1）
• 焦点陷阱或缺失焦点指示器
• 无无障碍名称的交互式元素

阶段 5：代码库分析

若审计的是无代码库访问权限的第三方网站，请跳过本阶段。

分析代码库，定位可实施优化的具体位置。

识别框架与打包器

搜索配置文件以确定技术栈：

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

Tree-Shaking 与死代码

• Webpack：检查是否启用 mode: 'production'、package.json 中是否声明 sideEffects、是否启用 usedExports 优化
• Vite/Rollup：默认启用 tree-shaking；检查 treeshake 相关配置项
• 重点关注：Barrel 文件（index.js 全量 re-export）、整包引入大型工具库（如 lodash、moment）

未使用的 JS/CSS

• 区分 CSS-in-JS 与静态 CSS 提取方案
• 检查 PurgeCSS/UnCSS 配置（如 Tailwind 的 content 配置）
• 识别动态导入（dynamic import）与急切加载（eager loading）模式

Polyfill

• 检查 @babel/preset-env 的 targets 配置及 useBuiltIns 设置
• 查找 core-js 的显式导入（通常体积过大）
• 检查 browserslist 配置是否覆盖范围过宽

压缩与混淆

• 检查是否启用 terser、esbuild 或 swc 进行混淆
• 检查构建产物或服务器配置中是否启用 gzip/brotli 压缩
• 检查生产构建中是否包含 source map（应设为 external 或禁用）

输出格式

按以下结构呈现审计结果：

1. 核心网页指标摘要 —— 表格形式，含指标名、实测值及评级（良好 / 需改进 / 较差）
2. 主要问题 —— 按影响程度（高 / 中 / 低）排序的问题列表，并附预估影响值
3. 改进建议 —— 具体、可操作的修复方案，含代码片段或配置修改示例
4. 代码库发现 —— 已识别的框架/打包器类型及潜在优化点（若无代码库访问权限则省略）