web-perf

Web 性能审计

使用 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，说明其表现已经很出色。

快速参考

任务	工具调用
加载页面	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)

工作流

复制以下检查清单以跟踪进度：

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: "<target-url>")
   

2. 重新加载并开始性能追踪，以捕获冷加载指标：

   performance_start_trace(autoStop: true, reload: true)
   

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

故障排查：

• 如果追踪结果为空或失败，请先用 navigate_page 确认页面已正确加载
• 如果洞察名称不匹配，请检查追踪响应，列出可用洞察

阶段 2：Core Web Vitals 分析

使用 performance_analyze_insight 提取关键指标。

注意： 不同版本的 Chrome DevTools 中，洞察名称可能有所不同。如果某个洞察名称不起作用，请检查追踪响应中的 insightSetId，以查找可用洞察。

常见洞察名称：

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

示例：

performance_analyze_insight(insightSetId: "<id-from-trace>", 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. 阻塞渲染的资源：<head> 中未设置 async/defer/media 属性的 JS/CSS
2. 网络请求链：因依赖其他资源先加载而延迟发现的资源（例如，CSS 导入、由 JS 加载的字体）
3. 缺少预加载：未预加载的关键资源（字体、主视觉图片、关键脚本）
4. 缓存问题：缺少或较弱的 Cache-Control、ETag 或 Last-Modified 标头
5. 较大的负载：未压缩或体积过大的 JS/CSS 包
6. 未使用的预连接：如果有相关提示，请检查是否有任何请求发往该源。如果没有请求，则可确定该预连接未使用，建议移除。如果存在请求但加载较晚，预连接仍可能有价值。

查看详细请求信息：

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 中的框架依赖和构建脚本。

Tree-Shaking 和死代码

• Webpack：检查 mode: 'production'、package.json 中的 sideEffects、usedExports 优化
• Vite/Rollup：默认启用 Tree-Shaking；检查 treeshake 选项
• 查找：汇总文件（index.js 再导出）、整体导入的大型工具库（lodash、moment）

未使用的 JS/CSS

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

Polyfill

• 检查 @babel/preset-env 的目标和 useBuiltIns 设置
• 查找 core-js 导入（通常体积过大）
• 检查 browserslist 配置是否涵盖了过多浏览器

压缩和最小化

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

输出格式

按以下格式呈现发现：

1. Core Web Vitals 概览——包含指标、数值和评级（良好/需改进/较差）的表格
2. 主要问题——按优先级列出问题，并估算影响（高/中/低）
3. 建议——提供具体、可执行的修复方案，并附代码片段或配置更改
4. 代码库发现——检测到的框架/打包工具、优化机会（无法访问代码库时省略）