Повышаем эффективность времени ожидания первого байта

Время до первого байта (TTFB) является основным показателем веб-производительности, предшествующим другим важным метрикам взаимодействия с пользователем, таким как первая отрисовка контента (FCP) и наибольшая отрисовка контента (LCP). Это означает, что высокие значения TTFB могут увеличивать время выполнения последующих метрик.

Рекомендуется, чтобы ваш сервер оперативно реагировал на запросы навигации, чтобы у 75-го процентиля пользователей FCP оставался в пределах «хорошего» порога. Грубо говоря, для большинства сайтов желательно, чтобы значение TTFB составляло 0,8 секунды или меньше.

Как измерить TTFB

Перед тем как начать оптимизировать TTFB, важно наблюдать, как это воздействует на пользователей вашего сайта. Рекомендуется ориентироваться на полевые данные в качестве основного источника мониторинга TTFB, поскольку они учитывают перенаправления, в то время как лабораторные инструменты часто измеряются с использованием конечного URL-адреса, и, таким образом, не учитывают возможные дополнительные задержки.

Инструмент PageSpeed Insights предоставляет простой способ получения как полевых, так и лабораторных данных для широко доступных веб-сайтов, доступных в отчете об опыте пользователей Chrome.

Информация о TTFB для реальных пользователей отображается в верхнем разделе «Узнайте, что испытывают ваши реальные пользователи».

Подмножество TTFB показано в аудите времени ответа сервера

Аудит времени ответа сервера в Lighthouse исключает время поиска DNS и перенаправления, поэтому он представляет собой только подмножество TTFB. Большая разница между реальными пользовательскими данными и данными Lighthouse может указывать на проблемы, не очевидные во время лабораторных испытаний, такие как перенаправления или различия в сети.

Понимание высокого TTFB с помощью Server-Timing

Использование заголовка ответа Server-Timing в серверной части вашего приложения позволяет измерять отдельные серверные процессы, которые могут привести к высокой задержке. Структура значения заголовка гибка и может включать, по меньшей мере, определяемый вами дескриптор. Дополнительные необязательные значения могут включать продолжительность (через dur) и удобочитаемое описание (через desc).

Serving-Timing предоставляет возможность измерять множество серверных процессов приложения, при этом следует уделить особое внимание следующим аспектам:

• Запросы к базе данных.
• Время рендеринга на стороне сервера, если это применимо.
• Дисковые операции поиска.
• Попадания и промахи кеша на граничных серверах (при использовании CDN).

Все части записи Server-Timing разделяются двоеточием, и несколько записей могут быть разделены запятой:

// Две метрики с описаниями и значениями
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

Заголовок можно настроить, используя язык серверной части вашего приложения. Например, в PHP вы можете установить заголовок так:

<?php
// Получаем временную метку перед
// выполнением запроса к базе данных:
$dbReadStartTime = hrtime(true);

// Выполняем запрос к базе данных и получаем результат...
// ...

// Получаем временную метку после
// выполнения запроса к базе данных:
$dbReadEndTime = hrtime(true);

// Получаем общее время, конвертируя наносекунды
// в миллисекунды (или с любой степенью детализации, которая вам нужна):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;

// Устанавливаем заголовок Server-Timing:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

Если этот заголовок установлен, он будет отображать информацию, которую вы можете использовать как в лаборатории , так и в полевых условиях .

В этом поле любая страница с набором заголовков ответа Server-Timing будет заполнять свойство serverTiming в API синхронизации навигации:

// Получаем запись serverTiming для первого запроса навигации:
performance.getEntries("navigation")[0].serverTiming.forEach(entry => {
    // Регистрируем данные синхронизации сервера:
    console.log(entry.name, entry.description, entry.duration);
});

В лабораторной работе данные из заголовка ответа Server-Timing будут визуализированы на панели таймингов вкладки «Сеть» в Chrome DevTools:

Заголовки ответов Server-Timing отображаются на вкладке «Сеть» инструментов Chrome DevTools. В данном случае Server-Timing используется для измерения того, попал ли запрос на ресурс в кэш CDN, а также для определения времени, требуемого для достижения запроса пограничного сервера CDN и источника.

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

Способы оптимизации TTFB

Наиболее сложным аспектом оптимизации TTFB является то, что, несмотря на то, что стек веб-интерфейса всегда будет состоять из HTML, CSS и JavaScript, стеки серверной части могут значительно различаться. Существует множество серверных стеков и продуктов баз данных, каждый из которых имеет свои собственные методы оптимизации. Поэтому в данном руководстве основное внимание будет уделено тем аспектам, которые применимы к большинству архитектур, а не ограничится рекомендациями для конкретных серверных стеков.

Руководство для конкретной платформы

