web-perf

Web Performance Audit — навык Cloudflare для проверки производительности веб-страниц через Chrome DevTools MCP. Он предназначен для аудита, профилирования, отладки и оптимизации загрузки, но не подменяет измерение конкретного сайта общими советами. Для числовых порогов и рекомендаций источник предлагает обращаться к web.dev, документации Chrome DevTools и документации Lighthouse, потому что методики и API инструментов могут обновляться. Перед началом нужно проверить наличие MCP-инструментов: навык предлагает вызвать navigate_page или performance_start_trace. Если сервер chrome-devtools не настроен, workflow останавливается; вместо обхода проверки нужно подключить сервер с командой npx -y chrome-devtools-mcp@latest. Работа разделена на пять фаз. Сначала страницу открывают через navigate_page, затем запускают холодную запись performance_start_trace с autoStop и reload. Если trace пустой или завершился ошибкой, сначала проверяют, что страница действительно загрузилась, а при расхождении названий insight изучают доступные ответы trace. На второй фазе разбираются Core Web Vitals и связанные показатели. Источник перечисляет TTFB, FCP, LCP, INP, TBT, CLS и Speed Index, а также ориентиры good, needs-improvement и poor: например, LCP ниже 2,5 секунды считается хорошим, от 2,5 до 4 секунд требует внимания, а выше 4 секунд относится к плохому диапазону; для CLS приведены границы 0,1 и 0,25. Эти числа нужно применять к полученному измерению, а не выдавать как результат без trace. Третья фаза изучает сетевые запросы Document, Script, Stylesheet, Font и Image. Проверяются render-blocking ресурсы в head, поздно обнаруженные зависимости, отсутствие preload для действительно критичных ресурсов, Cache-Control, ETag и Last-Modified, размер и сжатие payload. Неиспользуемый preconnect можно рекомендовать удалить только после проверки, что к его origin не было ни одного запроса; наличие запросов, загруженных поздно, означает другую проблему. Отчёт должен быть конкретным: вместо общего совета об оптимизации изображений нужно назвать файл, его размер и измеримый ожидаемый эффект. Изменения с нулевым estimated impact не следует приоритизировать. Четвёртая фаза использует accessibility snapshot и ищет дублирующиеся ARIA ID, слабый контраст по WCAG AA, focus traps, отсутствие focus indicator и интерактивные элементы без доступного имени. Пятая фаза применяется только когда доступна кодовая база. Для проекта определяют framework и bundler по конфигурационным файлам, затем проверяют tree-shaking, barrel-файлы, тяжёлые импорты, dynamic imports, eager loading, polyfills, browserslist, gzip или Brotli и source maps. Для Next.js, Vite, Webpack и других стеков используются соответствующие реальные конфигурации; аудит стороннего сайта без исходников эту фазу пропускает. Итоговый формат состоит из сводки Core Web Vitals с метрикой, значением и оценкой, приоритизированных проблем с оценкой влияния, конкретных рекомендаций и, если есть доступ к исходникам, codebase findings. Ограничение навыка важно: он описывает воспроизводимый маршрут сбора и интерпретации данных Chrome DevTools MCP, но сам по себе не доказывает проблему, не выбирает исправление без проверки и не гарантирует одинаковый выигрыш для разных приложений. Каждая рекомендация должна опираться на trace, сетевой запрос, DOM, snapshot или фактическую конфигурацию проекта.