Вы запускаете рекламу, платите за клики, а заявок — единицы. SEO-специалист говорит, что нужно «больше контента». Маркетолог предлагает «поменять оффер». А я вам скажу: прежде чем лить бюджет в трафик, проведите аудит скорости сайта. Потому что если страница грузится пять секунд, вы не имеете проблемы с трафиком — у вас проблема с воронкой. И половина потенциальных клиентов уходит ещё до того, как увидит ваш телефон.

Я провожу десятки таких аудитов ежемесячно. И в 90% случаев владелец бизнеса искренне удивлён: «Но сайт же открывается». Открывается — у него на iPhone 15 Pro в офисе на Wi-Fi. А у клиента на Android в метро на 4G — это катастрофа.

Что такое аудит скорости: не просто «проверить в PSI»

Аудит скорости — это не единичный замер в PageSpeed Insights и не гонка за зелёной оценкой. Это системный анализ того, как сайт работает в реальных условиях, где узкие места и какие доработки дадут максимальный эффект за минимальные ресурсы.

Правильный аудит скорости сайта состоит из четырёх этапов: сбор данных, анализ метрик, технический разбор и приоритизация доработок.

Этап 1. Сбор данных — смотрим на реальность, а не на догадки

Первое правило: не доверяйте одному инструменту и одному замеру. Я использую три источника данных:

Google PageSpeed Insights — показывает полевые данные CrUX (как сайт работал у реальных пользователей за 28 дней) и лабораторные данные Lighthouse. Ориентируемся на полевые: именно они влияют на ранжирование.

Google Search Console → Core Web Vitals — здесь Google прямо указывает, какие конкретные страницы вашего сайта не проходят пороги и по какой метрике. Это приоритетный список URL для доработки.

Яндекс.Метрика или аналитика сервера — показывают реальную скорость для вашей аудитории, включая время ответа сервера, скорость из разных регионов и поведение на мобильных.

Собираем данные по ключевым страницам: главная, услуги, карточка товара, корзина, форма заявки. Не проверяем «сайт в целом» — проверяем те точки, которые приносят деньги.

Этап 2. Анализ метрик — переводим цифры в бизнес-язык

В отчётах вы увидите аббревиатуры. Вот что они значат для вашего кармана:

LCP (Largest Contentful Paint) — время загрузки самого крупного видимого элемента. Если больше 2,5 секунд, клиент видит белый экран или «ломающуюся» страницу. Прямая потеря доверия.

INP (Interaction to Next Paint) — задержка между кликом и реакцией. Больше 200 мс означает, что кнопка «Заказать» подвисает. Клиент нажимает дважды, получает ошибку, уходит.

CLS (Cumulative Layout Shift) — сдвиг элементов при загрузке. Если кнопка «Купить» прыгает вниз, а пользователь попадает по рекламе, это не просто раздражение — это прямые потери конверсии.

TTFB (Time to First Byte) — время от запроса до первого байта ответа сервера. Если оно плавает от 0,8 до 2 секунд, проблема в хостинге или серверной части. Это не задача для верстальщика, это повод поговорить с хостером.

FCP и TBT — дополнительные индикаторы. FCP показывает, когда пользователь видит первый элемент (логотип, текст). TBT измеряет, сколько времени страница «зависает» из-за JavaScript.

Этап 3. Технический разбор — находим корень проблемы

Когда метрики собраны, нужно понять, что именно их портит. Я проверяю пять областей:

Сервер и хостинг. Устаревший PHP, отсутствие OPcache, медленные диски вместо NVMe, перегруженный shared-хостинг — всё это даёт высокий TTFB. Если сервер отвечает дольше секунды, оптимизация картинок не спасёт.

Изображения и медиа. 60–80% веса страницы — это картинки. Неоптимизированные JPEG в 2 МБ, отсутствие WebP/AVIF, неправильный lazy loading на LCP-элементе — классика, которую я вижу каждую неделю.

Код и скрипты. Лишний JavaScript, неиспользуемый CSS, конфликтующие плагины, сторонние виджеты (чаты, метрики, пиксели) — всё это увеличивает INP и TBT. Особенно болезненно для WordPress и конструкторов.

База данных. Раздутые таблицы, миллионы ревизий, неочищенные транзиенты, отсутствие индексов. Для WooCommerce это критично: каждая лишняя секунда запроса к БД умножается на количество товаров в каталоге.

Кэширование. Отсутствие page cache, object cache (Redis/Memcached), CDN или неправильная настройка исключений. Без кэша сервер генерирует одну и ту же страницу тысячи раз в день впустую.

