Откройте отчёт PageSpeed Insights по своему сайту, и почти наверняка увидите красную строчку: «Сократите время ответа сервера». За этой формулировкой прячется метрика с тремя буквами: TTFB. Именно она часто отвечает за то, что страница «думает» секунду-другую, прежде чем на экране вообще что-то появится.
В этой статье разберём простыми словами, что такое TTFB, из чего он складывается, какой показатель считается нормальным, как посмотреть его прямо в браузере и как уменьшить: от смены хостинга до настройки кеша. Заодно покажем, где TTFB виден в Chrome DevTools и что делать владельцу сайта на WordPress. Если вам ближе полная картина по технике сайта, у нас есть отдельный разбор технического аудита, где TTFB стоит одной из проверяемых строк.
TTFB влияет на скорость загрузки страницы и косвенно на Core Web Vitals (набор показателей, по которым Google и Яндекс оценивают, насколько сайту приятно пользоваться). Что это за показатели и как измерять их целиком, мы собрали в большой статье про Core Web Vitals и скорость сайта. Здесь же говорим только про первый байт.
Материал для начинающих вебмастеров и владельцев сайтов. Если вы впервые слышите слова «бэкенд» или «кеш», ничего страшного: каждый термин поясняем по ходу, без занудства.
А если хочется разобраться в серверной части глубже и научиться чинить такие вещи руками, загляните в подборку курсов по веб-разработке: там программы от коротких интенсивов до годовых, с разбором серверов, баз данных и оптимизации.
КурсыСравнение 146 курсов по веб-разработкеЦены, школы, длительность, рассрочка
Что такое TTFB простыми словами
TTFB расшифровывается как Time to First Byte, дословно «время до первого байта». Это промежуток между моментом, когда браузер отправил запрос на сервер, и моментом, когда от сервера пришёл самый первый байт ответа.
Представьте, что вы звоните в справочную. Вы задали вопрос и ждёте. TTFB — это пауза от конца вашего вопроса до первого слова оператора. Оператор ещё ничего толком не сказал, но уже снял трубку и начал отвечать. Сколько он перед этим листал бумажки, столько и длится ваш «первый байт».
Важный момент, который часто упускают новички. В TTFB входит не только работа сервера, но и дорога запроса по сети туда и обратно. Поэтому даже быстрый сервер где-нибудь в США даст москвичу заметную задержку: данным физически нужно время, чтобы добежать через полмира и вернуться.
Пока браузер не получил первый байт, он не может начать рисовать страницу. Поэтому большой TTFB тормозит вообще всё, что идёт после: текст, картинки, скрипты послушно стоят в очереди. По этой же причине TTFB служит фундаментом для другой метрики скорости, LCP (момент, когда на экране появляется самый крупный блок). Ей мы посвятим отдельную статью в этом хабе.
Из чего складывается TTFB

