Медленный сайт теряет посетителей и хуже ранжируется в поиске. Разбираю причины, по которым WordPress «тяжелеет», и шаги, которые дают реальный прирост скорости — без переписывания всего проекта.
WordPress сам по себе не медленный. Тормозит обычно не движок, а то, что на него навесили: десятки плагинов, нежатые изображения, тяжёлая тема и хостинг по цене чашки кофе. Хорошая новость — большинство проблем решается точечно.
Сначала измерьте, потом чините
Прежде чем что-то оптимизировать, нужно понять, что именно тормозит. Прогоните сайт через PageSpeed Insights и посмотрите на Core Web Vitals — это метрики, по которым скорость оценивает и Google, и реальные пользователи.
- LCP — за сколько отрисовывается основной контент. Цель — менее 2,5 секунды.
- CLS — насколько «прыгает» вёрстка при загрузке.
- INP — как быстро страница реагирует на действия.
Главные причины медленной загрузки
В 9 из 10 проектов, которые ко мне приходят на ускорение, виноват один или несколько пунктов:
- Тяжёлые изображения — фото на 3–5 МБ, загруженные «как есть» из телефона.
- Избыток плагинов — каждый тянет свои скрипты и стили на каждую страницу.
- Нет кеширования — сервер заново собирает страницу при каждом заходе.
- Дешёвый или перегруженный хостинг с медленным ответом сервера.
- Универсальная «тема на всё» с конструктором, который грузит лишний код.
Чаще всего сайт ускоряется не покупкой дорогого хостинга, а наведением порядка: сжать картинки, включить кеш, убрать три лишних плагина.
Что даёт реальный прирост
1. Изображения
Сжатие и современный формат (WebP) плюс отложенная загрузка (lazy-load) часто срезают вес страницы вдвое. Это первое, с чего стоит начать.
2. Кеширование
Страничный кеш отдаёт готовый HTML мгновенно. В связке с кешем браузера повторные заходы становятся почти моментальными.
3. Чистка лишнего
Аудит плагинов и удаление неиспользуемого кода убирает десятки запросов. Меньше скриптов — быстрее интерактивность.
Когда стоит позвать на помощь
Если базовые шаги сделаны, а сайт всё равно медленный, проблема глубже — в теме, структуре базы данных или хостинге. Здесь нужен прицельный аудит: я нахожу узкое место и убираю именно его, а не «оптимизирую всё подряд».