Платформа, которую вы используете для своего веб-сайта, может сильно повлиять на TTFB. Например, на производительность WordPress влияет количество и качество плагинов или используемые темы. На другие платформы аналогично влияет настройка платформы. Вам следует обратиться к документации вашей платформы за рекомендациями для конкретного поставщика в дополнение к более общим советам по производительности, приведенным в этом посте. Аудит Lighthouse для сокращения времени ответа сервера также включает в себя некоторые ограниченные рекомендации для конкретного стека.

Хостинг

Перед тем как рассматривать другие методы оптимизации, первым вопросом, который следует учесть, является выбор хостинга. Здесь может не быть жестких рекомендаций, но общее правило заключается в том, чтобы удостовериться, что ваш веб-сайт может эффективно обрабатывать трафик, направляемый на него.

Общий хостинг обычно предоставляет меньшую производительность. Если у вас небольшой личный веб-сайт, который в основном предоставляет статические файлы, это, вероятно, приемлемо, и некоторые из следующих методов оптимизации могут помочь уменьшить TTFB.

Однако, если у вас крупное приложение с большим числом пользователей, включающее в себя персонализацию, запросы к базе данных и другие сложные операции на стороне сервера, выбор хостинг-провайдера становится критически важным для снижения TTFB в реальных условиях.

При выборе хостинг-провайдера учтите следующее:

1. Выделено ли достаточно памяти для вашего экземпляра приложения? Недостаток памяти может замедлить работу приложения и ухудшить время обслуживания страниц.
2. Поддерживается ли актуальное состояние вашего серверного стека? Следует выбирать хостинг-провайдера, который поддерживает актуализацию вашего программного обеспечения, так как новые версии могут улучшить производительность.
3. Если у вас специфические требования и вам нужен доступ к файлам конфигурации сервера, стоит ли настраивать свой экземпляр приложения?

Есть много хостинг-провайдеров, которые позаботятся об этих вещах за вас, но если вы начнете наблюдать длинные значения TTFB даже у выделенных хостинг-провайдеров, это может быть признаком того, что вам, возможно, придется переоценить возможности вашего текущего хостинг-провайдера, чтобы вы можете обеспечить наилучший пользовательский опыт.

Используйте сеть доставки контента (CDN)

Тема использования CDN, хоть и избита, имеет вескую причину: даже если ваша серверная часть приложения оптимизирована на высоком уровне, пользователи, находящиеся далеко от вашего исходного сервера, могут все равно сталкиваться с высоким TTFB в реальных условиях.

CDN решают эту проблему, обеспечивая близость пользователей к исходному серверу через распределенную сеть серверов, которые кэшируют ресурсы на серверах, физически близких к пользователям. Эти серверы называются пограничными серверами.

Воспользовавшись CDN, вы также можете получить следующие преимущества:

1. Быстрое разрешение DNS: Поставщики CDN часто предоставляют быстрое разрешение DNS.
2. Использование современных протоколов: CDN обычно обслуживают контент с использованием современных протоколов, таких как HTTP/2 или HTTP/3.
3. Решение проблемы блокировки начала строки: Протокол HTTP/3, использующий протокол UDP, решает проблему блокировки начала строки, присутствующую в TCP (используемом в HTTP/2).
4. Обеспечение современных версий TLS: CDN вероятно предоставит современные версии TLS, что снижает задержку, связанную с временем согласования TLS.
5. Пограничные работники: Некоторые поставщики CDN предоставляют функцию, подобную «пограничному работнику», что позволяет программно управлять ответами в пограничных кэшах.
6. Эффективное сжатие: Поставщики CDN хорошо оптимизируют сжатие, что сложно реализовать самостоятельно.
7. Автоматическое кэширование: CDN автоматически кэшируют сжатые ответы для статических ресурсов, обеспечивая наилучшее сочетание степени сжатия и времени ответа.

Несмотря на то что внедрение CDN может потребовать различных усилий, от тривиальных до значительных, оптимизация TTFB должна быть приоритетной задачей, особенно если ваш веб-сайт еще не использует эту технологию.

По возможности использовал кэшированный контент

CDN позволяют кэшировать контент на пограничных серверах, которые физически расположены ближе к посетителям, при условии, что контент настроен с использованием соответствующих HTTP-заголовков Cache-Control . Хотя это не подходит для персонализированного контента, требование обратного пути к источнику может свести на нет большую часть ценности CDN.

Для сайтов, которые часто обновляют свой контент, даже короткое время кэширования может привести к заметному увеличению производительности загруженных сайтов, поскольку только первый посетитель в течение этого времени испытывает полную задержку при возвращении на исходный сервер, в то время как все остальные посетители могут повторно использовать кэшированный ресурс. с пограничного сервера. Некоторые CDN допускают аннулирование кэша в выпусках сайта, что позволяет получить лучшее из обоих миров — длительное время кэширования, но при необходимости мгновенные обновления.

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

