Узнайте, как оптимизировать показатель Time to First Byte.
Дата публикации: 19 января 2023 г. Последнее обновление: 28 ноября 2025 г.
Время до получения первого байта (TTFB) – это базовый показатель эффективности сайта, который предшествует всем остальным показателям удобства для пользователей, таким как первая отрисовка контента (FCP) и отрисовка самого крупного контента (LCP). Это означает, что высокие значения TTFB увеличивают время для последующих показателей.
Рекомендуется, чтобы сервер отвечал на запросы навигации достаточно быстро, чтобы у 75 % пользователей показатель FCP не превышал пороговое значение. В большинстве случаев рекомендуется стремиться к тому, чтобы время до получения первого байта составляло не более 0,8 секунды.
Как измерить TTFB
Прежде чем оптимизировать TTFB, нужно понять, как этот показатель влияет на пользователей сайта. В качестве основного источника информации о TTFB следует использовать данные наблюдений, поскольку на этот показатель влияют переадресации, а инструменты для лабораторных данных часто выполняют измерения с использованием конечного URL, поэтому не учитывают эту дополнительную задержку.
PageSpeed Insights – это один из способов получить как полевые, так и лабораторные данные для общедоступных сайтов, которые есть в отчете Chrome User Experience Report.
Показатель TTFB для реальных пользователей приведен в разделе Узнайте, что видят пользователи:
В лабораторных данных проблемы с TTFB показаны в разделе Статистика задержки при запросе документа:
Дополнительную информацию о том, как измерять TTFB в полевых и лабораторных условиях, можно найти на странице, посвященной этому показателю.
Различия между полевыми и лабораторными данными о TTFB
Лабораторные и полевые значения TTFB могут различаться по ряду причин. В таких случаях важно понимать, почему это происходит, чтобы эффективно использовать лабораторные данные для улучшения взаимодействия с пользователем.
Если лабораторное значение TTFB намного больше, чем полевое, это указывает на то, что лабораторная среда более ограничена, чем типичный пользовательский опыт. Это не обязательно проблема, поскольку результаты и рекомендации все равно будут действительными, но влияние и улучшение могут быть преувеличены.
Если полевое значение TTFB намного больше лабораторного, это указывает на проблемы, которые не проявляются в лабораторных условиях, например использование кеширования на стороне сервера, переадресации или различия в сети. В этом случае результаты и рекомендации могут быть менее полезными, поскольку они не учитывают одну из основных проблем.
Чтобы узнать, влияет ли кеширование на стороне сервера на лабораторный показатель TTFB, попробуйте протестировать менее популярные страницы или использовать другие параметры URL, чтобы получить некешированный контент. Это позволит понять, насколько лабораторный показатель TTFB соответствует полевому. Также может быть полезно иметь возможность обходить кеширование на стороне сервера с помощью определенного параметра URL. Подробнее о кешированном контенте…
Чтобы выявить проблемы с переадресацией и различиями в сетях, можно проанализировать, как трафик поступает на сайт и откуда.
Как отлаживать высокий показатель TTFB в полевых условиях с помощью Server-Timing
Заголовок ответа Server-Timing можно использовать в серверной части приложения, чтобы измерять отдельные процессы, которые могут приводить к высокой задержке. Структура значения заголовка может быть разной, но должна содержать как минимум определенный вами дескриптор. Необязательные значения включают значение продолжительности (через dur), а также необязательное человекочитаемое описание (через desc).
Serving-Timing можно использовать для измерения многих внутренних процессов приложения, но есть некоторые, на которые стоит обратить особое внимание:
- Запросы к базам данных
- Время отрисовки на стороне сервера (если применимо).
- Поиск по диску
- совпадения или несовпадения в кеше пограничного сервера (при использовании CDN);
Все части записи Server-Timing разделяются двоеточием, а несколько записей можно разделить запятой:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
Заголовок можно задать на языке, который используется в серверной части приложения. Например, в PHP заголовок можно задать следующим образом:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Если этот заголовок задан, он предоставляет информацию, которую можно использовать как в лабораторных, так и в полевых условиях.
В поле любая страница с заданным заголовком ответа Server-Timing заполняет свойство serverTiming в Navigation Timing API:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
В лабораторных условиях данные из заголовка ответа Server-Timing визуализируются на панели Timings (Временные метки) вкладки Network (Сеть) в инструментах разработчика Chrome.
В данном случае Server-Timing используется, чтобы определить, попал ли запрос ресурса в кеш CDN, и сколько времени требуется запросу, чтобы достичь пограничного сервера CDN, а затем источника.
Временные показатели сервера также отображаются на дорожке "Сеть" на панели Производительность в инструментах разработчика Chrome:
Если вы проанализировали доступные данные и обнаружили, что у вас есть проблемы с TTFB, то можете перейти к их устранению.
Как оптимизировать TTFB
Самый сложный аспект оптимизации TTFB заключается в том, что, хотя стек внешнего интерфейса всегда состоит из HTML, CSS и JavaScript, стеки внутреннего интерфейса могут значительно различаться. Существует множество серверных стеков и продуктов баз данных, каждый из которых имеет свои собственные методы оптимизации. Поэтому в этом руководстве мы сосредоточимся на том, что применимо к большинству архитектур, а не только к конкретным стекам.
Рекомендации для разных платформ
Платформа, на которой размещен ваш сайт, может сильно влиять на TTFB. Например, на производительность WordPress влияет количество и качество плагинов, а также используемые темы. Другие платформы также затронуты, если они настроены. Рекомендуем ознакомиться с документацией по вашей платформе, чтобы получить дополнительные советы по повышению производительности. В подсказках Lighthouse также есть рекомендации для конкретных платформ.
Хостинг, хостинг, хостинг
Прежде чем рассматривать другие подходы к оптимизации, следует обратить внимание на хостинг. В этом случае сложно дать конкретные рекомендации, но общее правило таково: убедитесь, что хостинг вашего сайта способен справиться с трафиком, который вы на него направляете.
Общий хостинг обычно работает медленнее. Если у вас небольшой личный сайт, на котором размещены в основном статические файлы, то, скорее всего, этого будет достаточно. Ниже приведены некоторые методы оптимизации, которые помогут вам максимально сократить TTFB.
Однако если вы запускаете более крупное приложение с большим количеством пользователей, которое включает персонализацию, запросы к базе данных и другие интенсивные операции на стороне сервера, ваш выбор хостинга становится критически важным для снижения TTFB в полевых условиях.
При выборе хостинг-провайдера обратите внимание на следующее:
- Сколько памяти выделено для экземпляра приложения? Если у приложения недостаточно памяти, оно будет работать медленно и не сможет быстро загружать страницы.
- Обновляет ли хостинг-провайдер стек бэкенда? По мере выпуска новых версий языков серверной части приложений, реализаций HTTP и программного обеспечения баз данных производительность этого программного обеспечения со временем повышается. Поэтому важно выбрать хостинг-провайдера, который уделяет должное внимание обслуживанию.
- Если у вас есть особые требования к приложению и вы хотите получить доступ к файлам конфигурации сервера на самом низком уровне, спросите, имеет ли смысл настраивать серверную часть вашего собственного экземпляра приложения.
Многие хостинг-провайдеры берут на себя решение этих проблем, но если вы наблюдаете высокие значения TTFB даже у выделенных хостинг-провайдеров, это может быть признаком того, что вам нужно пересмотреть возможности текущего хостинг-провайдера, чтобы обеспечить наилучшее взаимодействие с пользователем.
Используйте сеть доставки контента (CDN)
Тема использования CDN уже избита, но не без причины: у вас может быть очень хорошо оптимизированный бэкенд приложения, но пользователи, находящиеся далеко от вашего сервера-источника, все равно могут сталкиваться с высоким TTFB.
Сети доставки контента решают проблему удаленности пользователей от вашего сервера-источника, используя распределенную сеть серверов, которые кешируют ресурсы на серверах, физически расположенных ближе к вашим пользователям. Такие серверы называются пограничными.
Поставщики CDN могут предлагать и другие преимущества, помимо пограничных серверов:
- Поставщики CDN обычно предлагают очень быстрое DNS-преобразование.
- CDN, скорее всего, передает ваш контент с пограничных серверов, используя современные протоколы, такие как HTTP/2 или HTTP/3.
- В частности, HTTP/3 решает проблему блокировки начала очереди, которая возникает в TCP (на котором основан HTTP/2), за счет использования протокола UDP.
- Сети доставки контента обычно поддерживают современные версии TLS, что позволяет снизить задержку при согласовании TLS. В частности, TLS 1.3 разработан так, чтобы согласование TLS было как можно короче.
- Некоторые поставщики CDN предлагают функцию, которая часто называется "пограничный обработчик". Она использует API, похожий на Service Worker API, чтобы перехватывать запросы, программно управлять ответами в пограничных кешах или полностью перезаписывать ответы.
- Поставщики CDN отлично справляются с оптимизацией сжатия. Сжатие – сложный процесс, и при неправильной настройке он может привести к увеличению времени ответа в некоторых случаях с динамически генерируемой разметкой, которую необходимо сжимать на лету.
- Кроме того, поставщики CDN автоматически кешируют сжатые ответы для статических ресурсов, что позволяет достичь оптимального соотношения между степенью сжатия и временем отклика.
Если вы ещё не используете CDN, то вам стоит уделить этому особое внимание, поскольку это один из самых эффективных способов оптимизации TTFB.
По возможности используйте кешированный контент
Сети доставки контента позволяют кешировать контент на пограничных серверах, которые физически расположены ближе к посетителям, при условии, что контент настроен с соответствующими HTTP-заголовками Cache-Control. Это не подходит для персонализированного контента, но необходимость возвращаться к источнику может свести на нет большую часть преимуществ CDN.
Для сайтов, контент которых часто обновляется, даже короткое время кеширования может привести к заметному повышению производительности, поскольку только первый посетитель за это время сталкивается с полной задержкой при обращении к серверу-источнику, в то время как все остальные посетители могут повторно использовать кешированный ресурс с пограничного сервера. Некоторые сети доставки контента позволяют аннулировать кеш при выпуске сайта, что дает возможность использовать как длительное время кеширования, так и мгновенные обновления при необходимости.
Даже если кеширование настроено правильно, его можно игнорировать, используя уникальные параметры строки запроса для аналитических измерений. В результате сеть доставки контента может не распознать, что это один и тот же контент, и не использовать кешированную версию.
Старый или редко посещаемый контент также может не кешироваться, что может привести к более высоким значениям TTFB на некоторых страницах по сравнению с другими. Увеличение времени кеширования может снизить влияние этой проблемы, но имейте в виду, что при этом повышается вероятность показа потенциально устаревшего контента.
Кеширование контента влияет не только на тех, кто использует CDN. Если кешированный контент нельзя использовать повторно, серверной инфраструктуре может потребоваться генерировать контент на основе дорогостоящих поисков в базе данных. Данные, к которым обращаются чаще, или предварительно кешированные страницы часто работают лучше.
Избегайте многократных переадресаций страниц
Одна из распространенных причин высокого значения TTFB – переадресация. Переадресация происходит, когда в ответ на запрос навигации по документу браузер получает сообщение о том, что ресурс находится в другом месте. Одно перенаправление может добавить нежелательную задержку к запросу навигации, но ситуация может ухудшиться, если это перенаправление указывает на другой ресурс, что приводит к другому перенаправлению и так далее. Это может повлиять на сайты, которые получают большой объем трафика от рекламы или новостных рассылок, поскольку они часто перенаправляют пользователей через аналитические сервисы для сбора статистики. Чтобы улучшить показатель TTFB, удалите переадресации, которыми вы управляете.
Существует два типа переадресации:
- Переадресация в пределах одного источника, когда переадресация происходит полностью на вашем сайте.
- Перекрестные переадресации, когда переадресация сначала происходит на другой источник (например, из сервиса сокращения URL в социальных сетях), а затем – на ваш сайт.
Сосредоточьтесь на устранении переадресаций в пределах одного источника, поскольку вы можете напрямую управлять этим процессом. Проверьте, не возвращают ли ссылки на вашем сайте код ответа 302 или 301. Часто это происходит из-за того, что в URL не указана схема https:// (поэтому браузеры по умолчанию используют http://, а затем перенаправляют на нужный адрес) или в URL не включены или не исключены косые черты в конце.
Перекрестные переадресации сложнее, поскольку они часто находятся вне вашего контроля, но старайтесь избегать нескольких переадресаций, где это возможно, например, используя несколько сокращателей ссылок при обмене ссылками. Убедитесь, что URL, предоставленный рекламодателям или новостным рассылкам, является правильным конечным URL, чтобы не добавлять ещё одно перенаправление к тем, которые используются этими сервисами.
Ещё одним важным источником времени переадресации может быть переадресация с HTTP на HTTPS. Один из способов обойти это ограничение – использовать заголовок Strict-Transport-Security (HSTS), который обеспечивает применение HTTPS при первом посещении источника, а затем сообщает браузеру, что при последующих посещениях нужно сразу обращаться к источнику по протоколу HTTPS.
После того как вы настроите правила HSTS, вы можете ускорить загрузку сайта при первом посещении, добавив его в список предварительной загрузки HSTS.
Передача разметки в браузер
Браузеры оптимизированы для эффективной обработки разметки, когда она передается в потоковом режиме, то есть разметка обрабатывается фрагментами по мере ее поступления с сервера. Это особенно важно, когда речь идет о больших объемах разметки, поскольку браузер может анализировать фрагменты разметки постепенно, а не ждать, пока придет весь ответ, прежде чем можно будет начать анализ.
Хотя браузеры отлично справляются с потоковой разметкой, крайне важно сделать все возможное, чтобы поддерживать этот поток, чтобы эти начальные биты разметки были на пути как можно скорее. Если серверная часть задерживает работу, это проблема. Поскольку существует множество стеков бэкенда, мы не можем рассмотреть каждый из них и проблемы, которые могут возникнуть в каждом конкретном случае.
React и другие фреймворки, которые могут создавать разметку на сервере по запросу, используют синхронный подход к обработке на стороне сервера. Однако в более новых версиях React реализованы серверные методы для потоковой передачи разметки по мере ее отрисовки. Это означает, что вам не нужно ждать, пока метод API сервера React отобразит весь ответ, прежде чем он будет отправлен.
Ещё один способ обеспечить быструю передачу разметки в браузер – использовать статическую отрисовку, при которой HTML-файлы создаются во время сборки. Если файл доступен сразу, веб-серверы могут начать его отправку немедленно, а особенности протокола HTTP позволяют передавать разметку в потоковом режиме. Такой подход подходит не для всех страниц на всех сайтах (например, он не подходит для страниц, требующих динамического ответа в рамках взаимодействия с пользователем), но он может быть полезен для тех страниц, разметка которых не требует персонализации для конкретного пользователя.
Используйте сервис-воркер
Service Worker API может значительно влиять на TTFB как для документов, так и для загружаемых ими ресурсов. Это связано с тем, что сервисный работник действует как прокси-сервер между браузером и сервером, но влияет ли это на TTFB вашего сайта, зависит от того, как вы настроили сервисного работника и соответствует ли эта настройка требованиям вашего приложения.
- Используйте для объектов стратегию stale-while-revalidate. Если объект (документ или ресурс, необходимый для документа) находится в кеше сервисного работника, стратегия stale-while-revalidate обслуживает этот ресурс из кеша в первую очередь, а затем скачивает этот объект в фоновом режиме и обслуживает его из кеша для будущих взаимодействий.
- Если у вас есть ресурсы документов, которые меняются не очень часто, использование стратегии stale-while-revalidate может сделать TTFB страницы почти мгновенным. Однако это не всегда работает, если ваш сайт отправляет динамически созданную разметку, например разметку, которая меняется в зависимости от того, прошел ли пользователь аутентификацию. В таких случаях всегда нужно сначала обращаться к сети, чтобы документ был как можно более свежим.
- Если ваш документ загружает некритичные ресурсы, которые часто меняются, но получение устаревшего ресурса не сильно повлияет на удобство использования (например, некоторые изображения или другие некритичные ресурсы), TTFB для этих ресурсов можно значительно сократить с помощью стратегии stale-while-revalidate.
- Используйте модель оболочки приложения для приложений, отрисовываемых на стороне клиента. Эта модель лучше всего подходит для одностраничных приложений, в которых "оболочка" страницы может быть мгновенно доставлена из кеша скрипта service worker, а динамический контент страницы заполняется и отображается позже в жизненном цикле страницы.
Используйте 103 Early Hints для ресурсов, критически важных для отрисовки
Независимо от того, насколько хорошо оптимизирован бэкэнд вашего приложения, серверу все равно может потребоваться выполнить значительный объем работы для подготовки ответа, включая дорогостоящую (но необходимую) работу с базой данных, которая задерживает поступление ответа навигации так быстро, как это возможно. В результате может задерживаться загрузка некоторых ресурсов, критически важных для отрисовки, например CSS или, в некоторых случаях, JavaScript, который отрисовывает разметку на стороне клиента.
Заголовок 103 Early Hints – это код раннего ответа, который сервер может отправить браузеру, пока серверная часть занята подготовкой разметки. Этот заголовок может использоваться, чтобы сообщить браузеру, что на странице есть критически важные для отрисовки ресурсы, которые нужно начать скачивать, пока готовится разметка. В поддерживаемых браузерах это может ускорить отрисовку документов (CSS) и загрузку страниц.
Один из недостатков 103 Early Hints заключается в том, что, как и кеширование, они могут маскировать "реальное" значение TTFB сайта. Если инфраструктура сервера работает медленно (из-за недостаточной мощности или необходимости оптимизировать код), это может быть не так очевидно при использовании 103 Early Hints, поскольку TTFB кажется быстрым. Если на сайте используется код 103 Early Hints, рекомендуется измерять фактическое время ответа сервера (с помощью Server-Timing или finalResponseHeadersStart в PerformanceNavigationTiming API).
Заключение
Поскольку существует множество комбинаций стеков серверных приложений, нет ни одной статьи, в которой можно было бы описать все, что вы можете сделать, чтобы снизить TTFB вашего сайта. Однако вы можете попробовать ускорить работу сервера.
Как и в случае с другими показателями, подход к оптимизации TTFB в целом одинаков: измерьте TTFB в полевых условиях, используйте лабораторные инструменты, чтобы выявить причины, а затем примените оптимизацию, где это возможно. Некоторые из них могут не подойти для вашей ситуации, но другие, скорее всего, будут полезны. Как и всегда, вам нужно будет внимательно следить за полевыми данными и вносить необходимые корректировки, чтобы обеспечить максимально быструю работу сайта для пользователей.