Как ускорить WordPress-сайт: что проверить в первую очередь

Если WordPress-сайт стал открываться медленно и просел в Core Web Vitals, не стоит сразу менять тему или переписывать весь фронтенд. В большинстве случаев проблема лежит в нескольких типовых местах: тяжёлые изображения, медленный хостинг, лишние плагины, отсутствие кэша или слишком «тяжёлая» главная страница. Эти вещи проверяются быстро и часто дают заметный прирост без сложной разработки.

Ниже — порядок, в котором я обычно ищу узкое место. Он помогает не распыляться и сначала убрать то, что тормозит сильнее всего.

Сначала поймите, что именно тормозит: сервер или фронтенд

Когда сайт «тормозит», это может означать разные вещи. Иногда долго отвечает сам сервер: страница начинает грузиться с задержкой, а в отчётах видно высокий TTFB. Иногда сервер отвечает нормально, но браузер долго рисует страницу из-за тяжёлых скриптов, шрифтов и изображений. Для ускорения WordPress это принципиально разные сценарии.

Самый простой способ понять направление поиска — открыть страницу в PageSpeed Insights или Lighthouse и посмотреть, что именно проседает:

• если высокий TTFB и страница долго начинает загружаться, сначала проверяйте хостинг, кэш и нагрузку от плагинов;
• если TTFB нормальный, а проблемы в LCP, INP или CLS, чаще всего дело в теме, медиафайлах, скриптах и верстке;
• если мобильная версия сильно хуже десктопной, обычно виноваты тяжёлые изображения, лишний JS и блокирующие ресурсы.

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

Проверьте хостинг и время ответа сервера

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

Что проверить в первую очередь:

• есть ли на хостинге актуальная версия PHP, подходящая для вашей версии WordPress и плагинов;
• включён ли объектный кэш, если хостинг его поддерживает;
• не упирается ли сайт в лимиты тарифа по CPU, памяти или количеству одновременных процессов;
• нет ли регулярных пиков нагрузки из-за ботов, фоновых задач или тяжёлых запросов.

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

Включите кэш страниц, если его ещё нет

Для большинства обычных сайтов на WordPress кэш страниц — самая быстрая и полезная мера. Он позволяет отдавать готовую HTML-страницу вместо того, чтобы каждый раз собирать её заново из PHP и запросов к базе данных. Это особенно важно для главной, категорий, статей и других публичных страниц.

Если кэша нет, сайт почти всегда будет медленнее, чем мог бы быть. Если кэш есть, проверьте, не отключён ли он после обновления плагина, смены темы или переноса сайта.

Что важно учесть:

• кэш страниц не должен ломать авторизацию и корзину, если на сайте есть личные кабинеты или динамические элементы;
• после включения кэша нужно сбросить старые кэшированные версии и проверить сайт в обычном окне браузера;
• если используется CDN или прокси-уровень вроде Cloudflare, убедитесь, что он не конфликтует с кэшем WordPress.

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

Уберите тяжёлые изображения и проверьте формат медиа

Очень часто сайт кажется «медленным» не из-за WordPress как такового, а из-за изображений, которые загружаются в исходном размере. Большая картинка на 3000–4000 пикселей на странице, где она показывается в 800 пикселей, — типичная причина плохого LCP и лишнего трафика на мобильных.

Что стоит проверить сразу:

• не загружаются ли на страницу изображения больше, чем они отображаются на экране;
• не используются ли PNG там, где достаточно JPEG или WebP;
• не вставлены ли в контент фото напрямую из камеры без сжатия;
• есть ли у изображений корректные размеры, чтобы браузер не пересчитывал layout.

Если на сайте много старых медиафайлов, имеет смысл прогнать библиотеку через сжатие и, при возможности, перевести изображения в WebP. Но не стоит слепо гнаться за «максимальным» сжатием: слишком агрессивная оптимизация быстро портит качество, а выигрыш по скорости уже не растёт.

Отдельно проверьте первую видимую картинку на странице. Именно она чаще всего влияет на LCP. Если это баннер или обложка статьи, она должна быть достаточно лёгкой и не тянуть за собой лишние скрипты или фоновые эффекты.

