Как увеличить скорость загрузки сайта Wordress

WordPress сам по себе не медленный. Медленным его делает набор решений, которые накапливаются годами: тема с конструктором, три десятка плагинов, картинки прямо из фотоаппарата, дешёвый общий хостинг и таблица wp_options, разросшаяся до сотен тысяч строк. Каждое решение по отдельности выглядело разумным. Вместе они дают страницу, которая грузится пять секунд и теряет половину мобильных посетителей.

Ниже — практическая последовательность работ по ускорению WordPress-сайта в том порядке, в котором её имеет смысл выполнять. Порядок важен: бессмысленно вылизывать критический CSS на хостинге, который отдаёт первый байт за две секунды. Скорость всегда входит в технический аудит сайта, и почти всегда именно с неё начинается список правок.

Что измерять, прежде чем что-то менять

Оптимизация без замеров — это гадание. Нужны две вещи: синтетический тест (PageSpeed Insights, GTmetrix, Вебмастер) и полевые данные о реальных пользователях.

Метрика	Что показывает	Целевое значение
TTFB	Время до первого байта — скорость сервера и бэкенда	до 400 мс, хорошо — до 200 мс
LCP	Отрисовка крупнейшего элемента экрана	до 2,5 с
INP	Отзывчивость на действия пользователя	до 200 мс
CLS	Смещение вёрстки при загрузке	до 0,1
Вес страницы	Суммарный объём загружаемых файлов	до 1,5–2 МБ для контентной страницы
Число запросов	Сколько файлов тянет страница	ориентир — до 60–80

Замеряйте отдельно мобильную версию: там процессор слабее и канал хуже. И тестируйте не только главную — она обычно самая вылизанная. Берите карточку товара, страницу услуги, статью блога.

Хостинг и версия PHP

Это фундамент, и на нём чаще всего экономят. Признак проблемы — высокий TTFB при полностью включённом кэшировании и небольшой базе. Что проверить:

• Версия PHP. Переход с 7.4 на 8.1–8.3 даёт заметный прирост производительности бесплатно. Перед обновлением проверьте совместимость темы и плагинов — старые сборки могут отвалиться.
• Тип диска и ресурсы. Сайт на HDD-хостинге не спасти никакой оптимизацией. Нужен SSD/NVMe и адекватный лимит по памяти PHP (256 МБ и выше для магазина).
• Соседи по серверу. На дешёвом shared-тарифе вы делите ресурсы с сотнями сайтов. Если TTFB скачет от 200 мс до 2 с без видимой причины, дело обычно в этом.
• Географическое расположение. Сервер в Европе для российской аудитории добавляет задержку на каждом запросе.
• OPcache и веб-сервер. OPcache должен быть включён. Связка nginx впереди Apache или чистый nginx работает быстрее классического Apache с .htaccess.

Кэширование: три уровня

Уровень	Что кэширует	Чем реализуется
OPcache	Скомпилированный PHP-байткод	Настройка PHP на сервере
Объектный кэш	Результаты запросов к базе внутри страницы	Redis или Memcached плюс дроп-ин
Полностраничный кэш	Готовый HTML целиком	Плагин кэширования или кэш на уровне сервера
Браузерный кэш	Статику на стороне посетителя	Заголовки Cache-Control и Expires
CDN	Раздачу статики с ближайшего узла	Внешний сервис

Полностраничный кэш даёт самый большой эффект: посетитель получает готовый HTML без обращения к PHP и базе. Но здесь же кроется главная ловушка, на которую я не раз наступал на клиентских проектах: полностраничный кэш ломает динамику. Корзина, личный кабинет, формы с токенами, счётчики — всё это может закешироваться в чужом состоянии. Правило простое: страницы корзины, оформления заказа и личного кабинета исключаются из кэша всегда, а формы, работающие через AJAX, проверяются вручную после включения кэша.

Объектный кэш через Redis имеет смысл при большом числе плагинов и тяжёлой админке — он ускоряет и работу редакторов. На сайте-визитке разница незаметна.

Изображения — обычно половина веса страницы

Порядок работ с картинками:

Первое — размеры. Загруженное фото 4000×3000 пикселей, показанное в блоке шириной 600 пикселей, — самая распространённая ошибка. WordPress генерирует размерные версии, но тема не всегда их использует. Проверьте, что в вёрстке есть атрибуты srcset и sizes.

Второе — формат. WebP весит на 25–40% меньше JPEG при сопоставимом качестве и поддерживается всеми актуальными браузерами. AVIF ещё легче, но с ним больше нюансов. Конвертацию делают плагины оптимизации или модуль на стороне сервера.

Третье — сжатие. Качество 75–85 для фотографий визуально неотличимо от исходника, а весит вдвое меньше. Для скриншотов и графики с текстом лучше PNG с уменьшением палитры.

Четвёртое — отложенная загрузка. В WordPress она встроена, но важно исключить из неё изображение первого экрана: если LCP-картинка загружается лениво, метрика ухудшается. Первому изображению задают fetchpriority="high" и снимают ленивую загрузку.

Пятое — явные размеры. Атрибуты ширины и высоты у каждой картинки убирают смещение вёрстки и улучшают CLS.

Плагины: как найти тормозящие

Тридцать плагинов не обязательно медленнее пяти — вопрос в том, что они делают. Но каждый плагин добавляет свои CSS и JS на все страницы, даже там, где не используется.

Как искать виновных. Установите инструмент профилирования (Query Monitor или аналог) и посмотрите, какие плагины дают больше всего запросов к базе и времени выполнения. Отдельно проверьте автозагружаемые опции: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes' — если результат превышает пару мегабайт, каждый запрос к сайту тянет этот объём из базы.

