web-perf · openai — скилл для Codex: что делает и как установить
Скилл запускает аудит производительности страницы через Chrome DevTools MCP. Он измеряет Core Web Vitals и находит блокирующие рендеринг ресурсы.
npx skills add openai/plugins --skill web-perf -a codexЧто делает web-perf
Скилл web-perf организует пошаговый аудит скорости веб-страницы. Он снимает трейс загрузки через Chrome DevTools MCP, после чего анализирует метрики LCP, CLS, TBT, FCP и Speed Index. Ассистент проверяет цепочки сетевых запросов, проблемы с кэшированием и заголовки ответов.
Для работы требуется настроенный MCP-сервер chrome-devtools с командой npx -y chrome-devtools-mcp@latest. Скилл вызывает функции navigate_page, performance_start_trace и list_network_requests, а также делает снимок дерева доступности. Если есть доступ к кодовой базе, ассистент изучает конфигурации сборщиков вроде Webpack или Vite для поиска неиспользуемого кода.
Ставьте этот скилл, если нужно найти точные причины медленной загрузки сайта. Без предварительно настроенного MCP-сервера аудит прервётся на первом шаге.
Какие задачи решает
- измерить Core Web Vitals и выявить причины задержки LCP
- выявить блокирующие рендеринг скрипты и таблицы стилей
- найти сдвиги макета CLS и элементы без фиксированных размеров
- проверить цепочки сетевых зависимостей и заголовки кэширования
- найти дефекты контрастности и ARIA в дереве доступности
Примеры запросов агенту
- Сделай аудит производительности для локального сайта
- Проверь LCP и сдвиги макета страницы
- Найди блокирующие рендеринг ресурсы в проекте
Как установить web-perf
1Через Skills CLI (Vercel)
npx skills add openai/plugins --skill web-perf -a codex2Вручную: положить файлы
.agents/skills/web-perf/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add openai/plugins --skill web-perf -a claude-code2Вручную: положить файлы
~/.claude/skills/web-perf/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/web-perf/
Вручную: положить файлы
.cursor/skills/web-perf/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install openai/plugins web-perf2Вручную: положить файлы
.github/skills/web-perf/SKILL.mdКомандой платформы
gemini skills install https://github.com/openai/plugins --path plugins/cloudflare/skills/web-perfВручную: положить файлы
.devin/skills/web-perf/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Claude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
Из того же набора201
Весь набор →Другие версии web-perf
Похожие
Вопросы о web-perf
Как установить web-perf в Codex?
Выполните команду npx skills add openai/plugins --skill web-perf -a codex. Конфигурация сохранится по пути .agents/skills/web-perf/SKILL.md.
Что делает скилл web-perf?
Он профилирует загрузку страницы через инструменты Chrome DevTools. Скилл рассчитывает Core Web Vitals, проверяет сеть и собирает снимок доступности.
Что нужно настроить перед началом аудита?
Требуется настроить локальный MCP-сервер chrome-devtools через npx -y chrome-devtools-mcp@latest. Без доступных вызовов navigate_page или performance_start_trace скилл сразу останавливает работу.
Исходный текст
SKILL.md · MIT
---
name: web-perf
description: Analyzes web performance using Chrome DevTools MCP. Measures Core Web Vitals (FCP, LCP, TBT, CLS, Speed Index), identifies render-blocking resources, network dependency chains, layout shifts, caching issues, and accessibility gaps. Use when asked to audit, profile, debug, or optimize page load performance, Lighthouse scores, or site speed. Biases towards retrieval from current documentation over pre-trained knowledge.
---
# Web Performance Audit
Your knowledge of web performance metrics, thresholds, and tooling APIs may be outdated. **Prefer retrieval over pre-training** when citing specific numbers or recommendations.
## Retrieval Sources
| Source | How to retrieve | Use for |
|--------|----------------|---------|
| web.dev | `https://web.dev/articles/vitals` | Core Web Vitals thresholds, definitions |
| Chrome DevTools docs | `https://developer.chrome.com/docs/devtools/performance` | Tooling APIs, trace analysis |
| Lighthouse scoring | `https://developer.chrome.com/docs/lighthouse/performance/performance-scoring` | Score weights, metric thresholds |
## 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:
```json
"chrome-devtools": {
"type": "local",
"command": ["npx", "-y", "chrome-devtools-mcp@latest"]
}
```
## 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 | `navigate_page(url: "...")` |
| 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:
```
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)
```
### Phase 1: Performance Trace
1. Navigate to the target URL:
```
navigate_page(url: "<target-url>")
```
2. Start a performance trace with reload to capture cold-load metrics:
```
performance_start_trace(autoStop: true, reload: true)
```
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 | `LCPBreakdown` | 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:
```
performance_analyze_insight(insightSetId: "<id-from-trace>", insightName: "LCPBreakdown")
```
**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:
```
list_network_requests(resourceTypes: ["Script", "Stylesheet", "Document", "Font", "Image"])
```
**Look for:**
1. **Render-blocking resources**: JS/CSS in `<head>` without `async`/`defer`/`media` attributes
2. **Network chains**: Resources discovered late because they depend on other resources loading first (e.g., CSS imports, JS-loaded fonts)
3. **Missing preloads**: Critical resources (fonts, hero images, key scripts) not preloaded
4. **Caching issues**: Missing or weak `Cache-Control`, `ETag`, or `Last-Modified` headers
5. **Large payloads**: Uncompressed or oversized JS/CSS bundles
6. **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:
```
get_network_request(reqid: <id>)
```
### Phase 4: Accessibility Snapshot
Take an accessibility tree snapshot:
```
take_snapshot(verbose: true)
```
**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 | `webpack.config.js`, `webpack.*.js` |
| 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)
2. **Top Issues** - Prioritized list of problems with estimated impact (high/medium/low)
3. **Recommendations** - Specific, actionable fixes with code snippets or config changes
4. **Codebase Findings** - Framework/bundler detected, optimization opportunities (omit if no codebase access)
© Cloudflare · MIT · openai/plugins