Недавно ко мне обратился клиент из B2B-сегмента - компания продаёт спецтехнику, сайт на WordPress, трафик есть, но заявок почти нет. Открываю PageSpeed Insights - 23 балла на мобильных. Страница весит больше 8 МБ, загружается 9 секунд. При этом владелец искренне удивился: «Мне казалось, всё нормально работает». Вот тут и начинается разговор про скорость загрузки сайта и то, как она убивает конверсию тихо и незаметно.
Я Андрей Зенков, руковожу веб-студией «Мельница» и с 2013 года занимаюсь продвижением сайтов - в том числе в тяжёлых B2B-нишах, где покупатель приходит с мобильного телефона прямо с объекта. В этой статье разберём, как ускорить WordPress сайт: почему он тормозит, какие инструменты дают нужную информацию, и что реально работает. Только конкретные шаги и плагины.
Чтобы ускорить WordPress сайт, нужно последовательно устранить узкие места: сжать изображения через EWWW Image Optimizer или ShortPixel, настроить кэширование через WP Rocket или LiteSpeed Cache, подключить минификацию через Autoptimize - и только потом браться за серверную часть и чистку базы данных.
Почему WordPress тормозит: разбираем причины
WordPress сам по себе не медленный. Но он очень легко превращается в тормоз, если не следить за тем, что на нём накапливается. Проблема почти всегда комплексная - одна причина тянет за собой другую, и в итоге сайт начинает грузиться по 5-7 секунд, хотя каждый отдельный элемент «вроде бы нормальный».
Первое и самое распространённое - лишние плагины. Каждый плагин добавляет свои скрипты и стили, которые грузятся на всех страницах, даже там, где они не нужны. Я видел сайты с 60+ активными плагинами, половина из которых не используется годами. Каждый такой плагин добавляет HTTP-запросы и лишний код на страницу.
Второе - перегруженные темы. Особенно это касается популярных конструкторов типа Avada, Divi, Betheme. Они тащат за собой огромное количество CSS и JS-файлов, большую часть которых конкретный сайт никогда не использует. Тема на 2 МБ CSS - это не редкость, и это катастрофа для скорости загрузки.
Третье - неоптимизированные изображения. Загружают JPEG прямо с фотоаппарата, размером 4000x3000 пикселей и весом 5-8 МБ. WordPress делает миниатюры, но оригинал никуда не девается. Иногда один такой файл весит больше, чем вся остальная страница.
Четвёртое - отсутствие кэширования. Каждый запрос к сайту без кэша - это обращение к базе данных, сборка страницы из PHP, отдача HTML. При нескольких одновременных пользователях сервер начинает захлёбываться. Кэш решает это кардинально: готовый HTML отдаётся мгновенно, без обращения к БД.
Пятое - слабый хостинг и устаревший PHP. Shared-хостинг с PHP 7.0 и 256 МБ RAM - не фундамент, на котором строят быстрый сайт. PHP 8.x работает значительно быстрее, а нехватка памяти заставляет сервер «думать» над каждым запросом.
Как проверить скорость сайта перед оптимизацией
Прежде чем что-то трогать - нужно собрать информацию о состоянии сайта. Без этого оптимизация превращается в угадывание. Я всегда начинаю с аудита: смотрю, что именно тормозит, какой размер страниц, сколько запросов, что блокирует рендеринг.
Главный инструмент - Google PageSpeed Insights. Он показывает Core Web Vitals: LCP (время загрузки основного контента), INP (отклик на взаимодействие), CLS (визуальная стабильность). Именно эти метрики Google использует как сигнал ранжирования. Если LCP больше 4 секунд - это уже красная зона. Плюс PageSpeed даёт конкретные рекомендации: какие изображения нужно сжать, какие скрипты блокируют рендеринг, где можно включить кэш.
Второй инструмент - GTmetrix. Он показывает более детальную информацию: водопад загрузки ресурсов, размер каждого файла, время ответа сервера. Очень удобно для поиска «тяжёлых» файлов - тех самых изображений на 5 МБ или CSS на 2 МБ. GTmetrix также позволяет тестировать с разных географических точек, что важно для понимания реальной скорости ускорения загрузки для конечного пользователя.
Третий - Pingdom Tools. Проще в интерпретации, хорошо подходит для быстрой проверки и мониторинга динамики после изменений. Я использую его как «контрольный замер» до и после оптимизации.
| Инструмент | Что измеряет | Стоимость | Что даёт на выходе |
| Google PageSpeed Insights | Core Web Vitals (LCP, INP, CLS), производительность страницы | Бесплатно | Оценка 0-100, конкретные рекомендации по исправлению, данные реальных пользователей (CrUX) |
| GTmetrix | Скорость загрузки, размер страницы, количество запросов, водопад ресурсов | Бесплатно / от $4.25/мес | Детальный водопад загрузки, анализ каждого файла, тест из разных локаций |
| Pingdom Tools | Время загрузки, размер страницы, оценка производительности | Бесплатно (базовый) / от $10/мес | Простой отчёт с оценкой, удобен для сравнения до/после оптимизации |
Минимальный аудит перед началом работы: проверить сайт в PageSpeed Insights на мобильных и десктопе, скачать отчёт GTmetrix и найти три самых тяжёлых файла, зафиксировать исходные цифры - время загрузки, размер страницы, количество запросов. Это займёт 15 минут, но сэкономит часы работы в неправильном направлении.
Оптимизация изображений: самый быстрый выигрыш
Когда я делаю первый технический аудит нового клиента, почти всегда картина одна и та же: 60-70% веса страницы - это изображения. Фотографии товаров по 3-5 МБ, загруженные прямо с фотоаппарата, слайдеры с десятками картинок, которые грузятся все разом при открытии страницы. Именно с оптимизации изображений я всегда начинаю работу по ускорению сайта - это самый быстрый выигрыш с минимальными усилиями.
Работаю по трём уровням последовательно.
Первый уровень: сжатие без потери качества. Здесь у меня три рабочих инструмента - EWWW Image Optimizer, ShortPixel и Imagify. EWWW Image Optimizer бесплатен, работает на сервере и не отправляет данные во внешние сервисы - это важно для клиентов с NDA. ShortPixel и Imagify работают через облако: загружают картинку на свои серверы, сжимают, возвращают обратно. Качество у всех трёх примерно одинаковое, разница - в удобстве массовой обработки и цене за большие объёмы. По моему опыту, снижение размера картинок на 40-60% без видимой потери качества - это норма. На сайтах с большим каталогом я видел результаты и в 70-80%.
Второй уровень: конвертация в WebP. Формат WebP при том же визуальном качестве весит на 25-35% меньше, чем JPEG, и на 50-70% меньше, чем PNG. Все три плагина умеют конвертировать автоматически при загрузке: WordPress отдаёт WebP браузерам, которые его поддерживают (сейчас это 97% браузеров), и оригинал - остальным. Никаких дополнительных настроек не нужно, включается одним чекбоксом.
Третий уровень: ленивая загрузка (lazy load). С WordPress 5.5 она встроена в ядро и работает по умолчанию - атрибут loading="lazy" добавляется к изображениям автоматически. Браузер загружает только те картинки, которые попадают в видимую область экрана. Всё остальное - по мере прокрутки. На длинных страницах с большим количеством картинок это сокращает начальную загрузку в 2-3 раза.
Отдельный вопрос - что делать с уже загруженными изображениями. Новые картинки плагины обрабатывают автоматически при загрузке. Для старых есть массовая обработка: в EWWW Image Optimizer это раздел «Bulk Optimize» в меню инструментов, в ShortPixel и Imagify - аналогичные разделы в настройках плагина. Запускаете, ждёте, пока плагин пройдёт по всей медиабиблиотеке. На сайте с тысячами изображений это может занять несколько часов, но делается один раз.
У меня был клиент - онлайн-магазин промышленного оборудования, около 800 товаров. Все фото грузились напрямую из 1С, без какой-либо обработки. Средний размер изображения - 2,4 МБ, страница каталога весила 18 МБ. После установки ShortPixel с конвертацией в WebP и включения lazy load - 2,1 МБ. Время загрузки упало с 11 до 3,8 секунды, PageSpeed вырос с 19 до 61 балла. Только за счёт изображений, без каких-либо других изменений.
Кэширование страниц: как ускорить отдачу контента
Каждый раз, когда пользователь открывает страницу WordPress без кэша, сервер проделывает одну и ту же работу: обращается к базе данных, собирает данные, выполняет PHP-код, формирует HTML и отдаёт его браузеру. На нагруженном сайте этот процесс занимает 300-800 миллисекунд только на стороне сервера. При большом потоке посетителей база данных и PHP начинают очередь запросов, время ответа растёт.
Кэширование решает эту проблему простым способом: сервер один раз генерирует готовый HTML страниц и сохраняет его. Следующему посетителю отдаётся уже готовый файл - без обращения к базе данных, без PHP. Время ответа падает до 10-50 миллисекунд. Это и даёт большую часть выигрыша в скорости при правильной настройке кэширования - иногда ускорение в 2-3 раза только за счёт этого шага.
Лучших плагинов для кэширования несколько, и выбор зависит от хостинга и бюджета. Вот сравнение основных вариантов:
| Плагин | Цена | CDN | Сложность настройки | Примечание |
| W3 Total Cache | Бесплатно / Pro от $9/мес | Да | Высокая | Максимум настроек, легко сломать |
| WP Fastest Cache | Бесплатно / Premium от $49 | Нет (в платной - да) | Низкая | Хороший выбор для старта |
| LiteSpeed Cache | Бесплатно | Да (QUIC.cloud) | Средняя | Только для LiteSpeed-серверов |
| WP Rocket | От $59/год | Да | Низкая | Лучший «из коробки», рекомендую |
| WP Super Cache | Бесплатно | Нет | Низкая | Простой, от Automattic |
Мой рабочий выбор - WP Rocket для клиентских проектов и LiteSpeed Cache там, где хостинг на LiteSpeed-сервере. WP Rocket работает правильно сразу после установки: минимум настроек, максимум результата. W3 Total Cache я ставлю только когда нужен тонкий контроль или интеграция с конкретным CDN - слишком много точек, где можно ошибиться при настройке.
Следующий уровень - объектное кэширование через Redis или Memcached. Это кэширование результатов запросов к базе данных, а не готовых HTML-страниц. Актуально для интернет-магазинов на WooCommerce с большим каталогом и высокой нагрузкой. Требует поддержки на стороне хостинга - уточняйте у своего провайдера. На нагруженном WooCommerce-сайте Redis добавляет ещё 30-50% к производительности бэкенда.
Важный момент: кэш нужно правильно инвалидировать. Все нормальные плагины делают это автоматически при обновлении записи или страницы. Но если вы используете динамический контент - корзину, личный кабинет, персонализированные блоки - убедитесь, что эти части страницы исключены из кэша. Иначе один пользователь может увидеть данные другого.
Минификация CSS, JS и HTML: убираем лишний код
Каждый CSS и JS файл, который браузер загружает при открытии страницы, написан разработчиком для людей: с отступами, переносами строк, комментариями, понятными именами переменных. Всё это нужно для работы с кодом, но браузеру безразлично. Минификация убирает всё лишнее - пробелы, переносы, комментарии - без изменения функциональности. Типичный CSS-файл после минификации становится на 20-40% легче.
Для ускорения загрузки через минификацию и объединение файлов я использую Autoptimize. Бесплатный плагин, который умеет три вещи: минифицировать CSS и JS, объединять несколько файлов в один (меньше HTTP-запросов), и генерировать критический CSS - тот минимум стилей, который нужен для отрисовки видимой части страницы без загрузки основного CSS-файла.
Отдельная тема - отложенная и асинхронная загрузка JS. По умолчанию браузер, встретив тег <script> в HTML, останавливает рендеринг страниц и ждёт, пока скрипт загрузится и выполнится. Это называется «блокирующий скрипт» - именно он часто стоит за высоким показателем «Устранение ресурсов, блокирующих рендеринг» в PageSpeed Insights. Атрибут defer говорит браузеру загружать скрипт параллельно с HTML, но выполнять после. Атрибут async - загружать и выполнять сразу, не дожидаясь остального. Autoptimize позволяет применить defer ко всем JS одним чекбоксом.
Здесь есть типичная ошибка: после включения минификации и объединения JS часть функций сайта перестаёт работать. Это происходит потому, что некоторые скрипты написаны с расчётом на определённый порядок загрузки, который нарушается при объединении. Или потому, что скрипт конфликтует с другим при слиянии. Решение - исключить проблемные скрипты из обработки. В Autoptimize для этого есть поле «Exclude scripts from Autoptimize»: вписываете имя файла или часть пути, плагин оставляет его нетронутым.
Ещё один инструмент, который можно использовать в паре с Autoptimize: Perfmatters или Asset Cleanup Pro. Их задача - не минифицировать, а отключать ненужные скрипты и стили на конкретных страницах. Например, плагин контактной формы грузит свои скрипты на каждой странице сайта, хотя форма есть только на одной. Perfmatters позволяет отключить эти скрипты везде, кроме страницы с формой. На типичной странице каталога такой точечный подход убирает лишние 200-500 КБ.
Практика работы с минификацией: всегда тестируйте после каждого изменения. Включили минификацию CSS - проверьте визуально несколько ключевых страниц. Включили объединение JS - проверьте все интерактивные элементы: слайдеры, фильтры, добавление в корзину, формы. Делайте это в режиме инкогнито, чтобы браузер не использовал старый кэш. Лучше 10 минут на проверку, чем звонок клиента на следующий день с вопросом «почему у нас ничего не работает».
Хостинг, PHP и серверная оптимизация
Плагины не сделают большую работу за слабый сервер. Это ошибка, которую я вижу регулярно: владелец сайта ставит WP Rocket, настраивает кэш, оптимизирует изображения - а скорость загрузки почти не меняется. Причина в том, что проблема была не в WordPress, а в хостинге.
Shared-хостинг за 100-200 рублей в месяц - это ресурсы, которые делятся между сотнями сайтов. Если соседи нагрузили сервер - ваш сайт тормозит. Для серьёзных проектов я рекомендую VPS от 1 ГБ RAM или облачный хостинг с гарантированными ресурсами. Разница в цене - 500-1500 рублей в месяц, разница в скорости - в разы.
Отдельно про PHP: переход с PHP 7.4 на PHP 8.2 даёт прирост производительности от 30 до 50% без каких-либо изменений в коде. Можно использовать этот рычаг бесплатно - просто смените версию PHP в панели хостинга. На одном из проектов по продаже промышленных насосов мы сменили PHP 7.2 на 8.1 и получили плюс 8 баллов PSI без единого изменения в WordPress - только за счёт этого переключателя. Важно проверить совместимость плагинов заранее - но у большинства современных инструментов с PHP 8.x проблем нет.
Про серверный стек: Nginx обрабатывает статические файлы быстрее Apache, OPcache кэширует скомпилированный PHP-код в памяти и ускоряет каждый запрос. Redis или Memcached для object cache - следующий уровень, особенно для интернет-магазинов с большой базой товаров. LiteSpeed Cache работает в полную силу только на серверах с LiteSpeed Web Server - если ваш хостинг его не поддерживает, плагин даст лишь часть возможностей.
CDN Cloudflare - простое и бесплатное решение для ускорения отдачи статики. Подключается за 20 минут, статические файлы (картинки, CSS, JS) отдаются с ближайшего к посетителю сервера. Для аудитории по всей России это ощутимо: страница из московского датацентра грузится быстрее, чем с сервера в Европе.
Чистка базы данных и гигиена сайта
WordPress накапливает мусор незаметно. После года активной работы база данных среднего блога содержит тысячи ненужных записей: черновики, ревизии страниц, удалённые записи в корзине, спам-комментарии, устаревшие transients (временные опции в таблице wp_options). Всё это замедляет запросы к базе и влияет на скорость загрузки.
Для чистки я использую два инструмента. WP-Optimize - простой плагин, который убирает ревизии, черновики, удалённые комментарии и оптимизирует таблицы базы. Запускаю вручную раз в месяц или настраиваю по расписанию. Advanced Database Cleaner - более детальный инструмент, можно использовать для глубокой чистки transients и orphaned data (осиротевших записей от удалённых плагинов).
Ограничение ревизий - обязательный шаг для контентных проектов. В wp-config.php добавляю строку define('WP_POST_REVISIONS', 3); (сделайте бэкап перед правкой - ошибка тут отключит сайт) - WordPress будет хранить не более трёх версий каждой страницы, а не бесконечное количество. На одном блоге о строительной технике с 400 статьями после этой настройки и чистки база уменьшилась с 180 МБ до 34 МБ, время ответа сервера сократилось на 0,3 секунды.
Отдельная тема - неиспользуемые плагины и темы. Деактивация не решает проблему: деактивированный плагин всё равно занимает место на сервере, а его таблицы остаются в базе. Полное удаление - через «Плагины» - «Удалить» - убирает и файлы, и (если плагин написан правильно) его данные из БД. Неиспользуемые темы удаляйте полностью, оставляйте только активную и одну резервную. Каждая лишняя тема - это файлы, которые WordPress проверяет при каждом запросе.
Гигиена сайта - это не разовая акция, а регулярная работа. Раз в месяц: чистка базы, проверка плагинов, удаление того, что не используется. Это занимает 15 минут и даёт накопительный эффект.
Итоги: с чего начать и что даст результат быстрее всего
За годы практики я выработал чёткий маршрут для ускорения загрузки любого WordPress-сайта. Он решает 80% проблем без глубокого технического погружения и без профессионального вмешательства.
- Измерьте текущее состояние. PageSpeed Insights и GTmetrix покажут реальную картину. Запишите баллы PSI (мобайл и десктоп) и время загрузки - это ваша точка отсчёта. Без замеров непонятно, работают ли ваши действия.
- Оптимизируйте изображения. Это один из лучших методов по соотношению усилий и результата: EWWW Image Optimizer или ShortPixel + конвертация в WebP + lazy load. Страниц с тяжёлыми картинками у большинства сайтов большинство, и именно здесь скрыт главный вес.
- Подключите кэш. WP Rocket для тех, кто готов заплатить, LiteSpeed Cache - если хостинг поддерживает. Кэширование даёт мгновенный прирост скорости загрузки для повторных посетителей и снижает нагрузку на сервер.
- Минифицируйте CSS и JS. Autoptimize или встроенные инструменты WP Rocket решают задачу за несколько кликов. Defer для некритичного JS - отдельный шаг, который улучшает LCP.
- Проверьте хостинг и PHP. Смените PHP на 8.2, если ещё не сделали. Если сайт на shared-хостинге с постоянными тормозами - это сигнал переходить на VPS. Cloudflare CDN можно подключить как бесплатный инструмент ускорения ещё до смены хостинга.
- Почистите базу данных. WP-Optimize, ограничение ревизий, удаление неиспользуемых плагинов и тем. Полчаса работы с накопительным эффектом на месяцы вперёд.
Первые три шага - изображения, кэш, минификация - дают ускорение загрузки на 40-60% на большинстве сайтов. Именно с них стоит начинать. WordPress при правильно подобранных и настроенных инструментах реально загружается за 1-2 секунды - это достижимо для большинства проектов, не только для лендингов.
В своей практике с 2013 года я видел сотни сайтов с баллами PSI от 8 до 30. После системной работы по этому маршруту большинство из них уходили в диапазон 60-85 баллов. Это не предел, но уже уровень, который перестаёт тормозить SEO и не отпугивает пользователей.
Проверьте свой сайт прямо сейчас через PageSpeed Insights. Если видите меньше 50 баллов на мобайле - у вас есть конкретная работа, которую можно сделать сегодня, используя один из плагинов из этой статьи.
Эта статья основана на личном опыте автора и актуальна на момент публикации. Интерфейсы сервисов и алгоритмы поисковых систем регулярно меняются - рекомендую проверять актуальность инструкций на официальных ресурсах. Если у вас остались вопросы - задайте их в комментариях.
Список литературы
- WordPress.org - Optimization / Advanced Administration Handbook // WordPress Developer Resources
- Google for Developers - About PageSpeed Insights // developers.google.com
- Google / web.dev - Lazy load images and iframe elements // web.dev, 2023
- WordPress Codex - WordPress Optimization / WordPress Performance // codex.wordpress.org