Типичные тяжеловесы: конструкторы страниц, слайдеры, счётчики посещений, плагины «похожих записей» с расчётом на лету, системы отзывов, галереи, чаты и виджеты обратного звонка, подгружающие внешние скрипты. Отдельная категория — плагины, которые вы поставили один раз для разовой задачи и забыли выключить.

Полезный приём: подключать скрипты плагинов только на тех страницах, где они нужны. Форма обратной связи не должна тащить свой JavaScript на каждую статью блога. Многие плагины оптимизации умеют это делать через правила отключения по URL.

Тема, конструкторы и фронтенд

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

Что делать с фронтендом:

• Объединять и минифицировать CSS и JS — с осторожностью: агрессивное объединение ломает вёрстку, проверяйте страницы после каждого изменения настройки.
• Выделять критический CSS для первого экрана и откладывать остальной.
• Переводить некритичные скрипты на defer, аналитику и чаты подгружать после взаимодействия пользователя.
• Убирать неиспользуемые шрифты и начертания. Три семейства по четыре начертания — это лишние сотни килобайт; часто хватает двух начертаний.
• Хранить шрифты локально с font-display: swap, а не подключать со сторонних серверов.
• Отключать эмодзи-скрипт и встраивания (embeds), если они не нужны.

База данных

На сайте, которому несколько лет, база обрастает мусором. Что чистить и как часто:

Что	Откуда берётся	Как чистить
Ревизии записей	Автосохранения редактора	Ограничить константой в wp-config, старые удалить
Транзиенты с истёкшим сроком	Плагины и тема	Плагин очистки или SQL-запрос
Спам и корзина комментариев	Боты	Регулярная очистка, автоудаление спама
Осиротевшие метаданные	Удалённые плагины и записи	Инструменты оптимизации базы
Раздутая автозагрузка wp_options	Плагины, пишущие большие значения	Найти запросом и отключить autoload у ненужных
Таблицы с фрагментацией	Долгая эксплуатация	OPTIMIZE TABLE для InnoDB — по необходимости

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

Чего делать не стоит

• Ставить два плагина кэширования одновременно. Они конфликтуют, результат непредсказуем, а отладка занимает больше времени, чем всё остальное ускорение.
• Гнаться за сотней баллов в PageSpeed. Это оценка синтетического теста, а не опыта пользователя. Разница между 82 и 95 баллами обычно не даёт ни конверсии, ни позиций, а достигается ценой хрупких настроек.
• Включать агрессивную оптимизацию и не проверять сайт. После каждого изменения открывайте ключевые страницы, отправляйте тестовую заявку, проходите оформление заказа.
• Оптимизировать фронтенд при плохом сервере. Если TTFB держится на уровне 1,5 секунды, начинать надо с хостинга.
• Удалять плагины пачкой, не проверяя зависимости. Часть функциональности сайта может быть завязана на то, что кажется лишним.
• Забывать про админку. Медленная админка — сигнал проблем с базой и автозагрузкой, который скоро проявится и на фронте.

Частые вопросы

Влияет ли скорость на позиции? Влияет, но не так прямолинейно, как принято думать. Скорость — один из факторов, и он редко перевешивает релевантность и качество контента. Зато она напрямую влияет на поведение: медленные страницы дают больше отказов, а это уже сказывается на ранжировании косвенно и на выручке напрямую.

Нужен ли CDN российскому сайту? Если аудитория в одном регионе, а сервер рядом, выигрыш небольшой. CDN оправдан при географически распределённой аудитории, большом объёме статики и медиа.

Что быстрее — WooCommerce или отдельный движок? На каталоге до нескольких тысяч товаров грамотно настроенный WooCommerce с объектным кэшем работает нормально. Проблемы начинаются на десятках тысяч позиций и сложной фильтрации — там уже нужны специализированные решения или серьёзная доработка сайта.

Помогает ли отключение REST API и XML-RPC? На скорость страниц почти не влияет, но снижает нагрузку от ботов и попыток перебора паролей. Отключать REST API целиком опасно: на нём работает редактор блоков и часть плагинов.

Как понять, что дальше оптимизировать нечего? Когда TTFB стабильно ниже 300 мс, LCP укладывается в 2,5 секунды на мобильных, а вес страницы не превышает пары мегабайт — дальнейшая борьба за десятые доли секунды обычно не окупается. Силы лучше вложить в контент и структуру.

Чеклист

• Сделаны замеры до начала работ: TTFB, LCP, INP, CLS, вес страницы — отдельно для мобильных.
• PHP обновлён до актуальной поддерживаемой версии, OPcache включён.
• Хостинг на SSD/NVMe, лимиты памяти достаточны, сервер расположен близко к аудитории.
• Настроен полностраничный кэш; корзина, оформление заказа и личный кабинет из него исключены.
• Проверены все формы и динамические элементы после включения кэша.
• Изображения приведены к нужным размерам, сконвертированы в WebP, сжаты.
• Изображение первого экрана исключено из ленивой загрузки, у всех картинок заданы размеры.
• Список плагинов пересмотрен, неиспользуемые удалены, тяжёлые ограничены по страницам.
• Шрифты локальные, лишние начертания убраны.
• Некритичные скрипты отложены, аналитика и чаты подгружаются позже.
• База очищена от ревизий, спама, истёкших транзиентов; автозагрузка wp_options проверена.
• Есть свежая резервная копия, повторные замеры зафиксированы после каждого этапа.

Ускорение WordPress — не разовая процедура, а часть регулярного обслуживания: с каждым новым плагином и партией изображений сайт снова набирает вес. Разумно раз в квартал проходить по этому чеклисту заново, а при серьёзной переработке функциональности закладывать замеры скорости в приёмку работ наравне с проверкой вёрстки.

Если нужно SEO-продвижение сайтов — помогу вывести сайт в топ Яндекса и удержать позиции.