Этап 4. Приоритизация — что делать первым

Самая распространённая ошибка после аудита — пытаться сделать всё сразу. Я приоритизирую доработки по принципу «максимальный эффект за минимальное время»:

1. Кэширование и сервер. Включаем page cache, проверяем PHP, настраиваем Redis. Это даёт мгновенный прирост TTFB и снижает нагрузку.
2. Изображения. Конвертируем в WebP/AVIF, сжимаем, настраиваем правильные размеры и lazy loading. Результат виден сразу по LCP.
3. Очистка скриптов. Убираем лишние плагины, откладываем не критичный JavaScript, оптимизируем CSS. Снижаем INP и TBT.
4. База данных. Чистим ревизии, оптимизируем таблицы, настраиваем индексы. Эффект накапливается, но требует аккуратности.
5. Долгосрочные доработки. Переход на лучший хостинг, рефакторинг кода, оптимизация архитектуры.

Практическая польза для бизнеса

Когда аудит скорости проведён правильно, вы получаете не просто отчёт с красными цифрами, а конкретный план:

• Приоритетный список доработок с оценкой времени и ресурсов. Вы знаете, что делать в первую очередь, а что можно отложить.
• Измеримый прогноз. Улучшение LCP с 4,5 до 1,8 секунд на ключевых страницах напрямую коррелирует с ростом конверсии на 7–10%.
• Экономия рекламного бюджета. Если половина платного трафика уходила из-за медленной загрузки, вы перестаёте сжигать деньги.
• Рост органического трафика. Google продвигает быстрые сайты выше. Сайты с зелёными Core Web Vitals получают в среднем на 23% больше органического трафика.

Типичные ошибки при аудите и оптимизации

Я постоянно вижу, как владельцы бизнеса и даже разработчики допускают одни и те же ошибки:

Ошибка 1. Аудит ради аудита. Собрали отчёт, положили в папку. Без плана действий и ответственных аудит бесполезен.

Ошибка 2. Гонка за оценкой 100 в PSI. Оценка Lighthouse — синтетический показатель. Важнее зелёные зоны трёх метрик Core Web Vitals. Сайт на 85 баллов с зелёным LCP/INP/CLS работает лучше, чем сайт на 95 с провалом по INP.

Ошибка 3. Игнорирование мобильной версии. Google использует mobile-first индексирование. Если десктоп летает, а мобильная версия тормозит — вы теряете основной трафик.

Ошибка 4. «Разработчик разберётся». Без чёткого технического задания, основанного на бизнес-метриках, разработчик оптимизирует то, что видит, а не то, что влияет на выручку.

Ошибка 5. Ожидание мгновенного эффекта от SEO. Данные Core Web Vitals обновляются по скользящему окну в 28 дней. После внедрения правок ждите 4–8 недель до пересчёта позиций.

Вывод

Аудит скорости — это не «проверка для гиков». Это инструмент принятия бизнес-решений. Он показывает, сколько денег вы теряете прямо сейчас, где именно утекает трафик и какие три доработки дадут максимальный результат в ближайший месяц.

Не ждите, пока конкуренты с зелёными метриками уйдут вперёд. Не добавляйте очередной плагин «для ускорения». Проведите системный аудит, получите чёткий план и начните с того, что реально двигает иглу — сервера, картинок и лишнего кода.

Хотите узнать, сколько денег теряет ваш сайт прямо сейчас?

Закажите комплексный аудит скорости. Мы проверим ваши ключевые страницы по всем метрикам Core Web Vitals, проанализируем сервер, код и медиа, и выдадим приоритетный план доработок с прогнозом роста скорости и конверсии. Без воды, только то, что влияет на заявки

Заказать в телеграм

ЧЕК-ЛИСТ: Аудит скорости сайта

• Зафиксировать 5–7 ключевых URL для проверки (главная, услуги, товар, корзина, форма заявки)
• Проверить каждый URL в PageSpeed Insights (мобильная версия), записать LCP, INP, CLS
• Открыть Google Search Console → Core Web Vitals, выгрузить список URL в красной и жёлтой зонах
• Проверить наличие полевых данных CrUX в PSI для каждого URL
• Замерить TTFB через WebPageTest или PSI: если > 0,8 сек — флаг серверной проблемы
• Проверить версию PHP на сервере: ниже 8.1 — требует обновления
• Убедиться, что включены OPcache и сжатие (Brotli/gzip) на сервере
• Проверить вес страницы в GTmetrix: если изображения > 60% — приоритет оптимизации медиа
• Проверить LCP-элемент: правильный ли формат, нет ли lazy loading, соответствует ли размер отображаемому
• Зафиксировать количество активных плагинов/скриптов: больше 15 — аудит на обязательность
• Проверить через Chrome DevTools → Network, какие сторонние скрипты блокируют отрисовку
• Проверить базу данных: размер wp_options, количество ревизий, наличие object cache (Redis)
• Убедиться, что настроено page cache с корректными исключениями (корзина, чекаут, админка)
• Проверить работу CDN: отдаёт ли оптимизированные версии статики
• Составить таблицу приоритетов: проблема | влияние на метрику | сложность fix | ответственный

