Аудит скорости CWV
Сначала полевые данные по шаблонам и URL, затем лабораторные гипотезы и DevTools. На выходе — таблица правок с ожидаемым эффектом, критериями приёмки и порядком внедрения, а не общий список из Lighthouse.
Почему один Lighthouse не объясняет красные CWV в GSC?
1
Слепое следование Lighthouse
Один лабораторный прогон не показывает реальную картину. Без полевых данных (CrUX) оптимизация превращается в гадание.
2
Нет понимания главной причины
Отчёт пестрит десятками рекомендаций, но непонятно, что именно даст наибольший эффект. Ресурсы распыляются.
3
Негативное влияние на ранжирование и конверсии
Плохие CWV снижают позиции и отталкивают пользователей. Каждая лишняя секунда загрузки стоит проценты конверсии.
4
Трудности с INP (Interaction to Next Paint)
Новая метрика отзывчивости выявляет тяжёлый JavaScript. Команда не знает, как профилировать и устранять long tasks.
Что входит в аудит скорости и CWV
Сначала полевые данные по шаблонам и URL, затем лабораторные гипотезы и DevTools. На выходе — таблица правок с ожидаемым эффектом, критериями приёмки и порядком внедрения, а не общий список из Lighthouse.
CrUX и GSC
Группировка URL по отчёту CWV, связка с шаблонами и трафиком; отделение шума от устойчивых красных зон.
- Срезы по mobile/desktop и ключевым сегментам
- Выбор репрезентативных URL на шаблон
- Сопоставление с релизами по датам
LCP
LCP‑элемент, приоритет загрузки, форматы изображений, preload/fetchpriority; цепочка до первого отрисованного кадра.
- Сжатие и размеры без потери визуала
- Узкие места CDN и кэша для LCP‑ресурса
- Критерии приёмки в миллисекундах на пилоте
INP и main thread
Long tasks, обработчики ввода, тяжёлая гидратация; план дробления бандла и отложенной работы.
- Профилирование конкретных сценариев (корзина, фильтры)
- Разгрузка третьих сторон на критическом пути
- Бюджет на JS для коммерческих шаблонов
CLS
Резервы под медиа и рекламу, динамические вставки, font‑display и метрики сдвига по элементам.
- Слоты и aspect‑ratio для карточек и баннеров
- Шрифты без FOIT/FOUT‑сюрпризов
- Повторная проверка после контентных правок
TTFB и инфраструктура
Edge‑кэш, origin, Nginx/Apache, БД и тяжёлые агрегации до первого байта.
- Сравнение TTFB по шаблонам и регионам
- Кэширование HTML там, где уместно
- Сигналы медленного бэкенда vs сети
JS bundle
Размер чанков, неиспользуемый код, tree‑shaking, code splitting и ленивая загрузка не‑критичных частей.
- Самые дорогие модули по coverage
- Маршрутизация и общие чанки
- Регрессии после обновления зависимостей
Render‑blocking
CSS/JS, блокирующие первый кадр; критический CSS, async/defer, порядок в head.
- Инлайн vs отдельные файлы — по риску на CLS
- Совместимость с CSP где есть
- Повторный замер на throttling
Third‑party и тег‑менеджер
Аналитика, чаты, A/B: вес, порядок загрузки, consent и влияние на INP/LCP.
- Server‑side vs client для ключевых тегов
- Триггеры и лишние срабатывания на первом экране
- Согласование с маркетингом без потери данных
Инженерный аудит с полевых данных до тикетов
Я связываю отчёты CWV из Google Search Console с реальными страницами, профилирую в Chrome DevTools, нахожу корневые элементы LCP/INP/CLS и формирую таблицу правок с ICE‑приоритетами. Результат — не список рекомендаций, а готовая спецификация для разработки.
Field data как источник истины — Выгружаю и группирую URL по CWV‑отчёту GSC, сопоставляю с шаблонами и трафиком. Лабораторные данные — только для гипотез.
Профилирование до костей — Ищу LCP‑элемент и цепочку запросов, long tasks под INP, сдвиги вёрстки для CLS. Одна главная причина на группу, а не десяток второстепенных.
ICE-приоритизация — Каждая правка получает оценку Impact / Confidence / Ease. Команда видит, с чего начать для максимального эффекта.
Готовые тикеты и критерии приёмки — Формулирую задачи для frontend, backend, CDN с измеримыми целями по метрикам field data.
Как проходит аудит
Три шага от сырых данных до готовых задач для разработки.
Шаг 1
Данные
Выгружаем отчёты CWV из GSC, группируем URL по шаблонам и трафику. Дополнительно собираем лабораторные срезы через PageSpeed API и Lighthouse как гипотезы. Результат: Набор репрезентативных страниц с реальными и лабораторными метриками.
Шаг 2
Причины
Профилируем в Chrome DevTools: строим LCP‑цепочку, анализируем main thread и длинные задачи, разбираем сетевой водопад и сдвиги. Фиксируем одну главную причину на группу страниц. Результат: Диагностическая карта: что именно вызывает превышение по каждой метрике.
Шаг 3
Fixes
Формируем таблицу правок с ICE‑приоритетами. Каждая правка — с описанием, ожидаемым эффектом и критериями приёмки. Готовые формулировки тикетов. Результат: Ранжированный план оптимизации, который сразу можно передавать в разработку.
Примеры результатов
Post-Roy
Сайт по оказанию строительных услуг: промышленные полы и стяжка. Проект начался с нуля: без сайта, домена и цифровой репутации.
lengidroprom.ru
OpenCart-каталог насосного оборудования: переработка шаблонов, защита от ботов, Silo-структура, доверие и унификация 3000+ товарных карточек.
Лично
Эксперт, который ведёт проект
Не прячусь за отделом продаж: приоритеты, разборы и ответы по сути — от стратегии до отчётности.
SEO-стратег
Павел Борушко
Head of SEO @ Texode · Минск / гибрид
SEO-стратег с инженерным мышлением. Веду проекты от запуска с нуля до масштабирования высоконагруженных платформ: JS/SPA, поддомены, мультиязычность и мультирегиональность. Техаудит, стратегии индексации, семантика и структурированные данные — в зоне моей ответственности.
Частые вопросы
Готовы вернуть сайт в зелёную зону и перестать терять трафик?
Полевые CWV, профилирование и таблица правок с ICE — сразу в бэклог разработки.
Бесплатная первичная консультация