Снижаем TTFB до 200 мс — кейсы и инструменты

Оптимизация TTFB: от 1.2 с до 150 мс за неделю

Недавно к нам обратился владелец интернет-магазина с жалобой на медленную загрузку — TTFB составлял 1.2 секунды на главной странице. После комплексного аудита мы внедрили full page cache, настроили Nginx FastCGI кеш, оптимизировали запросы к БД и подключили Redis. Результат: TTFB упал до 150 мс, LCP улучшился на 40%, а конверсия выросла на 12%. В этой статье разбираем, какие именно шаги привели к такому эффекту.

TTFB (Time to First Byte) — время от отправки запроса до получения первого байта ответа. Он складывается из DNS-резолва, установки соединения (TCP+TLS), отправки запроса, обработки на сервере и генерации ответа. Самая управляемая часть — серверная обработка. Именно её мы и оптимизируем. Согласно документации Google по Web Vitals, TTFB напрямую влияет на LCP и INP.

Почему TTFB критичен для Core Web Vitals?

Google использует TTFB как показатель первого отклика. Если сервер думает дольше 600 мс, даже идеальный фронтенд не спасёт LCP. Мы это видели на десятках проектов: снижение TTFB с 1 с до 200 мс улучшало LCP на 40%. Кроме того, медленный сервер задерживает обработку пользовательских запросов, ухудшая INP (Interaction to Next Paint).

Как диагностировать TTFB с помощью Chrome DevTools и WebPageTest?

• Chrome DevTools (вкладка Network): замеряем Waiting (TTFB) для каждого запроса. Фильтруем по типу document.
• WebPageTest: даёт детальный waterfall, показывающий DNS, TCP, TLS, первый байт. Указывает, сколько времени занял сервер.
• Lighthouse: общая оценка с рекомендациями.
• RUM-решения (Яндекс.Метрика, Google Analytics): показывают реальные значения TTFB для пользователей.

Мы всегда начинаем с RUM-данных, чтобы получить объективную картину.

Кеширование — главный инструмент

Full Page Cache на уровне приложения

Самый эффективный способ — кешировать готовый HTML для всех неавторизованных пользователей. Вот middleware для Laravel:

class FullPageCache { private const TTL = 300; // 5 минут public function handle(Request $request, Closure $next): Response { if (!$this->isCacheable($request)) { return $next($request); } $key = $this->cacheKey($request); if (Cache::has($key)) { return response(Cache::get($key)) ->header('X-Cache', 'HIT') ->header('Content-Type', 'text/html; charset=UTF-8'); } $response = $next($request); if ($response->getStatusCode() === 200) { Cache::put($key, $response->getContent(), self::TTL); } return $response->header('X-Cache', 'MISS'); } private function isCacheable(Request $request): bool { return $request->isMethod('GET') && !auth()->check() && !$request->hasCookie(session()->getName()); } private function cacheKey(Request $request): string { return 'fpc:' . sha1($request->fullUrl()); } } 

Такой подход даёт TTFB < 50 мс для закешированных страниц. Главное — правильно настроить инвалидацию при изменении контента. Мы используем события (Model events) для очистки кеша соответствующих URL.

Nginx FastCGI Cache — быстрее, чем PHP+Redis

Кеш на уровне nginx работает до генерации PHP, что даёт выигрыш ещё в 10-20 мс:

fastcgi_cache_path /var/cache/nginx/fcgi levels=1:2 keys_zone=LARAVEL:10m inactive=60m max_size=1g; fastcgi_cache_key "$scheme$request_method$host$request_uri"; server { location ~ \.php$ { fastcgi_cache LARAVEL; fastcgi_cache_valid 200 5m; fastcgi_cache_valid 404 1m; fastcgi_cache_bypass $cookie_laravel_session $http_authorization; fastcgi_no_cache $cookie_laravel_session $http_authorization; add_header X-Fastcgi-Cache $upstream_cache_status; fastcgi_pass unix:/run/php/php8.2-fpm.sock; } } 

Для инвалидации используем модуль ngx_cache_purge — отправляем PURGE-запрос на URL.

Оптимизация запросов к базе данных

Медленные запросы — вторая по частоте причина высокого TTFB. Типичная ошибка — N+1 problem:

// Медленно $products = Product::all(); foreach ($products as $product) { echo $product->category->name; } // Быстро $products = Product::with(['category', 'images', 'brand'])->get(); 

Мы профилируем все запросы через DB::listen и логируем те, что выполняются дольше 100 мс. Добавляем индексы, заменяем вложенные циклы на единые запросы с JOIN.

Redis для кеширования данных

Кешируем результаты частых запросов — дерево категорий, топ товаров, счётчики:

$categories = Cache::remember('categories:tree', 3600, function () { return Category::with('children')->whereNull('parent_id')->orderBy('sort_order')->get(); }); $stats = Cache::remember('product:stats:' . $productId, 300, function () use ($productId) { return [ 'views' => ProductView::where('product_id', $productId)->count(), 'sales' => OrderItem::where('product_id', $productId)->sum('quantity'), 'wishlist' => WishlistItem::where('product_id', $productId)->count(), ]; }); 

Прочие оптимизации

DNS и сеть

Используем <link rel="preconnect"> для сторонних ресурсов, чтобы сократить DNS+TCP время. Подключаем CDN (Cloudflare, Vercel) — они уменьшают задержку за счёт географически распределённых серверов.

OPcache для PHP

Настройки для продакшена:

opcache.enable=1 opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0 opcache.jit=tracing opcache.jit_buffer_size=64M 

JIT-компиляция ускоряет выполнение PHP-скриптов на 20-50%, что напрямую снижает TTFB.

Сравнение методов кеширования

Что входит в нашу работу

1. Аудит — замер TTFB на всех типах страниц, анализ структуры кеширования, профилирование БД.
2. Проектирование — выбор стратегии кеширования под конкретный стек.
3. Реализация — внедрение full page cache, nginx-кеша, оптимизация запросов, настройка Redis.
4. Тестирование — A/B-тесты до/после, проверка корректной инвалидации.
5. Документация — схема кеширования для команды разработки.
6. Аудит через полгода — контроль деградации.