ГАЙД: Проведение аудита скорости за 2 часа

Шаг 1. Подготовка (15 минут)
Составьте список из 5 приоритетных URL. Откройте Chrome в режиме инкогнито. Подготовьте таблицу: URL | LCP | INP | CLS | TTFB | Приоритет.

Шаг 2. Сбор полевых данных (30 минут)
Проверьте каждый URL в PageSpeed Insights. Запишите полевые данные CrUX. Если их нет — ориентируйтесь на лабораторные Lighthouse, но отметьте, что выборка недостаточна.

Шаг 3. Диагностика в Search Console (15 минут)
Перейдите в отчёт Core Web Vitals. Зафиксируйте, какие шаблоны страниц чаще всего в красной зоне. Это укажет на системную проблему (например, все карточки товаров тормозат из-за одного плагина).

Шаг 4. Технический замер (30 минут)
Откройте Chrome DevTools → вкладка Performance. Запишите LCP-элемент, проверьте наличие render-blocking resources, зафиксируйте TTFB в Network.

⚠️ Предупреждение: Не доверяйте одному замеру. Скорость плавает в зависимости от нагрузки на сервер. Делайте 3 замера в разное время.

Шаг 5. Анализ скриптов и плагинов (20 минут)
В DevTools → Network отфильтруйте по типу JS. Посмотрите, какие сторонние скрипты грузятся и сколько весят. В WordPress отключайте плагины по очереди, чтобы найти виновника роста INP.

Шаг 6. Проверка медиа (10 минут)
Откройте самую тяжёлую страницу. В DevTools → Network отфильтруйте по Img. Посчитайте общий вес картинок. Проверьте форматы: есть ли WebP/AVIF.

Шаг 7. Формирование приоритетов (10 минут)
Распределите найденные проблемы по матрице: высокое влияние / низкая сложность — делаем первым делом. Высокое влияние / высокая сложность — планируем на следующий квартал.

FAQ: Аудит и оптимизация скорости

Вопрос 1. Сколько стоит аудит скорости сайта?
Базовый аудит с анализом 5–7 страниц и отчётом по Core Web Vitals можно провести самостоятельно бесплатно через PSI и GSC. Комплексный технический аудит с разбором сервера, базы данных и кода стоит от 15 000 до 50 000 ₽ в зависимости от размера сайта.

Вопрос 2. Как часто нужно проводить аудит скорости?
После каждого крупного обновления (новый функционал, смена темы, добавление плагинов) и раз в квартал в рамках регулярного мониторинга. Данные CrUX обновляются каждые 28 дней.

Вопрос 3. Может ли быстрый сайт быть плохим для SEO?
Нет. Скорость — это фактор ранжирования, но не единственный. Однако медленный сайт создаёт потолок: при прочих равных Google выберет более быстрый ресурс. При этом контент и ссылки остаются доминирующими факторами.

Вопрос 4. Что важнее: сервер или оптимизация фронтенда?
Если TTFB выше 0,8 секунды — сначала сервер. Если TTFB нормальный, а LCP высокий — фронтенд (картинки, шрифты, CSS). Начинайте с диагностики, а не с догадок.

Вопрос 5. Поможет ли переход на VPS решить все проблемы со скоростью?
Нет. VPS даёт контроль над окружением и снижает TTFB, но не уберёт тяжёлые картинки, лишний JavaScript или нестабильную вёрстку. Это один из этапов, а не волшебная таблетка.

Вопрос 6. Сколько времени занимает оптимизация после аудита?
Базовые правки (кэширование, сжатие изображений, удаление лишних плагинов) — 1–3 дня. Серьёзные доработки (переезд на новый стек, рефакторинг темы, оптимизация базы) — 2–4 недели.

Вопрос 7. Когда ждать результатов после оптимизации?
Технический эффект (скорость загрузки) виден сразу. SEO-эффект (рост позиций) — через 4–8 недель, после того как Google пересчитает Core Web Vitals по новым полевым данным.