Какие способы оптимизации time to first byte существуют

Что проверяют

Понимаете ли вы, из чего складывается TTFB, и отличаете ли серверную задержку от скорости загрузки страницы целиком. Следом обычно спрашивают, как вы нашли, где именно теряется время.

Как отвечать

TTFB это время от начала навигации до первого байта ответа: редиректы, DNS, TCP и TLS, дорога до сервера и работа приложения. По рекомендации web.dev хорошим считается значение до 0,8 с. Начните с замера: curl -w "%{time_starttransfer}", вкладка Network в DevTools, заголовок Server-Timing и трейсинг OpenTelemetry на сервере.

Дальше меры по слоям:

• сеть: CDN ближе к пользователю, TLS 1.3 и HTTP/3 на краю, никаких цепочек редиректов вроде http, затем www, затем слеш;
• кэш: целые страницы на CDN с s-maxage и stale-while-revalidate, данные в памяти процесса или в Redis. Лучший TTFB у ответа, который не доходит до Node;
• event loop: никакого синхронного кода в горячем пути: fs.readFileSync, crypto.pbkdf2Sync, JSON.parse на мегабайтах. Задержку цикла показывает monitorEventLoopDelay из perf_hooks, тяжёлое уносят в worker_threads;
• ввод-вывод: независимые запросы через Promise.all, пул соединений к базе, keep-alive к апстримам. С Node 19 глобальный HTTP-агент держит keep-alive по умолчанию;
• ранняя отдача: потоковый SSR (renderToPipeableStream в React) отправляет <head> сразу, а res.writeEarlyHints() шлёт 103 Early Hints, чтобы браузер начал грузить CSS до готовности ответа;
• масштаб: несколько процессов через cluster или реплики за балансировщиком, в serverless борьба с холодным стартом.

Где спотыкаются

Советуют склеивать JS и CSS и собирать спрайты. Это ускоряет загрузку ресурсов, но на TTFB документа не влияет.

Оптимизируют вслепую, не разложив время по этапам. Часто основное время съедает медленный запрос в базу или внешний API, а не сам Node.

Кладут в общий кэш CDN персональные ответы или отдают поток с быстрым первым байтом и пустым <head>. Метрика улучшается, а пользователь всё равно ждёт основной контент.