TTFB больше 800мс

Симптом

• В Lighthouse / WebPageTest: TTFB > 800ms (норма — < 200ms).
• В аудите по чеклисту — пункт «Время ответа сервера ≤ 800 мс» в красном.
• LCP плохой, но картинки не виноваты.

Причина

1. Сервер медленный — слабый shared-хостинг, не хватает CPU/RAM.
2. Тяжёлые SQL-запросы при сборке страницы (N+1, отсутствие индексов).
3. Нет кеширования — каждый запрос пересобирается с нуля.
4. Удалённый CDN или DB — большой round-trip от сервера.
5. Слишком много external API при сборке страницы.

Как проверить

# Время от запроса до первого байта
curl -w "\nTTFB: %{time_starttransfer}s\n" -o /dev/null -s https://domain.ru/

Либо в Chrome DevTools → Network → ваш HTML → Timing → Waiting (TTFB).

Решение

Уровень кеширования (быстро)

1. Включить server-side кеш страницы (Varnish / nginx fastcgi_cache / плагины WP типа WP Rocket).
2. CDN с edge-кешем — Cloudflare, BunnyCDN. Ставит копию HTML на ближайший к пользователю POP.
3. Browser cache — Cache-Control: public, max-age=3600 на статику.

Уровень БД

1. Включить лог медленных запросов (slow_query_log в MySQL).
2. Добавить индексы на колонки в WHERE и ORDER BY.
3. Отказаться от N+1 через eager loading (SELECT ... JOIN ...).
4. Кешировать выборки в Redis / memcached.

Уровень хостинга

1. Перейти с shared-хостинга на VDS с гарантированным CPU.
2. HTTP/2 или HTTP/3 на сервере.
3. Локальная БД (на том же сервере, не remote-MySQL).
4. PHP-FPM 8.x / Node.js LTS — современные версии быстрее.

Цели

• TTFB < 200ms — отлично, плюс к ранжированию.
• TTFB 200–600ms — нормально, не штрафует.
• TTFB 600–1500ms — постепенное снижение позиций.
• TTFB > 1500ms — почти гарантированный фильтр по производительности.

Связанные

• LCP > 2.5 секунд