Снижаем 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. Аудит через полгода — контроль деградации.

Целевые значения TTFB по типам страниц

Мы гарантируем снижение TTFB до 500 мс на всех страницах и улучшение LCP на 30-50%. Клиенты экономят до 40% на хостинге за счёт кеширования, а инвестиции в оптимизацию окупаются за 3-6 месяцев. Свяжитесь с нами для бесплатного аудита вашего сайта. Получите консультацию по оптимизации TTFB — разберём ваш проект и предложим конкретные шаги.

Почему Core Web Vitals критичны для технического SEO

PageSpeed показывает 34/100 на мобильных. В Search Console — красные метрики по всем страницам категорий. Конкурент с сайтом на 3 года старше стоит выше в выдаче, несмотря на более слабые тексты. Техническая производительность стала прямым ранжирующим фактором — и разрыв между «приемлемо» и «быстро» стоит позиций. Мы решали эту проблему для десятков проектов — от интернет-магазинов до SaaS-платформ — и знаем, какие ошибки съедают ранжирование.

Core Web Vitals: что реально влияет на позиции

Google использует три метрики как сигналы ранжирования (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, заменил FID с последнего крупного обновления алгоритма).

LCP: почему 8 секунд — это не проблема изображения

LCP измеряет время отрисовки самого большого видимого элемента страницы. Чаще всего — hero image или H1. Пороги: хорошо < 2.5s, плохо > 4s.

Типичный диагноз на реальном проекте: интернет-магазин одежды, LCP 7.8s на мобильных. Элемент — hero image категории, 4.2MB JPEG без srcset, загружается через CSS background-image (не <img>). Проблема здесь двойная: во-первых, браузер не может preload CSS background images через <link rel="preload"> стандартным способом. Во-вторых, 4.2MB на мобильном соединении — это физически медленно.

Решение по шагам:

1. Переносим hero из CSS background в <img> с fetchpriority="high" и loading="eager"
2. Конвертируем в WebP, добавляем srcset: 800w для мобильных, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Убираем все render-blocking скрипты выше hero через defer

Итог: LCP 7.8s → 1.9s. Без смены хостинга, без CDN.

Если LCP — не изображение, а текстовый блок: проблема может быть в TTFB (медленный сервер), в render-blocking CSS/JS, или в web fonts с font-display: block.

CLS: смещения, которые раздражают пользователя и Google

CLS измеряет суммарный сдвиг элементов в процессе загрузки. Пороги: хорошо < 0.1, плохо > 0.25. CLS 0.35 — это баннер, который появляется через секунду и сдвигает всё содержимое страницы вниз.

Источники CLS:

• Изображения без заданных размеров. <img src="photo.jpg"> без width и height — браузер не резервирует место, контент прыгает при загрузке. Фикс: явные width/height или aspect-ratio в CSS.
• Рекламные блоки и виджеты. Google Ads, чат-виджеты, cookie consent — всё, что появляется после основного контента. Решение: резервировать место через min-height или загружать до рендера основного контента.
• Web fonts. FOUT (Flash of Unstyled Text) и FOIT (Flash of Invisible Text) могут вызывать переформатирование. font-display: swap с size-adjust (CSS свойство для выравнивания размеров fallback шрифта) минимизирует CLS.
• Динамический контент. Если блок появляется после загрузки (fetch данных, lazy load) — добавляем skeleton placeholder с нужными размерами.

INP: почему интерфейс «зависает» на 500ms

INP измеряет задержку ответа на любое взаимодействие пользователя: клик, тап, ввод. Пороги: хорошо < 200ms, плохо > 500ms. INP 680ms — это когда пользователь нажимает кнопку фильтра, а ничего не происходит полсекунды.

Главная причина высокого INP — заблокированный main thread. JavaScript-бандл 2.1MB парсируется и выполняется синхронно. Пока выполняется, пользовательские события не обрабатываются.

Диагностика через Chrome DevTools → Performance → взаимодействие с подозрительной задержкой → найти Long Tasks (> 50ms). Типичные виновники:

• Непрерывная обработка большого списка без requestIdleCallback или requestAnimationFrame
• Тяжёлые event listeners без debounce/throttle
• Синхронный setState в React, который триггерит полный ре-рендер сложного дерева компонентов
• Third-party scripts: livechat, аналитика, виджеты — они исполняются в том же main thread

Решения: code splitting через динамический import(), перенос тяжёлых вычислений в Web Workers, React.memo + useMemo для предотвращения лишних ре-рендеров, scheduler API для приоритизации задач.

Schema.org: разметка, которую читают роботы

Структурированные данные через JSON-LD — не прямой ранжирующий фактор, но дают rich snippets в выдаче (звёзды рейтингов, цены, дата публикации), что увеличивает CTR на 20–30%.

Типы разметки по сценариям:

• E-commerce: Product с offers (цена, наличие, валюта), aggregateRating (рейтинг из отзывов), brand. BreadcrumbList для навигации. ItemList для страниц категорий.
• Статьи и блог: Article или BlogPosting с author, datePublished, dateModified, image. Organization и WebSite на главной странице — помогают Google связать сайт с брендом.
• Локальный бизнес: LocalBusiness с address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage с mainEntity — вопросы и ответы могут появляться прямо в выдаче как раскрывающийся блок.

Валидация: Google Rich Results Test и Schema Markup Validator. Частая ошибка — указать price без priceCurrency, или ratingValue без reviewCount. Google игнорирует неполную разметку.

Как проводить технический SEO-аудит

Сканируемость. robots.txt блокирует нужные страницы (или наоборот, не блокирует служебные). Canonical URLs настроены неправильно — дублируются страницы с UTM-метками. Sitemap содержит страницы с noindex. Всё это Screaming Frog или Sitebulb покажут за час сканирования.

Core Web Vitals в масштабе. Google Search Console → Core Web Vitals → смотрим не отдельные страницы, а группы URL (шаблон страницы продукта, шаблон категории, блог). Проблема обычно системная — одна ошибка в шаблоне портит сотни страниц.

JavaScript SEO. Google рендерит JavaScript, но с задержкой (иногда дни для полного рендера). Для критичного контента — SSR или SSG обязательны. Проверяем через Search Console → Inspect URL → View Crawled Page: что видит Googlebot.

Internal linking. Орфанные страницы (нет входящих внутренних ссылок) теряют PageRank. Битые ссылки (404) — сигнал качества.

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

• Документация: отчёт с найденными проблемами, roadmap по приоритетам, тайминги для каждого этапа.
• Доступы: настройка мониторинга (SpeedCurve, Sentry Search Console), передача dashboard.
• Обучение: разбор типичных ошибок для вашей команды (1–2 созвона).
• Поддержка: сопровождение в течение месяца после деплоя — проверка метрик, фикс регрессий.

Свяжитесь с нами — мы оценим ваш проект за 2 дня и покажем, сколько позиций можно вернуть за счёт технического SEO. Опыт работы с проектами уровня сотен тысяч посещений в месяц — гарантируем измеримый результат в Core Web Vitals до/после. Закажите аудит в этой форме — получите персональный чек-лист из 15 пунктов.