Кратко — даёт ли смысл что‑то менять на shared‑хостинге: многое можно улучшить без перехода на VPS, но при ограничениях shared‑сервера есть предел: если у вас высокий TTFB из‑за перегруженного хоста или медленного PHP/БД на машине, единственный надёжный выход — более «живой» хостинг (VPS / managed WP / хостинг с LiteSpeed). Ниже — конкретный план действий, что проверить и какие изменения внедрять в порядке приоритета.
1) Быстрая диагностика (перед изменениями)
- Сделайте базовый замер: WebPageTest (поблизости к хосту), GTmetrix и PageSpeed — зафиксируйте TTFB и LCP.
- Посмотрите заголовки ответа curl -I https://вашсайт — есть ли кэш‑заголовки (cache, x-cache, cf‑cache)? Это покажет, кэшируется ли HTML.
- Включите плагин Query Monitor / Health Check или плагин‑профайлер (или New Relic, если доступен) — найдите медленные запросы, плагины, хуки, запросы к БД.
- phpinfo() — проверьте версию PHP, включён ли OPcache, доступен ли Redis/Memcached, используется ли PHP‑FPM.
2) Самые эффективные и простые шаги (начните с них)
- Включите CDN (Cloudflare бесплатный — значительно снижает TTFB для статики и ускоряет географию). Для WordPress можно подключить Cloudflare и включить Brotli + HTTP/2/3. Рассмотрите Cloudflare APO (платно) для кэширования HTML на edge — сильный выигрыш в TTFB/LCP.
- Настройте полный page cache (страничный кеш): если ваш плагин кэширования поддерживает кэш HTML (и правильно отдаёт его без PHP), включите его. Полноценный page cache уменьшит TTFB гораздо сильнее, чем объектный кэш.
- Preload LCP‑ресурса: определите главный LCP элемент (обычно крупное изображение/герой) и добавьте rel=preload для него, либо используйте плагин, который делает это автоматически.
- Отложенная загрузка скриптов: defer/async для ненужных блокирующих JS, инлайн критического CSS. Плагины: WP Rocket, Perfmatters, Asset CleanUp, Autoptimize — тестируйте по одному изменению.
- Оптимизируйте загрузку шрифтов: preconnect/preload к CDN шрифтов, использ. форматы WOFF2, размещайте критические стили шрифтов.
- Минимизируйте сторонние скрипты (Analytics, виджеты, рекламные сети) — они могут блокировать LCP.
3) Серверные и конфигурационные изменения, которые реально можно получить на shared
- OPcache: убедитесь, что он включён (нулевая/почти нулевая задержка компиляции PHP). На большинстве shared он включён по умолчанию; если нет — попросите поддержку включить.
- PHP‑версия и PHP‑FPM: используйте самую стабильную актуальную PHP 8.x (8.1/8.2/8.3 в зависимости от совместимости) и PHP‑FPM (он быстрее, чем mod_php). Проверьте в панели хостинга, можно ли переключить.
- Brotli/HTTP/2/3: спросите поддержку у хостера и включите (или используйте Cloudflare).
- Настройки кэша в панели хостинга: некоторые shared‑провайдеры (включая Hostinger) дают опции для кеша на уровне сервера (напр. LiteSpeed cache). Включите, если доступно.
- Включите сжатие (у вас GZIP — поищите Brotli как более эффективный).
- Таймауты и memory_limit: увеличить PHP memory_limit и max_execution_time только если есть явные ошибки/ограничения — это не ускорит напрямую, но предотвратит падения.
4) Redis / Memcached — имеет ли смысл на shared?
- Что дают: объектный кэш (Redis/Memcached) уменьшает количество запросов к БД и ускоряет динамические операции (админка, авторизованные пользователи, сложные виджеты). Особенно полезно для сайтов с большим числом динамических запросов и плагинов.
- Ограничения на shared: многие shared‑хосты не дают доступ к системному Redis или дают как платную опцию. Если Redis/Memcached доступен у Hostinger в панели — стоит включить и настроить persistent object cache (плагин Redis Object Cache, W3TC, WP Rocket support).
- Но: Redis не решит проблему, если основной узкий груз — медленный PHP или перегруженная нода хостинга. Он помогает снизить нагрузку на БД, но если процесс PHP всё равно долго выполняется (медленные плагины, тяжелый запрос, большой theme), TTFB останется высоким.
- Итог по Redis/Memcached: если хост поддерживает — попробуйте (снимет нагрузку). Если нет — для их работы нужно выделенное окружение (VPS).
5) Оптимизация базы и WP‑конфигурация
- Почистите опции autoload: использование плагинов типа Query Monitor покажет, какие опции autoload занимают ресурсы. Удалите/оптимизируйте.
- Очистка транзиентов, оптимизация таблиц (WP‑Optimize, WP‑CLI mysqloptimize), индексирование.
- Уменьшите число запросов: отключите неиспользуемые виджеты, внешние шрифты и плагины.
- Ограничьте количество постов/виджетов на странице, lazyload для iframes.
6) Тема и конструктор страниц
- Если тема/пейдж‑билдер тяжёлые (Elementor + много виджетов) — подумайте о переходе на лёгкую theme (GeneratePress, Astra, Neve, block theme) или минимизацию использования билдера.
- Умный приём: собрать критическую страницу без билдера и сравнить TTFB/LCP.
7) Что можно проверить у хостера (Hostinger)
- Спросите поддержку: включён ли OPcache, поддержка Redis/Memcached, можно ли переключить на PHP‑FPM, есть ли LiteSpeed/Nginx, поддержка Brotli/HTTP/2/3.
- Узнайте, дают ли они server‑level cache (LSCache) и как правильно настроить ваш плагин кэширования с этим сервисом.
8) Когда переходить на VPS / другой хостинг
- Переход нужен, если:
- После всех оптимизаций TTFB остаётся высоким (время до первого байта > 500–800 ms постоянное) и это вызвано серверной нагрузкой;
- Нельзя включить необходимый серверный функционал (OPcache/Redis/PHP‑FPM/LSCache) на shared;
- Сайт растёт по трафику и нагрузке.
- На VPS/managed вы получите контроль: Nginx/Apache+PHP‑FPM, OPcache, Redis, Varnish/LiteSpeed, более быстрый диск (NVMe), возможность масштабирования и мониторинга. Это решает проблему TTFB радикально, но требует администрирования (или платить за managed).
9) План действий на ближайшие 7–14 дней (пошагово)
1. Снимите замер (GTmetrix, WebPageTest) — запишите TTFB и LCP.
2. Подключите Cloudflare (бесплатный), включите HTTP/2/3 и Brotli; проверьте изменения.
3. Убедитесь, что page cache у плагина активирован и действительно отдает HTML без PHP (проверьте заголовки x‑cache).
4. Включите preload для LCP‑изображения и defer/async для JS; повторный замер LCP.
5. Проверьте OPcache и переключение на актуальную PHP‑версию + PHP‑FPM (через панель или поддержку).
6. Проверьте Query Monitor: устраните 1–2 самых медленных плагина/запроса.
7. Если host поддерживает Redis/Memcached — включите и протестируйте (профилируйте до/после).
8. Если после всех шагов TTFB всё ещё высокий — обсудите с Hostinger причину (нода перегружена?) и рассмотрите миграцию на VPS/managed.
10) Инструменты и плагины, которые пригодятся
- Query Monitor, New Relic (если доступен)
- WP‑Optimize, WP‑Rocket (платный), LiteSpeed Cache (если сервер LiteSpeed), Autoptimize, Perfmatters, Asset CleanUp
- Redis Object Cache (если доступен Redis)
- WebPageTest, Lighthouse, GTmetrix, Curl, Chrome DevTools (Performance и Network)
Краткий вывод
- Самые быстрые выигрыши: CDN (Cloudflare), корректный page cache, preload LCP, defer JS, OPcache + актуальная PHP, убрать тяжёлую тему/плагины.
- Redis/Memcached полезны, но только если хост их поддерживает; они не заменят медленный PHP/перегруженный сервер.
- Если после всех оптимизаций TTFB остаётся высоким — переход на VPS/managed WP или на хостинг с серверным кэшем (LiteSpeed/NGINX) будет единственным надёжным решением.
Если хотите, могу:
- Проанализировать ваш сайт (нужна ссылка) и указать конкретные медленные ресурсы/скрипты/плагины.
- Подготовить пошаговую инструкцию по настройке Cloudflare + плагина кэширования для вашего сайта.