Как мы ускорили сайт на Wordpress с 13 секунд до 0,3

К нам обратилась компания с большим интернет-магазином серверного оборудования на WordPress + WooCommerce. Сайт работал медленно — это было заметно и пользователям, и в метриках. Клиент хотел разобраться, в чём проблема, и исправить ситуацию.

Мы провели технический аудит, по итогам которого составили отчёт и план работ.

Что нашли при аудите?

Первый же замер показал: сервер начинает отдавать HTML главной страницы только через 4,2 секунды после запроса, а некоторые страницы и через 13 секунд. Почти всё это время уходит до первого байта — то есть на серверной генерации страницы.

Дальнейший анализ выявил несколько проблемных слоёв.

Что тормозило?

Кэш страниц не работал. Заголовки ответа прямо говорили: страница генерируется заново при каждом запросе.

Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 19 Nov 1981 08:52:00 GMT

Блокирующие скрипты в критическом пути рендера. На странице: 19 скриптов: 16 CSS и 3 JS. Шесть из них грузятся со сторонних сайтов: шрифты, Google Translate, Cloudflare Captcha. Самый тяжёлый занимает 403 мс. TotalBlockingTime страницы — 2242 мс.

Плагины генерировали огромную нагрузку. На одной странице товара с модулем энциклопедиии:

• 89 000 вызовов внутреннего PHP-кода
• 120 дублирующих запросов к базе данных

Encyclopedia Lite и WooCommerce при каждой загрузке страницы генерировали это заново.

Изображения весят до 50 МБ без сжатия и без предзагрузки.

Устаревший стек. PHP, MySQL, Redis, Apache и сама ОС — всё работало на старых версиях с накопившимися runtime-ошибками. Ошибки логировались при каждом запросе, создавая дополнительную нагрузку на диск.

Redis настроен неоптимально — повышенный расход памяти снижал общую производительность сервера.

Подготовка рабочей среды.

Для начала развернули локальную копию проекта, настроили профилирование через Xdebug + QCacheGrind и Tideways. Сделали резервные копии. Обновили WordPress и плагины — это сразу убрало часть PHP-ошибок.

Оптимизация шаблона.

Нашли главные узкие места в коде темы:

• функции get_pa_* вызывались 149 000+ раз на одной странице
• wc_get_product вызывался в цикле без кэширования
• агрегация атрибутов вариаций товара пересчитывалась при каждом запросе

Переписали логику шаблона — убрали лишние вызовы, добавили кэширование внутри цикла.

Работа с плагинами

• Encyclopedia Lite генерировал огромное количество WP_Query на каждой странице товара — закэшировали результаты на уровне NGINX
• Custom Permalinks накопил сотни неверных редиректов — почистили и исправили

База данных

Через Query Monitor нашли группу товаров с повреждённой структурой данных. Написали скрипт восстановления — исправили данные без ручного разбора каждого товара.

Кэширование и сжатие

Настроили корректное кэширование страниц, оптимизировали конфигурацию Redis, подключили минификацию JS и CSS, настроили сжатие изображений с автоматическим созданием превью при загрузке.

Время первого отклика на самой медленной странице уменьшилось с 13 секунд до 0,31 секунды - почти что в 50 раз!

Теперь нам остается только наблюдать за ростом конверсии и SEO!