Сайт на WordPress, который грузится 5–6 секунд, — это как магазин с заклинившей дверью: клиенты разворачиваются, не дождавшись, пока она откроется. По данным Google, больше половины мобильных пользователей уходят со страницы, если она грузится дольше трёх секунд. И это не абстрактная «скорость ради скорости»: медленный сайт напрямую режет заявки, что мы подробно разбирали в статье «Сайт не приносит заявок: 10 причин и план исправления за 30 дней».
Хорошая новость: WordPress ускоряется без переписывания сайта с нуля. В 80% случаев всё решают пять мер — замер, кэширование, сжатие изображений, ленивая загрузка и чистка плагинов. Ниже — практический гайд: что делать, в каком порядке и каких цифр реально ждать. Все шаги выполнимы своими руками за несколько вечеров; если копаться некогда — в конце расскажем, как это делаем мы.
Почему скорость — это деньги, а не «техническая мелочь»
Три причины относиться к скорости как к бизнес-метрике, а не как к прихоти разработчиков.
1. Потерянные клиенты. Каждая лишняя секунда загрузки снижает конверсию: посетитель, который ждёт, — это посетитель, который уже открыл вкладку конкурента. Особенно заметно это на мобильных: там и интернет медленнее, и терпения меньше. Если у вас больше половины трафика — со смартфонов (а это сейчас почти у всех), скорость мобильной версии — вопрос выживания, а не красоты.
2. Позиции в поиске. Google с 2021 года официально учитывает Core Web Vitals — метрики скорости и стабильности загрузки — как фактор ранжирования. Яндекс прямо про скорость не заявляет, но активно учитывает поведенческие факторы: высокий процент отказов и короткое время на сайте из-за медленной загрузки бьют по позициям в обеих поисковых системах.
3. Деньги на рекламу. Если вы ведёте трафик из Директа или Google Ads на медленный сайт, часть рекламного бюджета сгорает впустую: клик оплачен, а человек ушёл до загрузки страницы. Ускорение посадочной страницы — самый дешёвый способ поднять отдачу от рекламы без увеличения бюджета.
Вывод: ускорение сайта окупается трижды — ростом конверсии, позициями и экономией на рекламе. Поэтому начинаем не с «поставить плагин», а с замера: нельзя улучшить то, что не измерено.
Шаг 0: замеряем скорость и понимаем, что чинить
Главный инструмент — Google PageSpeed Insights (pagespeed.web.dev): бесплатный, показывает и мобильную, и десктопную версии. Вводите URL главной страницы и пары внутренних — получаете оценку от 0 до 100 и три ключевые метрики:
- LCP (Largest Contentful Paint) — время отрисовки самого крупного элемента страницы (обычно hero-изображение или заголовок). Норма — до 2,5 секунд. Именно LCP чаще всего «красный» у медленных сайтов.
- INP (Interaction to Next Paint) — отзывчивость: как быстро страница реагирует на клик или нажатие. Норма — до 200 миллисекунд. Страдает, когда страницу перегружают тяжёлыми скриптами.
- CLS (Cumulative Layout Shift) — стабильность вёрстки: не «прыгает» ли контент при загрузке. Норма — меньше 0,1. Прыгающие кнопки и съезжающий текст раздражают и роняют конверсию.
Важный нюанс: PageSpeed показывает два типа данных — лабораторные (замер прямо сейчас) и полевые (реальные визиты пользователей за 28 дней, блок «Discover what your real users are experiencing»). Ориентируйтесь на полевые: они показывают, как сайт грузится у живых людей, а не у тестового робота. Если полевых данных нет — сайт малопосещаемый, смотрите лабораторные.
Дополнительные инструменты: GTmetrix — удобный разбор «что тормозит» с waterfall-диаграммой загрузки каждого файла; WebPageTest — замер из разных стран (полезно, если клиенты в Беларуси, а сервер в США — об этом ниже). Скорость — лишь один из пунктов технической проверки сайта; полный список — в нашем чек-листе технического SEO-аудита из 25 пунктов.
Зафиксируйте цифры «до»: LCP, INP, CLS и общий вес страницы в мегабайтах (его показывает GTmetrix). Без точки «до» вы не поймёте, что сработало, а отчёт «стало лучше» останется ощущением, а не фактом.
Кэширование: самый быстрый выигрыш
Без кэширования WordPress при каждом визите заново собирает страницу: опрашивает базу данных, выполняет PHP-код, склеивает шаблон. Это сотни запросов к базе ради одной страницы. Кэширование сохраняет готовую HTML-версию страницы и отдаёт её мгновенно — сервер почти не работает.
Что настраиваем, по порядку важности:
1. Кэш страниц (page cache). Главный рычаг. Плагины: WP Rocket (платный, ~59$/год, настраивается за 15 минут и работает «из коробки»), LiteSpeed Cache (бесплатный, но раскрывается полностью только на хостинге с веб-сервером LiteSpeed — уточните у хостера), W3 Total Cache (бесплатный, мощный, но сложный в настройке — легко навредить). Правило: один плагин кэширования на сайт. Два кэширующих плагина одновременно — классический способ «сломать» сайт.
2. Кэш браузера. Настройка на стороне сервера: браузер посетителя запоминает стили, скрипты и картинки и не качает их заново при повторном визите. Обычно включается тем же плагином кэширования или правилами в .htaccess / настройками хостинга.
3. Объектный кэш (Redis или Memcached). Ускоряет работу с базой данных — заметно на сайтах с большим каталогом, личным кабинетом или там, где page cache применять нельзя (корзина, кабинет). Требует поддержки на хостинге; на дешёвом shared-хостинге часто недоступен — ещё один аргумент за нормальный хостинг.
4. CDN (сеть доставки контента). Копии ваших картинок, стилей и скриптов раздаются с серверов по всему миру — посетитель качает их с ближайшего. Для белорусской аудитории CDN с точкой присутствия в Европе даёт заметный выигрыш, если основной сервер далеко. Популярный бесплатный вариант — Cloudflare (заодно даёт защиту от ботов и базовый firewall).
После включения кэширования обязательно проверьте сайт в режиме инкогнито: формы обратной связи, корзина, личный кабинет — всё, что должно быть динамическим, не должно отдаваться из кэша. Если форма «замерла» или показывает чужие данные — исключите эти страницы из кэширования в настройках плагина.
Инструменты ускорения: что ставить и когда
| Плагин / инструмент | Что делает | Когда нужен |
|---|---|---|
| WP Rocket | Кэш страниц, сжатие и отложенная загрузка скриптов, оптимизация базы | Когда нужен результат быстро и без погружения в настройки; платный |
| LiteSpeed Cache | Кэш страниц на уровне сервера, сжатие изображений, оптимизация | Если хостинг работает на LiteSpeed — тогда это лучший бесплатный вариант |
| ShortPixel / Imagify | Сжатие изображений и конвертация в WebP/AVIF | Когда в медиабиблиотеке сотни тяжёлых JPG/PNG — сжимает всё разом |
| Autoptimize | Объединяет и минифицирует CSS/JS, откладывает загрузку скриптов | Как дополнение к простому кэшу (например, WP Super Cache), если нет WP Rocket |
| Query Monitor | Показывает, какие плагины и запросы тормозят каждую страницу | На этапе диагностики — ставится временно, после аудита удаляется |
| Cloudflare (CDN) | Раздача статики с ближайших серверов, защита от ботов | Когда аудитория географически распределена или сервер далеко от клиентов |
Изображения: обычно половина веса страницы — здесь
Откройте GTmetrix и посмотрите waterfall: в типичном случае 50–70% веса страницы — это картинки. Причём чаще всего — картинки, загруженные «как есть» с фотостока или телефона: 4000 пикселей в ширину и 3–5 МБ весом ради отображения в блоке 800 пикселей. Лечится за один вечер.
1. Сожмите всё, что уже загружено. Плагины ShortPixel, Imagify или EWWW Image Optimizer прогоняют всю медиабиблиотеку и ужимают изображения без видимой потери качества на 60–80%. Настройте автоматическое сжатие для новых загрузок — иначе через полгода всё вернётся.
2. Перейдите на WebP (а лучше — AVIF). Современные форматы дают тот же визуальный результат при весе на 25–35% меньше, чем JPEG. Те же плагины сжатия умеют конвертировать автоматически и отдавать WebP тем браузерам, которые его понимают. Проверьте результат: откройте картинку в новой вкладке — в адресе должен быть .webp.
3. Не грузите лишние пиксели. Изображение 1920 px для слайдера во всю ширину экрана — нормально; то же изображение в карточке новости 400 px — расточительство. WordPress сам создаёт миниатюры (thumbnail, medium, large), а атрибут srcset подставляет нужный размер под экран посетителя — убедитесь, что тема это использует, а не тянет везде оригинал.
4. Включите ленивую загрузку (lazy load). Картинки ниже первого экрана не должны грузиться, пока пользователь до них не доскроллил. В WordPress ленивая загрузка встроена с версии 5.5 — проверьте, что она не отключена темой или плагином. Отдельные lazy-load плагины нужны редко; если ставите — один, а не три.
5. Уберите тяжёлые фоны. Видео-фон на главной — это плюс 5–15 МБ к загрузке ради красоты, которую половина посетителей не досмотрит. Если видео критично для дизайна — сожмите его, уберите автовоспроизведение со звуком и подгружайте по клику (превью + кнопка play). Слайдеры из пяти полноэкранных фото работают так же: оставьте два-три, остальные — в ленивую загрузку.
Чистка плагинов: главный виновник тормозов
Типичная картина: на сайте 35–45 плагинов, из них реально нужны 12–15. Остальное — «поставили попробовать», «осталось от прошлой темы», «для одной галочки». Каждый плагин — это PHP-код, который выполняется при загрузке, запросы к базе и часто свои CSS/JS-файлы. Плагины — причина №1 медленного WordPress, поэтому этот раздел — самый важный в гайде.
Как провести ревизию за час:
- Удалите деактивированные. Выключенный, но не удалённый плагин — это мёртвый груз и потенциальная дыра в безопасности. Деактивирован больше месяца — удаляйте без жалости.
- Найдите дубли. Два плагина для форм, три для SEO-метатегов, два слайдера — классика. Оставьте один лучший в каждой категории, остальное — в корзину.
- Поставьте Query Monitor (временно) и откройте ключевые страницы: он покажет, какие плагины делают больше всего запросов к базе и дольше всего выполняются. Главные подозреваемые — плагины статистики, «комбайны» (Jetpack со всеми модулями сразу), конструкторы с кучей виджетов.
- Проверьте автозагрузку (autoload). Плагины любят складывать свои настройки в таблицу wp_options с флагом autoload=yes — и тогда WordPress тащит всё это в память при каждой загрузке. Плагин вроде WP-Optimize покажет объём autoload-данных; сотни килобайт «мусора» там — обычное дело на старых сайтах. Чистится аккуратно, с бэкапом.
- Оцените конструктор страниц. WPBakery, Elementor и аналоги удобны, но генерируют много лишнего кода и скриптов. Если сайт уже построен на конструкторе — не надо его сносить (это перестройка сайта), но отключите неиспользуемые виджеты и элементы: у Elementor и WPBakery есть настройки, убирающие лишнее. При выборе конструктора для нового сайта смотрите в сторону более лёгких решений.
Правило на будущее: один плагин — одна задача. Нужна форма — один плагин форм, а не «комбайн всё-в-одном» ради одной формы. И перед установкой любого нового плагина смотрите дату последнего обновления и число установок: заброшенный два года назад плагин — это и тормоза, и риск взлома. Подробнее про регулярную гигиену сайта — в нашем чек-листе технического аудита, там есть блок про плагины и базу данных.
Хостинг: Беларусь vs зарубеж и shared vs VPS
Можно идеально настроить кэш и сжать все картинки, но если сервер отвечает 1,5 секунды — сайт быстрым не будет. Метрика, за которую отвечает хостинг, — TTFB (time to first byte): время от запроса до первого байта ответа. Норма — до 600 мс, хорошо — 200–300 мс. Смотрите её в WebPageTest или в том же GTmetrix.
Локация сервера. Физике не прикажешь: запрос из Минска до сервера в Минске идёт ~10–30 мс, до Германии — ~40–60 мс, до США — 150–200+ мс. Если ваши клиенты в Беларуси, сервер в Беларуси или ближней Европе — разумный выбор; сервер в США добавляет ощутимую задержку к каждой загрузке. CDN частично сглаживает разницу, но TTFB главной страницы CDN не ускоряет — её отдаёт origin-сервер.
Shared vs VPS. Дешёвый виртуальный хостинг (shared) — это сотни сайтов на одном сервере: в час пик «соседи» съедают ресурсы, и ваш TTFB плавает. Для сайта-визитки и небольшого корпоративного сайта качественного shared обычно хватает. Для интернет-магазина, каталога на тысячи товаров или сайта с высокой посещаемостью — VPS: гарантированные ресурсы, возможность поставить Redis, свежая версия PHP. Кстати о PHP: переключение с 7.4 на 8.x даёт прирост скорости выполнения кода в полтора-два раза — проверьте в панели хостинга, какая версия стоит у вас (предварительно убедитесь, что тема и плагины совместимы).
Когда менять хостинг: TTFB стабильно выше 800 мс после всех оптимизаций; хостер не даёт выбрать версию PHP 8.x; нет поддержки Redis/Memcached, хотя сайту нужен объектный кэш; поддержка отвечает сутками. Переезд на нормальный хостинг — работа на пару часов (бэкап → перенос → проверка), и мы регулярно делаем это в рамках технической поддержки сайтов: переносим, настраиваем кэширование и PHP под новый сервер.
До и после: каких цифр реально ждать
Без выдуманных кейсов — ориентиры из практики. Типичный сайт-визитка или корпоративный сайт на WordPress с конструктором страниц, 30+ плагинами и несжатыми изображениями обычно приезжает с такими цифрами: LCP 4–6 секунд, вес главной 4–8 МБ, оценка PageSpeed для мобильных 30–50. Что даёт каждая мера:
| Проблема | Инструмент / решение | Типичный эффект |
|---|---|---|
| Нет кэширования: сервер собирает страницу при каждом визите | WP Rocket или LiteSpeed Cache | TTFB для повторных визитов падает с 600–900 мс до 100–200 мс; LCP минус 1–2 секунды |
| Тяжёлые изображения: 60–70% веса страницы | Сжатие всей медиабиблиотеки + WebP | Вес страницы минус 50–70%; LCP минус 0,5–1,5 секунды |
| Всё грузится сразу, включая картинки «подвала» | Ленивая загрузка (lazy load) | Минус 20–40% начального веса страницы; особенно заметно на длинных страницах |
| 30–45 плагинов, половина не используется | Ревизия: удаление дублей и мусора, чистка autoload | Минус 0,5–2 секунды и десятки запросов к базе; бонус — меньше рисков безопасности |
| Медленный shared-хостинг, сервер в США, PHP 7.4 | Переезд ближе к аудитории + PHP 8.x | TTFB минус 300–800 мс; стабильность скорости в часы пик |
| Десятки мелких CSS/JS-файлов от плагинов | Минификация и объединение (Autoptimize / WP Rocket) | Минус 10–30 запросов на страницу; LCP минус 0,3–0,8 секунды |
Итоговая картина после полного цикла: тот же типичный сайт выходит на LCP 1,5–2,5 секунды, вес главной 1–2 МБ и оценку PageSpeed 75–95 для мобильных. Идеальные 100 баллов — не самоцель: гнаться за сотней в ущерб функциональности (убить всю аналитику и виджеты ради цифры) не нужно. Ориентир — «зелёная зона» Core Web Vitals у реальных пользователей, а не цифра в лабораторном тесте.
Честная оговорка: если сайт собран на перегруженной теме с пятью конструкторами поверх друг друга, одними плагинами его не спасти — там вопрос уже о пересборке ключевых шаблонов. Это видно на этапе диагностики: если после кэша и сжатия LCP всё ещё за 4 секунды — дело в теме, а не в настройках.
План ускорения за неделю: чек-лист
Разложим всё по дням — по часу-два вечером:
- День 1 — замер. PageSpeed Insights + GTmetrix для главной и 2–3 внутренних страниц. Запишите LCP, INP, CLS, вес страницы, TTFB. Сделайте полный бэкап сайта (плагин Duplicator / UpdraftPlus или бэкап у хостера).
- День 2 — кэширование. Установите один плагин кэша (WP Rocket или LiteSpeed Cache), включите кэш страниц и кэш браузера. Проверьте формы, корзину, личный кабинет в инкогнито.
- День 3 — изображения. Установите ShortPixel/Imagify, прогоните медиабиблиотеку, включите WebP и автосжатие новых загрузок. Проверьте визуально ключевые страницы.
- День 4 — ревизия плагинов. Удалите деактивированные и дубли, прогоните Query Monitor, почистите autoload. После каждого удаления — проверка сайта.
- День 5 — скрипты и стили. Минификация и объединение CSS/JS, отложенная загрузка скриптов (defer/async), ленивая загрузка для видео и iframe.
- День 6 — хостинг. Проверьте версию PHP (8.x), TTFB, локацию сервера. Если хостинг — слабое звено, запланируйте переезд.
- День 7 — контрольный замер. Те же страницы, те же инструменты. Сравните с цифрами дня 1 — и зафиксируйте результат.
Дальше — поддерживающий режим: раз в квартал прогоняйте замер и ревизию плагинов, потому что сайт имеет свойство «обрастать» — новые плагины, несжатые картинки, обновления темы. Если следить некогда, это закрывает техническая поддержка сайта: мониторинг скорости, обновления и чистка входят в ежемесячное обслуживание.
Ускорение под ключ от Euromedia
Самостоятельное ускорение — реально, но требует времени и аккуратности: одна неверная настройка кэша — и сайт показывает посетителям устаревшие цены или «ломает» оформление. Мы ускоряем сайты на WordPress регулярно: диагностика (замер + Query Monitor + аудит плагинов), кэширование, сжатие изображений, чистка плагинов и базы, настройка PHP и переезд на быстрый хостинг при необходимости.
Euromedia — digital-агентство с 12-летним опытом и 600+ реализованными проектами. Офис — в Дзержинске (ул. Фурманова, 33), работаем по всей Беларуси. Связаться с нами: страница контактов, телефон +375 (29) 256-33-94, email euromedia.by@yandex.by, Пн–Пт с 9:00 до 17:30.
Сайт грузится дольше трёх секунд и теряет клиентов? Пришлите ссылку — замерим скорость, покажем, что именно тормозит, и назовём срок и стоимость ускорения: оставить заявку.
Частые вопросы об ускорении сайта на WordPress
Сколько времени занимает ускорение сайта на WordPress?
Базовый цикл — кэширование, сжатие изображений, чистка плагинов — занимает от нескольких часов до 2–3 дней работы. Переезд на другой хостинг добавляет ещё день-два. Если проблема в перегруженной теме и нужна пересборка шаблонов — это уже 1–3 недели.
Какой плагин кэширования лучше: WP Rocket или LiteSpeed Cache?
Оба отличные. WP Rocket проще и работает на любом хостинге, но платный (~59$/год). LiteSpeed Cache бесплатен и мощнее, но полностью раскрывается только на хостинге с сервером LiteSpeed. Если ваш хостер использует LiteSpeed — берите его, если нет — WP Rocket. Главное правило: только один плагин кэширования на сайт.
Поможет ли ускорение сайта выйти в топ Google и Яндекса?
Напрямую — как один из факторов: Google учитывает Core Web Vitals в ранжировании, Яндекс — поведенческие факторы, которые зависят от скорости. Но ускорение не заменит контент, ссылочную массу и техническую базу. Считайте его обязательным фундаментом, а не волшебной таблеткой для топа.
Можно ли ускорить сайт на WordPress, не меняя хостинг?
В большинстве случаев — да: кэширование, сжатие изображений и чистка плагинов дают основной эффект на любом хостинге. Менять хостинг стоит, только если TTFB стабильно выше 800 мс, нет PHP 8.x или поддержки Redis — то есть когда упёрлись в железо, а не в настройки.
Почему после установки плагина кэширования сайт «сломался»?
Три частые причины: конфликт двух плагинов кэширования; агрессивная минификация JS, сломавшая скрипты темы; закэшировались динамические страницы (корзина, личный кабинет, формы). Лечится отключением конфликтного плагина, ослаблением минификации и исключением динамических страниц из кэша. Поэтому перед любыми экспериментами — бэкап.
Сколько стоит ускорение сайта, если заказать его в агентстве?
Зависит от состояния сайта: базовая оптимизация (кэш, изображения, чистка плагинов) — это часы работы, переезд на хостинг и пересборка тяжёлых шаблонов — дни. Точную стоимость называем после диагностики: присылайте ссылку на сайт — замерим и посчитаем.