web-perf

Web 性能审计

你对 Web 性能指标、阈值和工具 API 的了解可能已经过时。引用具体数字或建议时，优先检索，而非依赖预训练知识。

检索来源

来源	检索方式	用途
web.dev	https://web.dev/articles/vitals	Core Web Vitals 阈值、定义
Chrome DevTools 文档	https://developer.chrome.com/docs/devtools/performance	工具 API、跟踪分析
Lighthouse 评分	https://developer.chrome.com/docs/lighthouse/performance/performance-scoring	评分权重、指标阈值

首先：确认可用的 MCP 工具

开始前，先发现可用的浏览器和性能工具。根据所请求的审计，使用可用的功能。如果跟踪工具不可用，请继续进行有用的来源或网络分析，并说明无法收集哪些测量结果。

如果用户需要设置 Chrome DevTools MCP，请查阅其安装指南，并使用最新的软件包版本。只有在设置属于用户授权范围时，才更改 MCP 配置；否则请先征求同意。对于使用 command 和 args 的客户端，服务器条目示例如下：

"chrome-devtools": {
  "command": "npx",
  "args": ["-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>)
A11y 快照	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 阶段：核心 Web 指标分析

使用 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. 代码库发现 - 检测到的框架/打包工具、优化机会（如果无法访问代码库，则省略）