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

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

Barry Pollard

Jeremy Wagner

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

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

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

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

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

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

Для лабораторных данных подмножество TTFB показано в аудите времени ответа сервера :

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

Понимать различия между полевым и лабораторным TTFB

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

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

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

  Чтобы проверить, влияет ли кэширование на стороне сервера на время до получения (TTFB) в лаборатории, попробуйте протестировать менее распространённые страницы или использовать другие параметры URL для получения некэшированного контента. Это поможет определить, соответствует ли время до получения (TTFB) полю 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 будут визуализированы на панели таймингов на вкладке «Сеть» в 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 предоставляют функцию, часто называемую «edge worker», которая использует 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 на HTTPS. Один из способов обойти это — использовать заголовок Strict-Transport-Security (HSTS), который включает HTTPS при первом посещении источника, а затем сообщает браузеру о необходимости немедленного доступа к источнику по протоколу HTTPS при последующих посещениях.

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

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

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

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

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

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

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

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

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

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

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

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

Один из недостатков 103 Early Hints заключается в том, что, как и кэширование, они могут маскировать «реальное» время загрузки сайта. Если инфраструктура сервера медленная (из-за недостаточной мощности или необходимости оптимизации кода), то это может быть менее очевидно при использовании 103 Early Hints, поскольку время загрузки кажется быстрым. Сайтам, использующим 103 Early Hints, следует рассмотреть возможность измерения фактического времени загрузки сервера (с помощью Server-Timing или finalResponseHeadersStart API PerformanceNavigationTiming ).

Заключение

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

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

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