Медленный сайт редко тормозит из-за одной причины. Обычно это сумма: тяжёлые изображения, лишний JavaScript, медленные запросы к базе и отсутствие кеша. Ниже — как мы ищем узкие места и в каком порядке их убираем.
Проблема
Пользователь ждёт больше 2–3 секунд, пока страница станет полезной, — и уходит. Поисковые системы учитывают Core Web Vitals: LCP (когда отрисован главный элемент), INP (как быстро страница реагирует на действия) и CLS (насколько «прыгает» вёрстка). Плохие значения — это и потерянные заявки, и позиции в выдаче.
Почему это происходит
- Сервер долго отвечает. TTFB больше 600 мс — признак медленного PHP или Node.js, тяжёлых запросов к базе или отсутствия кеша страниц.
- Тяжёлые изображения. Фотографии по 2–5 МБ без адаптивных размеров и современных форматов.
- Лишний JavaScript. Слайдеры, виджеты, трекеры и плагины, которые грузятся на каждой странице, даже если там не нужны.
- Блокирующие шрифты и CSS. Браузер ждёт их загрузки, прежде чем показать текст.
- Нет CDN. Статика едет к пользователю через полмира.
Как мы ищем узкие места
- Lighthouse и PageSpeed Insights — для первичной картины. Смотрим не на общий балл, а на конкретные метрики и «водопад» загрузки.
- Chrome DevTools → Performance: где именно тратится время — сеть, разбор скриптов или отрисовка.
- Логи и профилирование сервера: медленные SQL-запросы, время генерации страницы, нагрузка на CPU.
- Данные реальных пользователей (CrUX, RUM): лабораторный тест на быстром ноутбуке не показывает мобильный 4G.
Что делаем в первую очередь
| Проблема | Решение | Что улучшается |
|---|---|---|
| Долгий TTFB | Кеш страниц, OPcache, Redis, оптимизация запросов | Время ответа сервера |
| Тяжёлые изображения | WebP или AVIF, srcset, lazy loading |
LCP и трафик |
| Лишний JS | Убираем неиспользуемые плагины, грузим скрипты по требованию | INP |
| Прыгающая вёрстка | Фиксированные размеры медиа и блоков | CLS |
| Далёкий сервер | CDN, например Cloudflare | Загрузка статики |
Технические детали
Для WordPress чаще всего помогает связка: аудит плагинов, объектный кеш, кеш страниц на уровне Nginx и перенос тяжёлых операций — импорта, отправки писем — в фоновые задачи. Для React и Next.js — серверный рендеринг или статическая генерация, разделение бандла и отказ от клиентских запросов там, где данные можно сразу отдать в HTML.
Долгий кеш для статики на уровне Nginx:
location ~* \.(webp|avif|jpg|png|svg|woff2)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}
Пример
Типичная ситуация — магазин на WooCommerce, где главная на мобильном открывается 6–7 секунд. Внутри — 40 активных плагинов, слайдер из пяти полноразмерных фото и отдельный запрос к базе на каждый товар в каталоге. Порядок работ: отключить плагины, без которых магазин работает, перевести изображения в WebP с адаптивными размерами, включить кеш страниц и объединить запросы каталога. В подобных проектах LCP обычно удаётся опустить до 2–2,5 секунды.
Вывод
Ускорение — это не «поставить плагин кеша», а поиск конкретных узких мест и их последовательное устранение. Начинайте с измерений, затем сервер, изображения и JavaScript — в таком порядке эффект обычно максимальный.