Web Performance Audit
Audit web page performance using Chrome DevTools MCP tools. This skill focuses on Core Web Vitals, network optimization, and high-level accessibility gaps.
FIRST: Verify MCP Tools Available
Run this before starting. Try calling navigate_page or performance_start_trace. If unavailable, STOP—the chrome-devtools MCP server isn't configured.
Ask the user to add this to their MCP config:
CODEBLOCK0
Key Guidelines
- - Be assertive: Verify claims by checking network requests, DOM, or codebase—then state findings definitively.
- Verify before recommending: Confirm something is unused before suggesting removal.
- Quantify impact: Use estimated savings from insights. Don't prioritize changes with 0ms impact.
- Skip non-issues: If render-blocking resources have 0ms estimated impact, note but don't recommend action.
- Be specific: Say "compress hero.png (450KB) to WebP" not "optimize images".
- Prioritize ruthlessly: A site with 200ms LCP and 0 CLS is already excellent—say so.
Quick Reference
| Task | Tool Call |
|---|
| Load page | INLINECODE2 |
| Start trace |
performance_start_trace(autoStop: true, reload: true) |
| Analyze insight |
performance_analyze_insight(insightSetId: "...", insightName: "...") |
| List requests |
list_network_requests(resourceTypes: ["Script", "Stylesheet", ...]) |
| Request details |
get_network_request(reqid: <id>) |
| A11y snapshot |
take_snapshot(verbose: true) |
Workflow
Copy this checklist to track progress:
CODEBLOCK1
Phase 1: Performance Trace
- 1. Navigate to the target URL:
CODEBLOCK2
- 2. Start a performance trace with reload to capture cold-load metrics:
CODEBLOCK3
- 3. Wait for trace completion, then retrieve results.
Troubleshooting:
- - If trace returns empty or fails, verify the page loaded correctly with
navigate_page first - If insight names don't match, inspect the trace response to list available insights
Phase 2: Core Web Vitals Analysis
Use performance_analyze_insight to extract key metrics.
Note: Insight names may vary across Chrome DevTools versions. If an insight name doesn't work, check the insightSetId from the trace response to discover available insights.
Common insight names:
| Metric | Insight Name | What to Look For |
|---|
| LCP | INLINECODE11 | Time to largest contentful paint; breakdown of TTFB, resource load, render delay |
| CLS |
CLSCulprits | Elements causing layout shifts (images without dimensions, injected content, font swaps) |
| Render Blocking |
RenderBlocking | CSS/JS blocking first paint |
| Document Latency |
DocumentLatency | Server response time issues |
| Network Dependencies |
NetworkRequestsDepGraph | Request chains delaying critical resources |
Example:
CODEBLOCK4
Key thresholds (good/needs-improvement/poor):
- - 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
Phase 3: Network Analysis
List all network requests to identify optimization opportunities:
CODEBLOCK5
Look for:
- 1. Render-blocking resources: JS/CSS in
<head> without async/defer/media attributes - Network chains: Resources discovered late because they depend on other resources loading first (e.g., CSS imports, JS-loaded fonts)
- Missing preloads: Critical resources (fonts, hero images, key scripts) not preloaded
- Caching issues: Missing or weak
Cache-Control, ETag, or Last-Modified headers - Large payloads: Uncompressed or oversized JS/CSS bundles
- Unused preconnects: If flagged, verify by checking if ANY requests went to that origin. If zero requests, it's definitively unused—recommend removal. If requests exist but loaded late, the preconnect may still be valuable.
For detailed request info:
CODEBLOCK6
Phase 4: Accessibility Snapshot
Take an accessibility tree snapshot:
CODEBLOCK7
Flag high-level gaps:
- - Missing or duplicate ARIA IDs
- Elements with poor contrast ratios (check against WCAG AA: 4.5:1 for normal text, 3:1 for large text)
- Focus traps or missing focus indicators
- Interactive elements without accessible names
Phase 5: Codebase Analysis
Skip if auditing a third-party site without codebase access.
Analyze the codebase to understand where improvements can be made.
Detect Framework & Bundler
Search for configuration files to identify the stack:
| Tool | Config Files |
|---|
| Webpack | INLINECODE23 , INLINECODE24 |
| Vite |
vite.config.js,
vite.config.ts |
| Rollup |
rollup.config.js,
rollup.config.mjs |
| esbuild |
esbuild.config.js, build scripts with
esbuild |
| Parcel |
.parcelrc,
package.json (parcel field) |
| Next.js |
next.config.js,
next.config.mjs |
| Nuxt |
nuxt.config.js,
nuxt.config.ts |
| SvelteKit |
svelte.config.js |
| Astro |
astro.config.mjs |
Also check package.json for framework dependencies and build scripts.
Tree-Shaking & Dead Code
- - Webpack: Check for
mode: 'production', sideEffects in package.json, usedExports optimization - Vite/Rollup: Tree-shaking enabled by default; check for
treeshake options - Look for: Barrel files (
index.js re-exports), large utility libraries imported wholesale (lodash, moment)
Unused JS/CSS
- - Check for CSS-in-JS vs. static CSS extraction
- Look for PurgeCSS/UnCSS configuration (Tailwind's
content config) - Identify dynamic imports vs. eager loading
Polyfills
- - Check for
@babel/preset-env targets and useBuiltIns setting - Look for
core-js imports (often oversized) - Check
browserslist config for overly broad targeting
Compression & Minification
- - Check for
terser, esbuild, or swc minification - Look for gzip/brotli compression in build output or server config
- Check for source maps in production builds (should be external or disabled)
Output Format
Present findings as:
- 1. Core Web Vitals Summary - Table with metric, value, and rating (good/needs-improvement/poor)
- Top Issues - Prioritized list of problems with estimated impact (high/medium/low)
- Recommendations - Specific, actionable fixes with code snippets or config changes
- Codebase Findings - Framework/bundler detected, optimization opportunities (omit if no codebase access)
Web 性能审计
使用 Chrome DevTools MCP 工具审计网页性能。本技能专注于核心网页指标、网络优化以及高层次的可访问性差距。
第一步：验证 MCP 工具可用
在开始前执行此操作。 尝试调用 navigatepage 或 performancestart_trace。如果不可用，则停止——chrome-devtools MCP 服务器未配置。
请用户将此配置添加到其 MCP 配置中：
json
chrome-devtools: {
type: local,
command: [npx, -y, chrome-devtools-mcp@latest]
}
关键指南
- - 果断断言：通过检查网络请求、DOM 或代码库来验证声明——然后明确陈述发现。
- 先验证再推荐：在建议移除之前，确认某物未被使用。
- 量化影响：使用洞察中的预估节省量。不要优先处理影响为 0ms 的更改。
- 跳过非问题：如果渲染阻塞资源预估影响为 0ms，则注明但不建议采取行动。
- 具体明确：说“将 hero.png（450KB）压缩为 WebP”，而不是“优化图片”。
- 无情排序：一个 LCP 为 200ms 且 CLS 为 0 的网站已经非常出色——如实说明。
快速参考
| 任务 | 工具调用 |
|---|
| 加载页面 | navigatepage(url: ...) |
| 开始跟踪 |
performancestart_trace(autoStop: true, reload: true) |
| 分析洞察 | performance
analyzeinsight(insightSetId: ..., insightName: ...) |
| 列出请求 | list
networkrequests(resourceTypes: [Script, Stylesheet, ...]) |
| 请求详情 | get
networkrequest(reqid:
) |
| 可访问性快照 | take_snapshot(verbose: true) |
工作流程
复制此清单以跟踪进度：
审计进度：
- - [ ] 阶段 1：性能跟踪（导航 + 记录）
- [ ] 阶段 2：核心网页指标分析（包括 CLS 罪魁祸首）
- [ ] 阶段 3：网络分析
- [ ] 阶段 4：可访问性快照
- [ ] 阶段 5：代码库分析（如果是第三方网站则跳过）
阶段 1：性能跟踪
- 1. 导航到目标 URL：
navigate_page(url: )
- 2. 启动带重新加载的性能跟踪以捕获冷加载指标：
performancestarttrace(autoStop: true, reload: true)
- 3. 等待跟踪完成，然后检索结果。
故障排除：
- - 如果跟踪返回空或失败，请先使用 navigate_page 验证页面是否正确加载
- 如果洞察名称不匹配，请检查跟踪响应以列出可用的洞察
阶段 2：核心网页指标分析
使用 performanceanalyzeinsight 提取关键指标。
注意： 洞察名称可能因 Chrome DevTools 版本而异。如果某个洞察名称不起作用，请检查跟踪响应中的 insightSetId 以发现可用的洞察。
常见洞察名称：
| 指标 | 洞察名称 | 需要关注的内容 |
|---|
| LCP | LCPBreakdown | 最大内容绘制时间；TTFB、资源加载、渲染延迟的分解 |
| CLS |
CLSCulprits | 导致布局偏移的元素（无尺寸的图片、注入内容、字体切换） |
| 渲染阻塞 | RenderBlocking | 阻塞首次绘制的 CSS/JS |
| 文档延迟 | DocumentLatency | 服务器响应时间问题 |
| 网络依赖 | NetworkRequestsDepGraph | 延迟关键资源的请求链 |
示例：
performanceanalyzeinsight(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
- 速度指数：< 3.4s / < 5.8s / > 5.8s
阶段 3：网络分析
列出所有网络请求以识别优化机会：
listnetworkrequests(resourceTypes: [Script, Stylesheet, Document, Font, Image])
查找以下内容：
- 1. 渲染阻塞资源： 中没有 async/defer/media 属性的 JS/CSS
- 网络链：由于依赖其他资源先加载而发现较晚的资源（例如，CSS 导入、JS 加载的字体）
- 缺少预加载：未预加载的关键资源（字体、主图、关键脚本）
- 缓存问题：缺少或弱化的 Cache-Control、ETag 或 Last-Modified 标头
- 大负载：未压缩或过大的 JS/CSS 包
- 未使用的预连接：如果被标记，通过检查是否有任何请求发往该源来验证。如果零请求，则明确未使用——建议移除。如果存在请求但加载较晚，预连接可能仍有价值。
获取详细请求信息：
getnetworkrequest(reqid: )
阶段 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 压缩
- 检查生产构建中的源映射（应为外部或禁用）
输出格式
按以下方式呈现发现：
- 1. 核心网页指标摘要 - 包含指标、值和评级（良好/需改进/较差）的表格
- 主要问题 - 按预估影响（高/中/低）排序的优先级问题列表
- 建议 - 带有代码片段或配置更改的具体、可操作的修复方案
4.