Первый байт приходит не мгновенно. До него успевает произойти небольшая цепочка событий, и каждое звено добавляет миллисекунды. Когда браузер запрашивает страницу, по очереди случается вот что:
- Редиректы. Если адрес куда-то переадресуется (например, с http на https или со старого URL на новый), браузер сначала проходит все перенаправления. Каждый редирект добавляет лишний круг по сети.
- DNS-запрос. DNS (система, которая превращает имя сайта вроде checkroi.ru в числовой IP-адрес сервера) подсказывает браузеру, куда вообще стучаться.
- Соединение и TLS. Браузер устанавливает связь с сервером и договаривается о шифровании. TLS (он же SSL: протокол, который делает соединение защищённым, тот самый замочек в адресной строке) требует нескольких обменов сообщениями.
- Ожидание ответа сервера. Сервер принимает запрос, прогоняет код, лезет в базу данных, собирает HTML и отдаёт первый байт. Эту часть Chrome подписывает словом Waiting, и именно она обычно занимает больше всего времени.
Отдельная история — география сервера. Если ваши посетители живут по всей стране, а сервер стоит в одном городе, дорога до дальних регионов всегда будет длиннее. Эту проблему решает CDN (сеть серверов по всему миру, которая отдаёт копию сайта с ближайшей к пользователю точки). Подробно про него мы написали в статье что такое CDN и зачем он нужен.
Какой TTFB считается нормальным
Единого «правильного» числа нет, но есть ориентиры, на которые смотрят и поисковики, и сервисы проверки скорости. Вот они в удобном виде.
| Оценка | TTFB | Что это значит |
|---|---|---|
| Хорошо | до 0,8 с | Сервер отвечает шустро, тормозов на старте загрузки нет |
| Терпимо | 0,8–1,8 с | Работать можно, но есть что улучшать |
| Плохо | больше 1,8 с | Пользователь чувствует задержку, поисковик это видит |
PageSpeed Insights строже этих общих порогов: в своих рекомендациях он хочет видеть ответ сервера быстрее 200 мс и подсвечивает строчку «Сократите время ответа сервера», как только показатель уползает за эту планку. Гнаться за идеальными 200 мс на дешёвом хостинге тяжело, но удержать TTFB в пределах 0,5–0,8 с по силам почти любому сайту.
Сначала измерьте, потом чините. Один и тот же сайт может выдавать 200 мс для посетителя из Москвы и 1,5 с для посетителя из Владивостока. Прежде чем хвататься за настройки, проверьте TTFB из разных точек.
Как проверить и измерить TTFB
Узнать свой первый байт можно за минуту, причём прямо в браузере, без дополнительных программ. Самый наглядный способ — встроенные инструменты разработчика Chrome, или Chrome DevTools.
Откройте свой сайт в Chrome и нажмите F12. Перейдите на вкладку Network («Сеть») и обновите страницу. В списке запросов кликните по самому первому, который называется как ваш домен (это и есть HTML-документ страницы). Откройте вкладку Timing («Тайминг») и увидите разбивку:
- DNS Lookup: поиск IP-адреса по имени сайта.
- Initial Connection и SSL: установка соединения и шифрования.
- Waiting for server response: то самое ожидание ответа сервера. Раньше Chrome подписывал эту строку как Waiting (TTFB), так что если встретите формулировку «waiting ttfb», речь именно про неё.
- Content Download: загрузка тела ответа после первого байта.
Для диагностики первого байта вас интересует строка Waiting. Если она зелёная и короткая, сервер отвечает быстро. Если растянулась на секунду и больше, проблема в серверной части, и дальше по статье разберём, что с этим делать. Длинный Content Download означает уже другое: виновата тяжёлая страница, а не сервер.
Кроме DevTools есть и другие способы измерить TTFB. PageSpeed Insights покажет ответ сервера в блоке диагностики. WebPageTest и онлайн-сервисы проверки скорости умеют гонять тест из разных стран, что удобно для оценки географии. Для разовой быстрой проверки хватит и DevTools.
Почему TTFB большой

Если первый байт ждёт секунду и больше, причина почти всегда в одном из нескольких мест. Вот частые виновники, от самого распространённого к более редким.
Слабый или перегруженный хостинг. На дешёвом общем хостинге (когда на одной машине живут сотни чужих сайтов) ваш сайт делит процессор и память с соседями. Сосед словил наплыв трафика, а тормозите вы. Это причина номер один у новичков.
Нет кеширования. Кеш (заранее заготовленная копия готовой страницы) позволяет отдавать результат мгновенно. Без него сервер каждый раз собирает страницу с нуля: запускает код, лезет в базу, склеивает HTML. Для каждого посетителя заново.
Тяжёлый бэкенд. Бэкенд — это серверная часть сайта, всё, что работает на сервере и невидимо пользователю: код, обращения к базе данных, расчёты. Кривой запрос к базе или раздутый плагин легко добавляют полсекунды на каждый клик.
Нет CDN при широкой географии. Если аудитория размазана по стране или миру, а сервер один, дальние посетители всегда ждут дольше.
Медленный TLS и лишние редиректы. Старый протокол шифрования и цепочка переадресаций добавляют по кругу на каждом шаге. По отдельности немного, но в сумме чувствуется.
Таблица «причина TTFB → решение»
Чтобы не держать всё в голове, вот шпаргалка. Слева причина, которая замедляет первый байт, справа способ с ней справиться.
| Причина большого TTFB | Что делать |
|---|---|
| Дешёвый общий хостинг, сосед забирает ресурсы | Перейти на VPS или хостинг получше, выбрать сервер ближе к аудитории |
| Страница собирается заново для каждого посетителя | Включить кеширование страниц (на сервере или плагином) |
| Тяжёлые запросы к базе данных, лишние плагины | Почистить плагины, оптимизировать запросы, добавить кеш базы |
| Аудитория далеко от сервера | Подключить CDN |
| Старый TLS, нет HTTP/2 | Обновить сертификат и протокол на сервере |
| Длинные цепочки редиректов | Убрать лишние перенаправления, оставить максимум один |
Как уменьшить TTFB по шагам

