Краткий ответ: Полный проход тюнинга одним списком — измерить, кешировать на каждом слое, оттюнить PHP и базу, облегчить страницу, измерить ещё раз. Каждая строка ссылается на полный гайд. VPS, закрывающий каждый пункт, отдаёт кешированные страницы за десятки миллисекунд, а некешированные — комфортно быстрее секунды.
Обзор
Это сжатая пара к ускорению WordPress — полезна при сдаче нового сайта или охоте на регрессию. Порядок важен: измерения обрамляют работу, кеширование даёт самые большие выигрыши, микрооптимизации идут последними.
Что нужно иметь
- Привычку измерять: PageSpeed Insights / WebPageTest для взгляда посетителя,
htop+ Query Monitor для взгляда сервера. - Зафиксированные базовые числа — нельзя улучшить то, что не измерили.
Пошаговая инструкция
Измерить:
- ☐ Базовые TTFB, LCP и отклик админки зафиксированы.
Кешировать:
- ☐ Ровно один полностраничный кеш активен и проверен заголовком ответа (гайд).
- ☐ WooCommerce: cart/checkout/account исключены (детали).
- ☐ Объектный кеш Redis подключён, hit ratio проверен (настройка).
- ☐ OPcache включён с достаточной памятью (тюнинг PHP).
- ☐ Кеш браузера: 30-дневные expires на статике.
Тюнить:
- ☐ PHP 8.3; FPM-пул размерен от RAM (формула).
- ☐ InnoDB buffer pool размерен; slow-query log просмотрен (гайд по базе).
- ☐ Autoload-опции до ~800 KB; протухшие транзиенты вычищены.
- ☐ WP-cron заменён системным cron на бойких/коммерческих сайтах.
Облегчить:
- ☐ Изображения WebP + lazy loading; никаких hero-картинок на несколько МБ.
- ☐ Неиспользуемые плагины деактивированы и удалены; тяжёлые оправданы данными Query Monitor.
- ☐ Тема лёгкая, или вывод билдера агрессивно кешируется.
Измерить ещё раз:
- ☐ Те же тесты, что и базовые; числа записаны. TTFB на кеш-попаданиях всё ещё медленный? План маловат — рассмотрите NVMe/Power VPS.
Типичные проблемы
- Оптимизация без измерений: усилия падают не на тот слой — всегда обрамляйте тестами.
- Нагромождение плагинов: три плагина оптимизации воюют между собой — один страничный кеш, один инструмент изображений, один объектный кеш.
- Тестирование только главной: архивы, поиск и checkout — вот где прячутся регрессии.
Когда обращаться в поддержку
Все пункты закрыты, а сайт всё равно медленный на уровне платформы (стабильное насыщение CPU, IO wait)? Откройте тикет со своими измерениями, чтобы правильно подобрать апгрейд.
Частые вопросы
В каком порядке применять исправления производительности?
Сначала измерить, затем страничный кеш, объектный кеш и OPcache, дальше тюнинг PHP/базы, в конце медиа и чистка плагинов — и перемерять после каждого слоя, чтобы видеть, что реально помогло.
Насколько быстрым должен быть хорошо оттюненный сайт на WordPress?
Кешированные страницы должны показывать TTFB в десятки миллисекунд из близкого региона; некешированные (checkout, админка) — уверенно укладываться в одну секунду на адекватном железе.
Когда пора апгрейдить VPS вместо дальнейшей оптимизации?
Когда кеш-попадания подтверждённо быстрые, а некешированные запросы остаются медленными с насыщенным CPU или диском — тюнинг не создаст ресурсы, которых у плана нет.
Похожие статьи
- Как ускорить WordPress на VPS
- Как настроить объектный кеш Redis
- Как оптимизировать PHP для WordPress
- Как оптимизировать MariaDB для WordPress
Готовы начать? Заказать WordPress VPS в Cloud2Y →
