Большинство медленных сайтов на WordPress тормозят по одним и тем же причинам, и лечатся они не плагином-ускорителем, а наведением порядка в шести местах. Ниже тот порядок, в котором я иду сам, когда мне присылают сайт со словами «он какой-то вялый».
Сразу договоримся: цель не «100 баллов в PageSpeed», а сайт, который быстро открывается у живого человека на телефоне. Баллы бывают красивыми у пустой страницы и плохими у очень полезной, поэтому смотрим на причины, а не на цифру.
Шаг 0: Сначала замерьте, потом чините
Откройте PageSpeed Insights и проверьте не одну главную, а три адреса: главную, самую тяжёлую внутреннюю страницу и страницу, с которой приходит больше всего заявок. Смотрите на мобильный результат: поисковики оценивают именно его. Запишите три показателя: LCP (когда появился главный блок), CLS (прыгает ли вёрстка) и INP (насколько быстро сайт реагирует на нажатие).
Отдельно замерьте время ответа сервера. В инструментах разработчика браузера это TTFB первого запроса. Если оно на странице без кэша стабильно больше секунды, дальше можно не оптимизировать картинки: проблема глубже.
1 · Хостинг и версия PHP
Самый недооценённый пункт. Дешёвый тариф, где на одном сервере живут сотни сайтов, даёт медленный ответ при любой оптимизации. Что проверить в панели хостинга:
- версию PHP: используйте актуальную поддерживаемую, старые версии заметно медленнее;
- включён ли OPcache: без него PHP каждый раз заново разбирает файлы;
- лимит памяти PHP: 256 МБ достаточно для большинства сайтов, магазину может понадобиться больше;
- не упираетесь ли вы в лимиты процессора: в панели обычно видно графики нагрузки.
Если все лимиты в порядке, а TTFB всё равно большой, смотрите в сторону базы данных и плагинов, о них ниже.
2 · Кэш страниц
WordPress собирает страницу из базы при каждом запросе. Страничный кэш превращает её в готовый файл, и сервер отдаёт его без лишней работы. Включите кэш одним способом: на уровне сервера (если хостинг даёт) или одним плагином. Два кэша одновременно почти всегда конфликтуют.
Что важно исключить из кэша: корзину, оформление заказа, личный кабинет и страницы с персональными данными. Иначе покупатель увидит чужую корзину, а это уже не вопрос скорости. После правок на сайте кэш нужно сбрасывать, настройте автоматический сброс при обновлении записей.
3 · Картинки: главный виновник
В большинстве случаев вес страницы – это картинки. Типичная история: на главную загрузили фото с камеры на 4 МБ, а показывают его в блоке шириной 600 пикселей. Что делаю я:
- Загружаю картинки в нужном размере, а не больше. Для блока в 600 пикселей хватит 1200 для экранов с высокой плотностью.
- Перевожу в WebP или AVIF: файл становится в разы легче при том же виде.
- Включаю ленивую загрузку для всего, что ниже первого экрана.
- Главное изображение первого экрана, наоборот, не откладываю: даю ему высокий приоритет загрузки. Если его отложить, LCP станет хуже.
- Всегда указываю ширину и высоту, чтобы вёрстка не прыгала, пока картинка грузится.
4 · Плагины: одна функция – один плагин
Дело не в количестве плагинов, а в том, что именно они делают. Один плагин формы с аккуратным кодом легче, чем «универсальный комбайн», которым вы пользуетесь на десять процентов. Как провести ревизию без риска: сделайте копию сайта, отключайте плагины по одному и смотрите, как меняется время загрузки. Поставьте на копию Query Monitor: он покажет, какие плагины делают самые медленные запросы.
Заодно проверьте, на каких страницах работает каждый плагин. Форма нужна на странице с формой, а не на всём сайте, и хороший плагин это умеет, плохой грузит свои файлы везде.
5 · Шрифты и чужие скрипты
Каждый внешний ресурс – это дополнительное соединение и риск задержки. Шрифты храните у себя, оставьте только нужные начертания и задайте для них font-display: swap, чтобы текст появлялся сразу. Чаты, виджеты записи и пиксели подключайте после загрузки страницы или после первого действия посетителя. Яндекс Метрику и аналитику это не ломает, а страница открывается быстрее.
6 · База данных и фоновые задачи
Со временем в базе копятся ревизии записей, временные данные и настройки от давно удалённых плагинов. Ограничьте число ревизий (например, до 5 константой WP_POST_REVISIONS в wp-config.php), удалите мусор и посмотрите, нет ли гигантских автозагружаемых опций: они читаются на каждой странице.
Ещё одна мелочь, которая заметна на загруженных сайтах: WP-Cron запускается при заходе посетителей и может внезапно занять сервер. Его можно отключить и вместо него запускать расписание обычным системным cron раз в несколько минут.
Что даёт больше эффекта, что меньше
| Действие | Эффект | Сложность |
|---|---|---|
| Нормальный хостинг и актуальный PHP | очень большой | низкая |
| Страничный кэш | большой | низкая |
| Оптимизация картинок | большой | средняя |
| Чистка плагинов | средний или большой | средняя |
| Шрифты и сторонние скрипты | средний | средняя |
| Чистка базы | небольшой, но заметный на старых сайтах | низкая |
Как не сломать сайт, пока ускоряете
Работайте на копии, меняйте по одному параметру и после каждого шага проверяйте формы, корзину, меню и мобильную версию. Самые рискованные приёмы – объединение файлов и перенос скриптов в конец страницы. Если после них что-то перестало работать, не отключайте всё подряд, а исключите конкретный скрипт из оптимизации.
Когда проще отдать задачу
Если сайт приносит деньги, а времени разбираться нет, я делаю аудит скорости с планом за день и ускорение за 3–5 дней с отчётом «до и после». Если интересно сначала понять масштаб, начните с разбора причин медленной работы.
Вопросы, которые мне задают чаще всего
Хватит ли поставить плагин-ускоритель?
Он поможет с кэшем и сжатием, но не вылечит слабый хостинг и тяжёлые картинки. Это инструмент, а не лекарство.
Какой балл PageSpeed считать хорошим?
Ориентируйтесь на зелёные показатели Core Web Vitals для реальных пользователей и на ощущение скорости на телефоне. Число само по себе мало что говорит.
Можно ли ускорить магазин на WooCommerce?
Да, но там больше нюансов: кэш исключает корзину и кабинет, а база растёт быстрее. Магазины я ускоряю отдельно и осторожнее.