Хорошая новость для тех, кто боится лезть в консоль сервера: большую часть пунктов ниже можно сделать без единой строчки кода, через панель хостинга или плагин. Идём от самого действенного к тонкой настройке.
Шаг 1 — нормальный хостинг
Это база, которую новички почему-то откладывают на потом. Если сайт лежит на самом дешёвом общем тарифе и стабильно тормозит, никакие плагины не спасут. Перейдите на VPS (виртуальный сервер, где ресурсы выделены лично вам) или выберите хостинг с хорошими отзывами по скорости. И смотрите на географию: сервер для российской аудитории логичнее держать в России.
Шаг 2 — кеширование
Самый быстрый выигрыш по соотношению «усилие к результату». Кеш страниц превращает работу так: первый посетитель генерирует страницу обычным образом, а все следующие получают уже готовый файл. Первый байт падает с 300–600 мс до 20–50 мс, и всё это без правок в коде.
Шаг 3 — CDN
Если посетители приходят из разных регионов, подключите CDN. Он раздаёт копию сайта с ближайшего к человеку сервера, и дорога данных сокращается. По разным оценкам, CDN снижает время ответа на 40–60 % для удалённой аудитории.
Шаг 4 — лёгкий TLS и современный протокол
Убедитесь, что сервер отдаёт сайт по HTTP/2 (современная версия протокола, которая работает быстрее старого HTTP/1.1) и использует свежий TLS. Обычно это включается одной галочкой в панели хостинга или одной строкой в настройках сервера.
Шаг 5 — база данных и код
Тяжёлый бэкенд разгружают с двух сторон. Сначала чистка: уберите плагины, которыми не пользуетесь, они всё равно отъедают ресурсы. Потом оптимизация запросов к базе данных и кеш на уровне базы, чтобы повторные запросы не считались каждый раз заново.
Шаг 6 — уберите лишние редиректы
Проверьте, не гоняет ли сайт посетителя по цепочке переадресаций (с www на без www, потом с http на https и так далее). Идеально, когда редирект максимум один. Каждый лишний прыжок добавляет круг по сети ещё до того, как сервер начал собирать страницу.
TTFB на WordPress
У WordPress первый байт часто оказывается большим: движок на каждый запрос запускает PHP (язык, на котором написан WordPress) и лезет в базу данных. Без настройки это медленно. Хорошая новость: разгоняется он тоже предсказуемо, и почти всё ставится плагинами. Если вы только собираете сайт, базовые шаги удобно держать под рукой вместе с нашим гайдом, как создать сайт на WordPress с нуля.
КурсыСравнение 21 курса по WordPressЦены, школы, длительность, рассрочка
Кеш-плагин. Первое, что стоит поставить. Плагин кеширования отдаёт готовый HTML вместо того, чтобы собирать страницу заново. Важное правило: держите только один кеш-плагин, два конфликтуют между собой и ломают сайт.
OPcache. Это модуль PHP, который хранит уже скомпилированный код в памяти сервера. Без него PHP заново разбирает каждый скрипт при каждом запросе. С ним TTFB нередко падает вдвое сам по себе, и обычно OPcache просто включается в настройках хостинга.
Redis или Memcached для кеша объектов. Object cache (кеш объектов) хранит результаты запросов к базе в оперативной памяти. Redis — это быстрая база данных, которая живёт в памяти и идеально подходит на роль такого кеша. Правильно настроенный object cache сокращает число обращений к базе на 60–80 % для типового сайта.
Веб-сервер. Связка nginx (быстрый веб-сервер, который умеет отдавать готовые файлы напрямую) перед PHP работает заметно резвее, чем один классический Apache. На нормальном хостинге это обычно уже настроено, но проверить стоит.
Не ставьте всё разом. Сначала включите кеш-плагин и OPcache, измерьте TTFB. Если первого байта всё ещё много, добавляйте Redis и CDN. Так вы поймёте, что именно дало результат, а что было лишним.
Чек-лист «проверь TTFB за 10 минут»

