- PVSM.RU - https://www.pvsm.ru -
Сейчас я работаю над проектом для одного клиента. Речь идёт о сайте из сферы электронной коммерции, поэтому меня очень сильно интересуют некоторые аспекты производительности. Для начала это — различные показатели, характеризующие время загрузки сайта. Дальше — это время начала рендеринга страницы, которое важно для тех посетителей, которые хотят, после захода на сайт, увидеть его содержимое как можно быстрее (в эту категорию, естественно, попадают все посетители сайта). Есть среди интересующих меня показателей производительности и такие, которые отражают специфику деятельности моего клиента. Например: «Насколько быстро загружается основное изображение товара?». Анализ всех этих показателей способен дать ценные сведения о состоянии проекта.
Однако есть один показатель, которому, как кажется, фронтенд-разработчики часто не уделяют должного внимания. Речь идёт о времени до первого байта (Time to First Byte, TTFB). Это можно понять, можно и хотя бы отчасти простить разработчикам такое отношение к TTFB, особенно учитывая то, что они видят этот показатель как нечто, зависящее только от бэкенда проектов. Но если попытаться буквально в двух словах выразить проблему, касающуюся этого показателя, то можно сказать следующее: «Хотя хорошее значение TTFB не обязательно означает того, что демонстрирующий его сайт можно счесть быстрым, плохой показатель TTFB практически гарантированно указывает на проблемы с производительностью проекта».
Даже если учитывать то, что фронтенд-разработчик может быть в таком положении, в котором он не способен самостоятельно повлиять на бэкенд и на TTFB, важно учитывать то, что высокие значения TTFB способны заметно повредить производительности сайта. В результате усилия фронтенд-разработчика, стремящегося к скорости сайта, будут напоминать игру в догонялки. Это относится, например, и к оптимизации изображений, и к минимизации объёмов материалов, входящих в состав важнейших разделов проекта, и к асинхронной загрузке веб-шрифтов. Нельзя сказать, что, зная это, можно опустить руки и отказаться от оптимизаций фронтенда. Но если показатель TTFB слишком высок, то все подобные оптимизации напоминают попытки исправить некую проблему в условиях, когда она уже нанесла вред, и когда исправлять эту проблему уже слишком поздно. Собственно говоря, именно поэтому тем, кто занят разработкой фронтенда, очень важно пристально следить за показателем TTFB, и очень важно, при появлении слишком высоких его значений, принимать меры к его улучшению.
Показатель TTFB выглядит не особенно информативным (изображение в полном размере [2])
TTFB — это показатель, который выглядит, мягко говоря, непрозрачным. На него так много всего влияет, что у меня возникает такое ощущение, будто мы всё время просто отмахиваемся от его серьёзного анализа. Многие предполагают, что TTFB — это просто время, необходимое серверу на то, чтобы подготовить ответ, но это, на самом деле, лишь малая часть того, что влияет на TTFB.
Первое, на что мне хотелось бы обратить ваше внимание, это то, узнав о чём, люди обычно очень удивляются. Речь идёт о том, что в TTFB входит время, которое запрос от клиента идёт по сети к серверу, и время, которое занимает путь ответа сервера клиенту. Речь идёт о так называемом «времени приёма-передачи» (Round Trip Time, RTT). TTFB — это не просто некое время, потраченное сервером на подготовку ответа. Это ещё и время которое тратится в пути данными, идущими от клиента к серверу и от сервера к клиенту (в составе этих данных, понятно, и находится интересующий нас «первый байт»).
Теперь мы, вооружённые этим знанием, легко можем понять причину того, что при просмотре сайтов с мобильных устройств показатель TTFB часто оказывается просто неприлично большим. Вполне возможно, что раньше вы в подобных ситуациях задавались примерно таким вопросом: «Уверен, сервер не знает о том, что я смотрю сайт с мобильного. Как он тогда увеличивает TTFB?». Причина этого в том, что, как правило, мобильные сетевые соединения — это соединения с высокой задержкой. Если показатель RTT, отражающий время, необходимое данным для прохождение пути от телефона к серверу и обратно, составляет, например, 250 мс, то на соответствующее значение вырастет и TTFB.
Если бы мне хотелось, чтобы читатели этого материала вынесли бы из него лишь одну важнейшую идею, то я сформулировал бы эту идею так: «Сетевые задержки влияют на TTFB».
Что ещё влияет на TTFB? На самом деле — уйма всего. Вот далеко не полный список того, что вносит вклад в формирование этого показателя. Пункты этого списка расположены в произвольном порядке.
TTFB в 0 мс — это несбыточная мечта. Поэтому важно отметить, что в списке нет чего-то такого, что всегда плохо сказывается на TTFB или всегда ухудшает этот показатель. Этот список лучше всего воспринимать как описание структуры TTFB некоего проекта. Моя цель заключается не в том, чтобы критиковать некие технологии, а в том, чтобы показать, как те или иные технологии могут влиять на TTFB. И, если честно, учитывая то, как много всего происходит до того, как клиент получит первый байт ответа от сервера, удивительно уже то, что сайты вообще загружаются.
Теперь, надеюсь, TTFB выглядит уже не таким уж и таинственным показателем. А если потратить немного времени на реализацию API Server Timing [10], то можно приступать к измерениям хитрых серверных временных показателей и к отправке их на клиентские системы. Это позволит веб-разработчикам обнаруживать и устранять потенциальные узкие места производительности, которые раньше были скрыты от их взоров.
API Server Timing позволяет разработчикам расширять ответы на запросы с помощью дополнительного HTTP-заголовка Server-Timing
. Он содержит сведения о временных показателях, измеренные самим приложением.
Именно этим механизмом мы воспользовались в прошлом году при работе над BBC iPlayer.
Новый заголовок Server-Timing можно добавить к любому ответу (изображение в полном размере [11])
Обратите внимание на то, что механизм Server Timing тоже оказывает нагрузку на систему. В ходе его работы нужно измерить соответствующие показатели и заполнить заголовок Server-Timing
. Браузер лишь позволяет фронтенд-разработчику просматривать эти данные, пользуясь соответствующими инструментами.
Теперь, прямо в браузере, можно видеть структуру TTFB (изображение в полном размере [12])
Если вы хотите реализовать у себя API Server Timing — взгляните на этот материал [13].
Очень важно, чтобы веб-разработчики понимали бы масштабы влияния TTFB на всё то, что называют «производительностью сайтов». Время до первого байта — это некая граница, после пересечения которой можно говорить об оптимизации сайта. Чем ниже этот показатель — тем лучше.
Уважаемые читатели! Оптимизируете ли вы свои веб-проекты с учётом TTFB?
Автор: ru_vds
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/332856
Ссылки в тексте:
[1] Image: https://habr.com/ru/company/ruvds/blog/470868/
[2] изображение в полном размере: https://csswizardry.com/wp-content/uploads/2019/08/screenshot-ttfb-full.png
[3] 75 мс: https://wondernetwork.com/pings/London/New+York
[4] PoP: https://en.wikipedia.org/wiki/Point_of_presence
[5] хостинг: https://www.reg.ru/?rlink=reflink-717
[6] WAF: https://en.wikipedia.org/wiki/Web_application_firewall
[7] свёртывание запроса: https://docs.fastly.com/guides/performance-tuning/request-collapsing
[8] ESI: https://en.wikipedia.org/wiki/Edge_Side_Includes
[9] Задержки на «последней миле»: https://en.wikipedia.org/wiki/Last_mile
[10] Server Timing: https://www.w3.org/TR/server-timing/
[11] изображение в полном размере: https://csswizardry.com/wp-content/uploads/2019/08/screenshot-server-timing-full.png
[12] изображение в полном размере: https://csswizardry.com/wp-content/uploads/2019/08/screenshot-ttfb-iplayer-full.png
[13] этот материал: https://medium.com/bbc-design-engineering/server-timing-in-the-wild-bfb34816322e
[14] Источник: https://habr.com/ru/post/470868/?utm_source=habrahabr&utm_medium=rss&utm_campaign=470868
Нажмите здесь для печати.