Посмотрите, что делают плагины на каждой загрузке

В WordPress плагины часто тормозят не сами по себе, а из-за того, что добавляют лишние запросы, стили, скрипты или тяжёлую логику в админке и на фронтенде. На небольшом сайте это может быть незаметно, но со временем набор расширений начинает ощутимо влиять на скорость.

Я бы проверял плагины в таком порядке:

1. Отключить всё, что не влияет на публичную часть сайта прямо сейчас.
2. Посмотреть, не стало ли быстрее открываться главная и несколько внутренних страниц.
3. Вернуть нужные плагины по одному и отследить, после какого из них скорость снова падает.

Особенно часто тормозят плагины, которые:

• добавляют много внешних скриптов;
• выполняют сложные запросы к базе;
• подгружают тяжёлые блоки на всех страницах, даже если они нужны только в одном месте;
• дублируют функции темы или других расширений.

Если боитесь временно отключать плагины на рабочем сайте, делайте это на копии или в staging-окружении. На боевом сайте отключение может сломать формы, слайдеры, SEO-метки или интеграции, поэтому без бэкапа лучше не экспериментировать.

Проверьте тему и лишние элементы на странице

Иногда сайт медленный не из-за WordPress, а из-за самой темы. Тяжёлые темы часто тащат за собой большие CSS-файлы, десятки JS-скриптов, анимации, встроенные слайдеры и блоки, которые нужны далеко не на каждой странице. На слабом хостинге это особенно заметно.

На что смотреть:

• есть ли на главной слишком много секций, слайдеров, видео и анимаций;
• не загружается ли один и тот же набор скриптов на всех страницах без необходимости;
• не перегружена ли шапка сайта, особенно если там несколько меню, виджетов и внешних виджетов;
• не используется ли тяжёлый конструктор для простых страниц, где хватило бы обычного редактора блоков.

Если тема старая и давно не обновлялась, это отдельный риск. У неё могут быть устаревшие подходы к загрузке ресурсов, лишние зависимости и плохая совместимость с современными версиями PHP и WordPress. В такой ситуации иногда быстрее и дешевле перейти на более лёгкую тему, чем бесконечно «допиливать» старую.

Сократите лишний JavaScript и отложите то, что не нужно сразу

Когда сервер уже отвечает нормально, а сайт всё равно тяжёлый на мобильных, проблема часто в JavaScript. Браузер должен скачать, распарсить и выполнить скрипты, и пока это происходит, страница может выглядеть «замороженной» или дергаться при загрузке.

Что обычно даёт эффект без глубокой переделки:

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

Здесь важно не перестараться. Если отложить критический скрипт, можно сломать меню, слайдер, форму или всплывающее окно. После каждой правки проверяйте не только скорость, но и поведение интерфейса на мобильном и десктопе.

Проверьте базу данных и автозагрузку

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

Особенно стоит проверить:

• количество ревизий записей, если редакторы часто правят статьи;
• транзиенты и временные данные, которые не очищались долгое время;
• размер таблицы wp_options и количество автозагружаемых записей;
• следы удалённых плагинов, которые оставили свои опции в базе.

Если вы не уверены, что именно чистите, не удаляйте данные вручную из phpMyAdmin без бэкапа. Ошибка здесь может сломать сайт сильнее, чем любая медленная загрузка. Безопаснее использовать проверенный инструмент или сначала сделать полную резервную копию.

Что проверить после оптимизации

После каждого заметного изменения не ограничивайтесь субъективным ощущением «стало быстрее». Проверяйте результат теми же инструментами, которыми измеряли проблему сначала. Иначе легко принять случайное улучшение за стабильный эффект.

Минимальный набор проверки такой:

• открыть главную и 2–3 типовые внутренние страницы в PageSpeed Insights или Lighthouse;
• сравнить TTFB, LCP и общее время загрузки до и после;
• проверить сайт в обычном окне и в приватном режиме;
• убедиться, что не сломались формы, меню, поиск, комментарии и другие интерактивные элементы.

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

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