Почему ваш сайт должен иметь размер менее 14 КБ

Небольшой размер сайта напрямую ускоряет его загрузку — в этом нет ничего неожиданного. Удивительно другое: страница размером 14 КБ может загружаться значительно быстрее, чем страница в 15 КБ — разница способна достигать 612 мс. При этом между страницами 15 КБ и 16 КБ разница во времени загрузки уже почти незаметна.

Это связано с алгоритмом медленного запуска TCP (TCP slow start). В этой статье мы разберём, что это такое, как он работает и почему вам стоит обращать на это внимание. Но для начала кратко пройдёмся по базовым понятиям.

Это перевод/адаптация статьи Why your website should be under 14kB in size от Nathaniel

Transmission Control Protocol (TCP) — это протокол, который поверх интернет-протокола (IP) обеспечивает надёжную передачу пакетов данных. Иногда всю эту связку называют TCP/IP.

Когда браузер запрашивает ваш веб-сайт (или, например, изображение либо таблицу стилей), он делает это с помощью протокола HTTP.

HTTP работает поверх TCP, и один HTTP-запрос обычно передаётся не одним, а несколькими TCP-пакетами.

Сам по себе IP — это лишь система доставки пакетов данных из одной точки Интернета в другую. Он не умеет проверять, дошёл ли пакет до получателя успешно.

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

TCP — это надстройка над IP, которая позволяет браузеру и серверу веб-сайта сообщать друг другу, какие пакеты были успешно доставлены, а какие — нет.

Сервер отправляет несколько пакетов, затем ждёт ответа от браузера о том, что они получены. Такой ответ называется подтверждением (ACK, от Acknowledge). После этого сервер отправляет следующую порцию пакетов — либо, если ACK не пришёл, повторно отправляет данные.

Медленный старт TCP (TCP slow start) — это алгоритм, который серверы используют, чтобы определить, сколько пакетов можно отправлять одновременно.

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

Пропускная способность (bandwidth) — это объём данных, который может быть передан по сети за единицу времени. Обычно её измеряют в битах в секунду (бит/с). Часто используют аналогию с сантехникой: представьте пропускную способность как то, сколько воды может протекать по трубе за секунду.

Сервер не знает, какой объём данных способно выдержать соединение, поэтому сначала отправляет небольшой и безопасный объём — обычно около 10 TCP-пакетов.

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

После этого сервер отправляет следующую порцию данных, увеличивая количество пакетов вдвое.

Этот процесс повторяется до тех пор, пока пакеты не начнут теряться или сервер не перестанет получать подтверждения ACK. В этот момент сервер продолжает передачу данных, но снижает скорость отправки.

В этом и заключается суть медленного старта TCP (TCP slow start). В реальности конкретная реализация алгоритма может отличаться, но в общих чертах он работает именно так.

Большинство реализаций TCP slow start на веб-серверах начинают передачу именно с 10 TCP-пакетов.

Максимальный размер TCP-пакета составляет 1500 байт.

Этот предел задан не спецификацией TCP — он следует из стандарта Ethernet.

Каждый пакет TCP использует 40 байт в заголовке — 16 байт для IP и дополнительные 24 байта для TCP (IP-пакет содержит TCP-сегмент).

Остается 1460 байт на содержимое TCP-пакета. 10 x 1460 = 14600 байт или примерно 14 КБ!

Поэтому, если вам удастся уместить весь сайт — или хотя бы его критически важную часть — в 14 КБ, вы сэкономите пользователям значительное количество времени. Речь идёт о времени, необходимом на один сетевой «туда-обратно» (round trip) между браузером посетителя и вашим сервером.

Люди очень нетерпеливы, и даже один сетевой проход туда-обратно может занимать неожиданно много времени. Сколько именно — зависит от задержки (latency) сети…

Задержка (latency) — это время, за которое пакет данных проходит путь от источника до получателя. Если пропускная способность — это то, сколько воды может протекать по трубе за секунду, то задержка — это время, за которое одна капля входит в трубу и выходит с другого конца.

Вот забавный пример того, насколько плохой может быть задержка:

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

Чтобы наглядно показать, что такое плохая задержка, представим следующую ситуацию: группа рабочих на нефтяной платформе забыла дома игральные кости и вынуждена использовать отличный сайт Missingdice.com (размером менее 14 КБ), чтобы играть в Dungeons & Dragons.

Сначала один из них использует свой телефон, чтобы сделать запрос на веб-страницу…

Телефон отправляет этот запрос на Wi-Fi-маршрутизатор платформы, а тот передаёт данные на спутниковую тарелку. Будем оптимистичны и предположим, что на это уходит всего 1 мс.

Затем спутниковая антенна должна отправить эти данные на спутник, находящийся на орбите над Землей.

