TTFB (Time to First Byte) свыше 800 мс убивает конверсию на 15-20% и пессимизирует сайт в Core Web Vitals. Для высоконагруженных проектов на WordPress проблема не в теме, а в избыточных SQL-запросах, которые при посещаемости от 5 000 чел./сутки перегружают MySQL до критических 90% CPU.
Очистка БД: удаление «мусора» и оптимизация таблиц
Типичная база данных WordPress через год работы разрастается на 200-500 МБ из-за ревизий постов, остаточных данных плагинов (orphaned data) и тысяч записей в wp_options. Особенно критичны автосохранения: при 100 статьях и 10 правках каждой создается 1000 лишних строк, что замедляет поиск по БД на 10-15%.
Кейс: удаление 15 000 записей в таблице wp_options и очистка транзиентов (transients) сократило время выполнения сложных SQL-запросов с 1.2 сек до 0.3 сек. Рекомендую использовать WP-Optimize или прямой SQL-запрос для удаления ревизий старше 3 дней.
Экспертный вывод: автоматическая очистка раз в неделю — обязательный стандарт. Оставлять более 5 ревизий на один пост — неоправданный расход ресурсов сервера.
Объектное кэширование: переход с Page Cache на Redis
Обычный кэш страниц (WP Rocket, LiteSpeed) помогает только статическим пользователям. Для динамических разделов (личный кабинет, фильтры товаров) нужно объектное кэширование. Redis переносит результаты тяжелых запросов из медленной MySQL в быструю оперативную память (RAM), сокращая время отклика сервера с 1.5 сек до 200-400 мс.
Сравнение: Memcached работает быстрее с простыми ключами, но Redis поддерживает сложные структуры данных и персистентность. На VPS с 4 ГБ RAM выделение 256-512 МБ под Redis снижает нагрузку на процессор на 30-40% при пиковых нагрузках.
Экспертный вывод: для интернет-магазинов и порталов Redis — единственный способ избежать «падения» базы при резком наплыве трафика. Все остальное — полумеры.
Оптимизация индексации и структуры таблиц
Стандартная кодировка utf8 в старых версиях WP занимает больше места и работает медленнее, чем utf8mb4. Переход на utf8mb4 позволяет корректно работать с эмодзи и ускоряет сортировку данных. Также критически важно проверить индексы в таблице wp_postmeta; отсутствие индекса по полю meta_key превращает простой запрос в full table scan, что занимает до 2-3 секунд на больших БД.
Практика: внедрение композитных индексов для кастомных полей (ACF) ускоряет фильтрацию товаров в каталоге в 4-6 раз. Это особенно заметно, когда количество записей в meta_table превышает 100 000 строк.
Экспертный вывод: если у вас сложная разработка сайта на WordPress, аудит структуры БД должен проводиться на этапе бета-тестирования, а не после падения сервера.
Настройка MySQL и параметры конфигурации сервера
Стандартные настройки MySQL в большинстве хостингов рассчитаны на «средний» сайт. Для высокой нагрузки необходимо увеличить innodb_buffer_pool_size до 50-70% от общего объема RAM сервера. Если у вас 8 ГБ RAM, установка этого параметра на 4-5 ГБ позволит держать почти всю активную базу в памяти, исключая чтение с диска.
Ошибка новичка: использование дешевых shared-хостингов за 300-500 руб/мес для проектов с БД более 1 ГБ. В таких условиях никакой кэш не спасет от ограничений по IOPS (операциям ввода-вывода), которые режут скорость до 2-5 сек на запрос.
Экспертный вывод: переходите на VPS с NVMe-дисками и ручной настройкой my.cnf, как только ваш дневной трафик превышает 2 000 уникальных посетителей.
Вывод
Для достижения TTFB < 1 сек необходим комплекс: Redis для объектного кэширования, жесткий лимит ревизий (до 3-5 шт) и оптимизация innodb_buffer_pool_size. Начинайте с очистки wp_options и внедрения Redis — это дает 80% результата при минимальных затратах. Избегайте перегрузки сайта тяжелыми конструкторами страниц, так как они генерируют избыточные мета-запросы, которые не перекроет даже самый мощный сервер.
Подробный разбор всей темы смотрите в обзоре Разработка сайтов на WordPress.