Короткий маршрут, который пройдёт даже тот, кто открыл DevTools впервые сегодня:
- Открыли сайт в Chrome, нажали F12, вкладка Network, обновили страницу.
- Кликнули по первому запросу с именем домена, открыли Timing.
- Посмотрели на строку Waiting for server response. До 0,8 с можно выдохнуть, больше 1,8 с пора чинить.
- Проверили, включён ли кеш страниц (на WordPress — стоит ли кеш-плагин).
- Уточнили у хостинга, включены ли OPcache и HTTP/2.
- Прогнали сайт в PageSpeed Insights и проверили, ушла ли строчка «Сократите время ответа сервера».
- Если аудитория из разных регионов, прикинули, не пора ли подключать CDN.
Где научиться серверной части
Уменьшить TTFB на готовом сайте можно галочками в панели. Но если хочется понимать, что происходит под капотом, и уметь чинить не только первый байт, без базы по серверам, базам данных и протоколам не обойтись. Это и есть веб-разработка.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Fullstack-разработчик на Python Перейти на сайт курса | 175 800 ₽ | 7125 ₽/мес. | 21 месяц | Обзор курса | |
| Профессия «Веб-разработчик с нуля» Перейти на сайт курса | 163 300 ₽ | 7125 ₽/мес. | 13 месяцев | Обзор курса | |
| Веб-разработчик Перейти на сайт курса | 141 036 ₽ | 5877 ₽/мес. | 6 месяцев | Обзор курса | |
| Веб-разработчик Перейти на сайт курса | 152 760 ₽ | 4486 ₽/мес. | 16 месяцев | Обзор курса | |
| FullStack-разработчик: тариф PRO Перейти на сайт курса | 182 000 ₽ | 7583 ₽/мес. | 14 месяцев | Обзор курса | |
| Fullstack-разработчик на JavaScript Перейти на сайт курса | 158 760 ₽ | 6615 ₽/мес. | 11 месяцев | Обзор курса | |
| Веб-разработка для фриланса Перейти на сайт курса | 118 320 ₽ | 364 833 ₽/мес. | 12 месяцев | Обзор курса | |
| Фулстек-разработчик на JavaScript Перейти на сайт курса | 146 286 ₽ | 4296 ₽/мес. | 11 месяцев | Обзор курса | |
| FullStack-разработчик: тариф Базовый Перейти на сайт курса | 158 760 ₽ | 6615 ₽/мес. | 12 месяцев | Обзор курса | |
| Веб-разработчик (c индивидуальным сопровождением) Перейти на сайт курса | 204 000 ₽ | 368 333 ₽/мес. | 12 месяцев | Обзор курса |
Больше программ — в полном каталоге курсов по веб-разработке
После курса такие отчёты PageSpeed перестают пугать: красная строка превращается в понятный список действий, а цифры скорости становятся управляемыми. А пока можно начать с нашего разбора технического аудита сайта и общей статьи про Core Web Vitals, где TTFB стоит в ряду с остальными показателями скорости.
![Статья: Как ускорить сайт и улучшить Core Web Vitals в 2026 Обложка: Как ускорить сайт и улучшить Core Web Vitals в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77863-1781090788.webp)