Обычно это достигается с помощью спутника на геостационарной орбите на высоте 35786 км над поверхностью Земли. Скорость света составляет 299792458 м/с, поэтому сообщение, отправленное с Земли на спутник, занимает 120 мс. Затем спутник отправляет сообщение обратно на наземную станцию, что занимает еще 120 мс.

Затем наземная станция должна отправить запрос туда, где находится сервер на земле (свет замедляется до 200000000 м/с, когда он находится в оптоволоконном кабеле). Если расстояние между наземной станцией и сервером такое же, как расстояние между Нью-Йорком и Лондоном, это займет около 28 мс, но если оно больше похоже на расстояние между Нью-Йорком и Сиднеем, оно займет 80 мс, поэтому мы назовем это 60 мс (удобное число для наших математических вычислений).

Затем запрос должен быть обработан сервером, что может занять около 10 мс, после чего сервер снова отправляет его обратно.

Обратно на наземную станцию, в космос, обратно к спутниковой антенне, затем к Wi-Fi маршрутизатору и снова к телефону нашего нефтяника.

Если мы посчитаем, то это будет 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612 мс.

Это означает дополнительные 612 мс на каждый сетевой «туда-обратно». Возможно, на первый взгляд это не кажется слишком долгим ожиданием, но на веб-сайте может потребоваться несколько таких проходов ещё до того, как браузер получит самый первый ресурс.

Кроме того, HTTPS требует двух дополнительных циклов передачи данных, прежде чем он сможет выполнить первый — что дает нам время до 1836 мс!

Спутниковый интернет может показаться заведомо плохим примером — я выбрал его именно потому, что он наглядный и немного экстремальный. Однако и у пользователей «на суше» задержка может быть не меньше, а иногда и хуже, по целому ряду причин:

- Мобильные устройства 2G обычно имеют задержку от 300 до 1000 мс.
- Сети 3G могут иметь задержку от 100 до 500 мс.
- Шумная мобильная сеть — скажем, в необычно людном месте, например на музыкальном фестивале.
- Серверы, работающие с большими объемами трафика

Неоднородные и нестабильные соединения также могут приводить к потере пакетов, из-за чего требуется дополнительный сетевой «туда-обратно», чтобы повторно получить утраченные данные.

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

Эти 14 КБ считаются уже с учётом сжатия, то есть фактически это может быть около 50 КБ несжатых данных — что, по меркам веба, весьма щедро. Для сравнения: у компьютеров управления «Аполлона-11» было всего 72 КБ памяти.

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

Но даже если вы очень старались уложиться в 14 КБ, но всё же не смогли, это правило всё равно остаётся полезным ориентиром.

Если вы уверены, что первые 14 КБ данных, отправляемые пользователю, позволяют отобразить что-то действительно полезное — например, критически важные CSS и JS, а также первые абзацы текста с объяснением того, как пользоваться вашим приложением.

Примечание. Правило 14 КБ включает в себя и HTTP-заголовки, которые не сжимаются (даже при использовании HTTP/2 в первом ответе сервера). Оно также включает изображения, поэтому загружайте только то, что находится выше сгиба (above the fold) (имеется ввиду первый экран сайта), делайте изображения максимально лёгкими или используйте прелоадеры, чтобы посетители понимали, что загрузка идёт и впереди их ждёт что-то полезное.

Правило 14 КБ больше похоже на эмпирическое правило, чем на фундаментальный закон:

- Некоторые серверы увеличили начальное окно медленного запуска TCP до 30 пакетов вместо 10.

- Иногда сервер знает, что он может начать с большего количества пакетов, поскольку он использовал подтверждение TLS для установления возможности использования большего окна.

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

- Есть и другие предостережения — здесь более подробная статья о том, почему правило 14 КБ не всегда работает.

Иногда можно услышать мнение, что правило 14 КБ перестаёт быть актуальным при использовании HTTP/2. Я изучил всё, что смог по этой теме, не доводя себя до изнеможения, и не нашёл никаких подтверждений тому, что серверы с HTTP/2 перестали использовать медленный старт TCP или начали отправку данных с объёма больше 10 пакетов.

Как и в случае с HTTP/2, существует мнение, что HTTP/3 и QUIC покончат с правилом 14 КБ — это неправда. QUIC рекомендует то же правило 14 КБ.

Большая часть содержания этого поста взята из следующих ресурсов:

- Высокопроизводительная браузерная сеть от Ильи Григорика

- Увеличьте производительность HTTP, встроив начальное окно медленного запуска TCP, автор: Саймон Хоруп Эскильдсен

- Критические ресурсы и первые 14 КБ – обзор

- Улучшения производительности HTTP3