Оптимизировать время до первого байта

Узнайте, как оптимизировать показатель «Время до первого байта».

Jeremy Wagner

Barry Pollard

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

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

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

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

PageSpeed ​​Insights — это простой способ получить как полевые, так и лабораторные данные об общедоступных веб-сайтах, которые доступны в отчете об опыте пользователей Chrome .

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

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

Чтобы узнать больше о способах измерения TTFB как в полевых условиях, так и в лаборатории, посетите страницу показателей TTFB .

Понимание высокого 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 - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

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

В этом поле любая страница с набором заголовков ответа Server-Timing будет заполнять свойство serverTiming в 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 будут визуализированы на панели таймингов вкладки «Сеть» в Chrome DevTools:

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

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

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

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

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

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

Хостинг, хостинг, хостинг

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

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

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

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

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

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

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

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

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

Поставщики CDN также могут предлагать преимущества, выходящие за рамки пограничных серверов:

• Поставщики CDN обычно предлагают чрезвычайно быстрое разрешение DNS.
• CDN, скорее всего, будет обслуживать ваш контент с пограничных серверов, используя современные протоколы, такие как HTTP/2 или HTTP/3.
• HTTP/3, в частности, решает проблему блокировки начала строки, присутствующую в TCP (на которую опирается HTTP/2), используя протокол UDP .
• CDN, вероятно, также предоставит современные версии TLS, что снижает задержку, связанную с временем согласования TLS. В частности , TLS 1.3 предназначен для максимально короткого согласования TLS.
• Некоторые поставщики CDN предоставляют функцию, часто называемую «пограничным работником», которая использует API, аналогичный API Service Worker , для перехвата запросов, программного управления ответами в пограничных кэшах или полной перезаписи ответов.
• Поставщики CDN очень хорошо оптимизируют сжатие. Сжатие сложно реализовать самостоятельно, и в некоторых случаях это может привести к замедлению времени отклика при использовании динамически создаваемой разметки, которую необходимо сжимать на лету.
• Поставщики CDN также автоматически кэшируют сжатые ответы для статических ресурсов, что приводит к наилучшему сочетанию степени сжатия и времени ответа.

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

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

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

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

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

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

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

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

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

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

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

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

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

Другим важным источником времени перенаправления может быть перенаправление HTTP-to-HTTPS. Один из способов обойти эту проблему — использовать заголовок Strict-Transport-Security (HSTS), который будет обеспечивать соблюдение HTTPS при первом посещении источника, а затем сообщать браузеру о необходимости немедленного доступа к источнику через схему HTTPS в будущем. посещения.

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Изображение героя Тейлора Вика , взято с Unsplash.