Более старый или менее посещаемый контент также может не кэшироваться, что может привести к более высоким значениям TTFB на некоторых страницах, чем на других. Увеличение времени кэширования может уменьшить это влияние, но имейте в виду, что увеличение времени кэширования увеличивает вероятность обслуживания потенциально устаревшего контента.

Влияние кэшированного контента затрагивает не только тех, кто использует CDN. Серверной инфраструктуре может потребоваться генерировать контент из дорогостоящих поисков в базе данных, когда кэшированный контент не может быть повторно использован. Более часто используемые данные или предварительно кэшированные страницы часто могут работать лучше.

Избегайте перенаправления нескольких страниц

Один из распространенных факторов, влияющих на высокий TTFB, — это использование перенаправлений. Перенаправления происходят, когда запрос на навигацию получает ответ, указывающий браузеру, что ресурс находится в другом месте. Одно перенаправление может добавить нежелательную задержку к запросу, но ситуация может ухудшиться, если оно указывает на другой ресурс, который в свою очередь приводит к еще одному перенаправлению, и так далее. Это особенно заметно на сайтах, получающих много посетителей из рекламы или информационных бюллетеней, так как они часто проходят через аналитические службы для измерения.

Существуют два типа перенаправлений:

1. Перенаправления того же происхождения: Происходят внутри вашего веб-сайта.
2. Перенаправления между источниками: Происходят извне вашего веб-сайта, например, из службы сокращения URL в социальных сетях.

Фокус следует сосредоточить на устранении перенаправлений того же происхождения, так как они под вашим контролем. Это может потребовать проверки ссылок на вашем сайте, чтобы убедиться, что они не приводят к коду ответа 302 или 301. Часто это может произойти из-за отсутствия схемы https:// или из-за некорректного форматирования URL-адреса.

Перенаправления между источниками более сложны, но старайтесь избегать множественных перенаправлений. Убедитесь, что URL, предоставленные рекламодателям или информационным бюллетеням, являются правильными конечными URL-адресами.

Также обратите внимание на перенаправление HTTP-to-HTTPS. Использование заголовка Strict-Transport-Security (HSTS) может ускорить процесс при первом посещении источника и обеспечить последующий доступ через HTTPS. При хорошей политике HSTS, добавление вашего сайта в список предварительной загрузки HSTS может улучшить производительность.

Если у вас есть хорошая политика HSTS, вы можете ускорить процесс при первом посещении источника, добавив свой сайт в список предварительной загрузки HSTS.

Потоковая разметка в браузер

Браузеры оптимизированы для эффективной обработки разметки при ее потоковой передаче, а это означает, что разметка обрабатывается частями по мере ее поступления с сервера. Это крайне важно, когда речь идет о больших полезных нагрузках разметки, поскольку это означает, что браузер может анализировать эти фрагменты разметки постепенно, а не ждать получения всего ответа, прежде чем можно будет начать анализ.

Хотя браузеры отлично справляются с обработкой потоковой разметки, крайне важно сделать все возможное, чтобы поток не прерывался, чтобы начальные фрагменты разметки были готовы как можно скорее. Если серверная часть тормозит, это проблема. Поскольку серверных стеков много, в рамках данного руководства не будет описывать каждый стек и проблемы, которые могут возникнуть в каждом конкретном из них.

Например, React и другие платформы, которые могут отображать разметку на сервере по требованию , использовали синхронный подход к рендерингу на стороне сервера. Однако в более новых версиях React реализованы серверные методы для потоковой передачи разметки во время ее рендеринга. Это означает, что вам не нужно ждать, пока метод API сервера React отобразит весь ответ перед его отправкой.

Для обеспечения быстрой передачи разметки в браузер можно использовать еще один подход — статический рендеринг, при котором HTML-файлы генерируются во время сборки. Когда полный файл доступен сразу, веб-сервер может немедленно начать отправку файла, а внутренняя природа HTTP позволяет потоково передавать разметку. Хотя этот подход не подходит для каждой страницы на каждом веб-сайте (например, для тех, которые требуют динамического ответа взаимодействия с пользователем), он может быть полезен для страниц, не требующих персонализированной разметки для конкретного пользователя.

Используйте ServiceWorker

API Service Worker может оказать большое влияние на TTFB как для документов, так и для загружаемых ими ресурсов. Причина этого в том, что сервис-воркер действует как прокси-сервер между браузером и сервером, но влияние на TTFB вашего веб-сайта зависит от того, как вы настроили сервис-воркера и соответствует ли эта настройка требованиям вашего приложения.

