• Опубликовано
  • 3 просмотра
  • 10 мин. чтения
  • 0 комментариев

Как уменьшить TTFB (время до первого байта) в 2026

TTFB, или время ответа сервера, — это та самая красная строчка «Сократите время ответа сервера» в PageSpeed. Пока она высокая, сайт грузится медленно, как ни сжимай картинки. Разобрали простыми словами: какой первый байт считается нормальным, как за минуту посмотреть его прямо в браузере и что включить в 2026, чтобы ускорить сайт, даже если вы не админ. Отдельный блок для WordPress.
Статью написал:
Ваня Буявец, продюсер, основатель Checkroi
Ваня Буявец
Основатель Checkroi, продюсер Telegram-каналов, эксперт в выборе онлайн-курсов
Все 421 статья автора
Одобрено экспертом:
Наташа Буявец, основатель Checkroi, эксперт по онлайн-курсам
Наташа Буявец
Основательница Checkroi, продюсер Youtube-каналов, эксперт по онлайн-курсам
Все 1084 экспертных мнения

Откройте отчёт 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 по шагам

Инструменты ускорения сайта: сервер, кеш, CDN и защищённое соединение в изометрии

Хорошая новость для тех, кто боится лезть в консоль сервера: большую часть пунктов ниже можно сделать без единой строчки кода, через панель хостинга или плагин. Идём от самого действенного к тонкой настройке.

Шаг 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 с нуля.

Курсы по 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 месяцевОбзор курса
Веб-разработчик
Перейти на сайт курса
SkillboxSkillbox152 760 ₽4486 ₽/мес.16 месяцевОбзор курса
FullStack-разработчик: тариф PRO
Перейти на сайт курса
Академия ЭдюсонЭдюсон182 000 ₽7583 ₽/мес.14 месяцевОбзор курса
Fullstack-разработчик на JavaScript
Перейти на сайт курса
Академия ЭдюсонЭдюсон158 760 ₽6615 ₽/мес.11 месяцевОбзор курса
Веб-разработка для фриланса
Перейти на сайт курса
SkyproSkypro118 320 ₽364 833 ₽/мес.12 месяцевОбзор курса
Фулстек-разработчик на JavaScript
Перейти на сайт курса
SkillboxSkillbox146 286 ₽4296 ₽/мес.11 месяцевОбзор курса
FullStack-разработчик: тариф Базовый
Перейти на сайт курса
Академия ЭдюсонЭдюсон158 760 ₽6615 ₽/мес.12 месяцевОбзор курса
Веб-разработчик (c индивидуальным сопровождением)
Перейти на сайт курса
SkyproSkypro204 000 ₽368 333 ₽/мес.12 месяцевОбзор курса

Больше программ — в полном каталоге курсов по веб-разработке

После курса такие отчёты PageSpeed перестают пугать: красная строка превращается в понятный список действий, а цифры скорости становятся управляемыми. А пока можно начать с нашего разбора технического аудита сайта и общей статьи про Core Web Vitals, где TTFB стоит в ряду с остальными показателями скорости.

Часто задаваемые вопросы

Что такое TTFB простыми словами?

TTFB (Time To First Byte, время до первого байта) — это пауза между тем, как браузер отправил запрос на сайт, и тем, как получил от сервера первый байт ответа. Пока этот байт не пришёл, страница на экране не начинает рисоваться, поэтому большой TTFB тормозит загрузку целиком.

Какой TTFB считается хорошим?

Хорошим считается ответ сервера до 0,8 секунды, а в идеале — до 200 миллисекунд (на эту планку ориентируется PageSpeed Insights). Значение больше 1,8 секунды — сигнал, что с серверной частью сайта что-то всерьёз не так.

Как проверить TTFB своего сайта?

Самый быстрый способ — Chrome DevTools: нажмите F12, откройте вкладку Network, обновите страницу, кликните по первому запросу с именем домена и посмотрите строку Waiting for server response во вкладке Timing. Для проверки из разных регионов удобнее онлайн-сервисы вроде PageSpeed Insights и WebPageTest.

Что значит Waiting (TTFB) в Chrome DevTools?

Это и есть время до первого байта — строка, которая показывает, сколько браузер ждал ответа сервера. В новых версиях Chrome её переименовали в Waiting for server response. Если эта полоса длинная, проблема в серверной части, а не в размере страницы.

Почему у сайта большой TTFB?

Чаще всего виноваты слабый или перегруженный хостинг, отсутствие кеширования, тяжёлый бэкенд с медленными запросами к базе данных, удалённость сервера от посетителей и лишние редиректы. Обычно причин несколько сразу — какая именно у вас, подскажет разбор тайминга в DevTools.

Влияет ли TTFB на SEO и позиции в поиске?

Да, косвенно. TTFB — фундамент скорости загрузки и часть метрики LCP, а скорость входит в Core Web Vitals, по которым Google и Яндекс оценивают сайт. Медленный ответ сервера ухудшает и ранжирование, и поведение посетителей.

Как уменьшить TTFB на WordPress?

Поставьте один плагин кеширования страниц, включите OPcache и обновите PHP до актуальной версии в панели хостинга. Для сайтов с нагрузкой добавьте Redis в роли кеша объектов — это срежет 60–80% обращений к базе данных. Всё это делается без программирования.

Помогает ли CDN снизить TTFB?

Да, если посетители географически далеко от вашего сервера. CDN отдаёт копию сайта с ближайшей к пользователю точки, и дорога запроса сокращается. По разным оценкам это снижает время ответа на 40–60% для удалённой аудитории.

Оставить комментарий
0 комментариев
Форма комментария

Оставьте комментарий

Напишите, что думаете. Нам важно ваше мнение!