Web Perf
2026-03-28
新闻来源：网淘吧
围观:57
电脑广告
手机广告
网站性能审计
使用Chrome DevTools MCP工具审计网页性能。此技能侧重于核心网页指标、网络优化和高层次的无障碍访问差距。
首先：验证MCP工具是否可用
在开始前运行此步骤。尝试调用navigate_page或performance_start_trace。如果不可用，请停止——chrome-devtools MCP服务器未配置。
请用户将其添加到他们的MCP配置中：
"chrome-devtools": {
"type": "local",
"command": ["npx", "-y", "chrome-devtools-mcp@latest"]
}
关键指引
- 断言式验证：通过检查网络请求、DOM或代码库来验证声明——然后明确地陈述发现。
- 推荐前先验证：在建议移除之前，确认某些内容未被使用。
- 量化影响：使用从洞察中估算的节省。不要优先处理影响为0毫秒的更改。
- 跳过非问题：如果渲染阻塞资源的预估影响为0毫秒，请记录但不要建议采取行动。
- 具体明确：请说“将hero.png（450KB）压缩为WebP格式”，而不是“优化图片”。
- 严格划分优先级：一个LCP为200毫秒且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)
第一阶段：性能追踪
-
导航到目标URL：
navigate_page(url: "<target-url>") -
启动一个带重新加载的性能跟踪以捕获冷加载指标：
performance_start_trace(autoStop: true, reload: true) -
等待跟踪完成，然后检索结果。
故障排除：
- 如果跟踪返回为空或失败，请先使用
navigate_page验证页面是否正确加载 - 如果洞察名称不匹配，请检查跟踪响应以列出可用的洞察
第二阶段：核心网页指标分析
使用performance_analyze_insight提取关键指标。
注意：洞察名称可能因Chrome DevTools版本而异。如果某个洞察名称不起作用，请检查insightSetId从跟踪响应中发现可用的洞察。
常见的洞察名称：
| 指标 | 洞察名称 | 查找内容 |
|---|---|---|
| LCP | LCP 分解 | 最大内容绘制时间的细分：TTFB、资源加载、渲染延迟 |
| CLS | CLS 问题来源 | 导致布局偏移的元素（无尺寸图像、注入内容、字体切换） |
| 渲染阻塞 | 渲染阻塞 | CSS/JS 阻塞首次绘制 |
| 文档延迟 | 文档延迟 | 服务器响应时间问题 |
| 网络依赖 | 网络请求依赖图 | 延迟关键资源的请求链 |
示例：
performance_analyze_insight(insightSetId: "<id-from-trace>", insightName: "LCPBreakdown")
关键阈值（良好/需改进/差）：
- TTFB：< 800毫秒 / < 1.8秒 / > 1.8秒
- FCP：< 1.8秒 / < 3秒 / > 3秒
- LCP：< 2.5秒 / < 4秒 / > 4秒
- INP：< 200毫秒 / < 500毫秒 / > 500毫秒
- TBT：< 200毫秒 / < 600毫秒 / > 600毫秒
- CLS：< 0.1 / < 0.25 / > 0.25
- 速度指数：< 3.4秒 / < 5.8秒 / > 5.8秒
第三阶段：网络分析
列出所有网络请求以识别优化机会：
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>)
第四阶段：可访问性快照
获取可访问性树快照：
take_snapshot(verbose: true)
标记高级别问题：
- 缺失或重复的ARIA ID
- 对比度差的元素（对照WCAG AA标准检查：普通文本需达到4.5:1，大文本需达到3:1）
- 焦点陷阱或缺失的焦点指示器
- 无无障碍名称的交互元素
第五阶段：代码库分析
如果审计的是无法访问代码库的第三方网站，则跳过此阶段。
分析代码库，以了解可在何处进行改进。
检测框架与打包工具
通过搜索配置文件来识别技术栈：
| 工具 | 配置文件 |
|---|---|
| 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.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'、sideEffects在 package.json 中的设置、usedExports优化 - Vite/Rollup: Tree-shaking 默认启用；检查
摇树优化选项 - 查找：桶文件（
index.js重新导出），整体导入的大型工具库（lodash、moment）
未使用的JS/CSS
- 检查CSS-in-JS与静态CSS提取
- 查找PurgeCSS/UnCSS配置（Tailwind的
content配置） - 识别动态导入与急切加载
Polyfills
- 检查
@babel/preset-env目标和useBuiltIns设置 - 查找
core-js导入（通常体积过大） - 检查
browserslist配置中是否存在过于宽泛的目标浏览器设置
压缩与最小化
- 检查是否使用了
Terser、esbuild或SWC进行最小化处理 - 在构建输出或服务器配置中查找gzip/brotli压缩
- 检查生产构建中的源映射（应为外部或已禁用）
输出格式
按以下格式呈现发现：
- 核心网页指标摘要- 包含指标、数值和评级（良好/需改进/差）的表格
- 主要问题- 按优先级排序的问题列表，附带预估影响（高/中/低）
- 建议- 具体、可操作的修复方案，附带代码片段或配置更改
- 代码库发现- 检测到的框架/打包器，优化机会（若无代码库访问权限则省略）
微信扫一扫，打赏作者吧～文章底部电脑广告
手机广告位-内容正文底部