• Используйте для активов стратегию устаревания во время повторной проверки . Если актив находится в кэше сервисного работника (будь то документ или ресурс, который требуется документу), стратегия устаревшего при повторной проверке сначала будет обслуживать этот ресурс из кэша, а затем загружать этот актив в фоновом режиме и обслуживать его из кэша. кэш для будущих взаимодействий.
  • Если у вас есть ресурсы документов, которые меняются не очень часто, использование стратегии «устаревшие при повторной проверке» может сделать TTFB страницы практически мгновенным. Однако это работает не так хорошо, если ваш веб-сайт отправляет динамически генерируемую разметку, например разметку, которая меняется в зависимости от того, прошел ли пользователь аутентификацию. В таких случаях вам всегда нужно сначала подключиться к сети, чтобы документ был как можно более свежим.
  • Если ваш документ загружает некритические ресурсы, которые меняются с некоторой частотой, но извлечение устаревшего ресурса не сильно повлияет на взаимодействие с пользователем (например, избранные изображения или другие некритические ресурсы), TTFB для этих ресурсов может быть значительно уменьшен. используя стратегию устаревшей при повторной проверке.
• Если возможно, используйте рабочую архитектуру службы потоковой передачи . В этой архитектуре сервис-воркера используется подход, при котором части ресурса документа хранятся в кэше сервис-воркера и объединяются с частями содержимого во время запроса навигации. Результатом использования этого шаблона сервисного работника является то, что ваша навигация будет довольно быстрой, в то время как полезные данные HTML будут загружаться из сети меньшего размера. Хотя этот шаблон сервисного работника работает не для каждого веб-сайта, время TTFB для ресурсов документов может быть практически мгновенным для сайтов, которые могут его использовать.
• Используйте модель оболочки приложения для приложений, отображаемых клиентом. Эта модель лучше всего подходит для SPA, где «оболочка» страницы может быть доставлена ​​мгновенно из кэша сервисного работника, а динамическое содержимое страницы заполняется и отображается на более позднем этапе жизненного цикла страницы.

Используйте 103 Early Hints для ресурсов, критически важных для рендеринга

Вне зависимости от того, насколько хорошо оптимизирована серверная часть вашего приложения, сервер может столкнуться с необходимостью выполнения значительного объема работы для подготовки ответа, включая дорогостоящую, но необходимую, обработку базы данных. Это может задерживать прибытие навигационного ответа так быстро, как это возможно. Этот процесс может повлиять на последующие ресурсы, критически важные для рендеринга, такие как CSS или, в некоторых случаях, JavaScript, отвечающий за отображение разметки на клиенте.

Заголовок 103 Early Hints представляет собой код раннего ответа, который сервер может отправить браузеру во время подготовки разметки. Этот заголовок используется для того, чтобы предварительно уведомить браузер о критически важных ресурсах, которые страница должна начать загружать еще до завершения подготовки разметки. В результате поддерживающие браузеры могут обеспечить более быстрый рендеринг документов (CSS) и более быстрый доступ к основным функциям страницы (JavaScript).

Заключение

Поскольку существует множество комбинаций стеков серверных приложений, нет универсального решения, которое охватывает все возможности по снижению TTFB вашего веб-сайта. Однако вот несколько вариантов, которые стоит рассмотреть для оптимизации работы на стороне сервера:

1. Измерение и анализ:
   • Измерьте TTFB в реальных условиях, полагаясь на полевые данные.
   • Используйте лабораторные инструменты для выявления причин задержек.
2. Оптимизация хостинга:
   • Убедитесь, что ваш хостинг-провайдер обеспечивает достаточные ресурсы.
   • Проверьте выделенную память для вашего приложения.
3. Использование CDN:
   • Рассмотрите внедрение CDN для улучшения доступности контента ближе к конечным пользователям.
4. Управление перенаправлениями:
   • Избегайте избыточных перенаправлений, особенно тех же происхождения.
   • Учтите перенаправление HTTP-to-HTTPS и используйте заголовок Strict-Transport-Security (HSTS).
5. Статический рендеринг:
   • Используйте статический рендеринг для генерации HTML-файлов во время сборки, где это возможно.
6. Заголовок 103 Early Hints:
   • Рассмотрите использование заголовка 103 Early Hints для предварительной загрузки критически важных ресурсов.
7. Использование Server-Timing:
   • Используйте заголовок ответа Server-Timing для измерения и отладки процессов на стороне сервера.
8. Управление перенаправлениями:
   • Устраните ненужные перенаправления и учтите их в своем контроле.
9. Использование Server-Timing для измерения:
   • Рассмотрите использование заголовка Server-Timing для измерения процессов на стороне сервера, таких как запросы к базе данных, время рендеринга и другие.
10. Структурированный подход:
    • Применяйте оптимизации, основанные на конкретных данных и характеристиках вашего приложения, а не просто в соответствии с общими рекомендациями.

Как и при любой оптимизации, важно регулярно мониторить полевые данные и внимательно анализировать результаты, внося необходимые коррективы для достижения максимальной производительности и быстрого взаимодействия с пользователями.