Чем меньше веб-сайт, тем быстрее он грузится, и это неудивительно.
Удивительно то, что страница на
14 КБ может грузиться гораздо быстрее, чем страница на 15 КБ, даже на 612 мс быстрее, хотя разница между страницами на 15 КБ и 16 КБ минимальна.Так происходит из-за алгоритма медленного старта TCP. В этой статье я расскажу, что это такое, как оно работает и почему это важно. Но сначала мы вкратце расскажем об основах.
Что такое TCP?
Transmission Control Protocol (TCP) — это способ использования Internet Protocol (IP) для надёжной передачи пакетов данных; иногда его также называют TCP/IP.
Когда браузер запрашивает ваш веб-сайт (или изображение, или таблицу стилей), он выполняет запрос при помощи HTTP.
HTTP построен поверх TCP, один HTTP-запрос обычно состоит из множества пакетов TCP.
Сам по себе IP — это просто система отправки пакетов данных из одной точки Интернета в другую. IP не имеет возможности проверить, добрался ли пакет до пункта назначения.
Когда мы работаем с веб-сайтами, важно знать, прибыли ли все данные, в противном случае фрагменты веб-страницы будут потеряны. Существуют и другие способы применения веба, например, стриминг видео, но в данном случае это неважно.
TCP — это расширение IP, позволяющее браузеру и серверу веб-сайта сказать друг другу, какие пакеты успешно получены.
Сервер отправляет несколько пакетов, затем ожидает ответа от браузера, сообщающего, что он получил пакеты (это называется подтверждением приёма, acknowledgement, или ACK), затем отправляет ещё несколько пакетов, а если он не получил ACK, то может отправить пакеты повторно.
Что такое медленный старт TCP?
Медленный старт TCP (TCP slow start) — это алгоритм, используемый серверами для определения того, сколько пакетов можно отправить за раз.
Когда браузер выполняет подключение к серверу, сервер никак не может узнать ширину канала между ними.
Ширина канала (bandwidth) — это объём данных, который можно передать по сети за единицу времени. Обычно она измеряется в битах в секунду (
бит/с). В качестве аналогии можно привести задачу про воду и трубы: ширина канала — это количество воды, которое может выливаться из трубы в секунду.Ваш сервер не знает, с каким объёмом данных может справиться соединение, поэтому сначала он отправляет небольшое надёжное количество данных, обычно 10 пакетов TCP.
Если эти пакеты успешно добираются до посетителя сайта, то его компьютер передаёт подтверждение приёма (ACK), сообщающее об успешном получении пакетов.
Затем сервер отправляет новые данные, на этот раз удваивая количество пакетов.
Этот процесс повторяется до утери пакетов, когда сервер не получит ACK. (После этого сервер продолжает отправлять пакеты, но с меньшей частотой.)
Вот краткое описание медленного старта TCP. В реальной ситуации реализация алгоритма варьируется, но в целом он работает так.
Откуда же взялась величина 14 КБ?
Медленный старт TCP большинства веб-серверов начинает с отправки 10 пакетов TCP.
Максимальный размер пакета TCP составляет
1500 байтов.Этот максимум определяется не спецификацией TCP, а стандартом Ethernet.
В каждом пакете TCP 40 байтов используются под заголовок — 16 байтов для IP и дополнительные 24 байта для TCP.
То есть на каждый пакет TCP остаётся 1460 байтов.
10 x 1460 = 14600 байтов, или приблизительно 14 КБ!То есть если вы сможете уместить свой веб-сайт (или хотя бы его критически важные части) в 14 КБ, то сэкономите посетителям кучу времени, необходимого для передачи данных туда и обратно между ними и сервером веб-сайта.
Насколько долгим может быть путь туда и обратно?
Люди очень нетерпеливы, а один путь туда и обратно на удивление длителен. Его длительность зависит от задержки…
Задержка (latency) — это время, необходимое пакету данных для перемещения от его источника к конечной точке. Если ширина канала — это количество воды, проходящее через трубу за секунду, то задержка — это время, необходимое капле воды, чтобы попасть в трубу и выйти с другого конца.
Вот любопытный пример того, насколько плохой может быть задержка:
Спутниковый Интернет
Спутниковый Интернет предоставляется спутником на орбите Земли. Он используется в местах с очень низкой плотностью населения, на нефтяных платформах, круизных судах и для WiFi в самолётах на время полёта.
Чтобы проиллюстрировать этот пример ужасной задержки, представим, что компания нефтяников забыла свои кубики дома и хочет использовать замечательный сайт missingdice.com (меньше 14 КБ), чтобы сыграть в Dungeons & Dragons.
Сначала один из нефтяников через свой телефон выполняет запрос к веб-странице…
Телефон отправляет запрос WiFi-маршрутизатору платформы, передающему эти данные на спутниковую тарелку буровой платформы. Давайте будем щедрыми, пусть это занимает
1 мс.Затем спутниковая тарелка должна отправить эти данные на спутник, летающий по орбите вокруг Земли.
Обычно для этого спутник выводят на геостационарную орбиту в
35786 км над поверхностью Земли. Радиоволны (и свет) движутся со скоростью 299792458 м/с, поэтому отправленное с Земли на спутник сообщение будет передано за 120 мс. Затем спутник отправляет сообщение на земную станцию, для чего требуется ещё 120 мс.Затем земная станция должна отправить запрос в ту точку Земли, где находится сервер (перемещаясь по оптоволоконному кабелю, свет замедляется до
двухсот миллионов м/с). Если расстояние между земной станцией и сервером такое же, как расстояние между Нью-Йорком и Лондоном, то он будет передан примерно за 28 мс, но если оно ближе к расстоянию между Нью-Йорком и Сиднеем, то это займёт 80 мс, так что остановимся на 60 мс (удобное для наших расчётов значение).Затем сервер должен обработать запрос, что может занять, наверное, около
10 мс, после чего сервер отправляет его обратно.Снова на земную станцию, в космос, обратно на спутниковую тарелку, затем на WiFi-маршрутизатор, и, наконец, в телефон нефтяника.
телефон -> WiFi-маршрутизатор -> спутниковая тарелка -> спутник -> земная станция -> сервер -> земная станция -> спутник -> спутниковая тарелка -> WiFi-маршрутизатор -> телефон
Если мы выполним расчёт, то получим
10 + ( 1 + 120 + 120 + 60 ) x 2 = 612 мс.Это дополнительные
612 мс на каждый путь туда и обратно. Возможно покажется, что это не очень долго, но ваш веб-сайт лишь для получения первого ресурса запросто может выполнить множество таких передач туда и обратно.Кроме того, до выполнения первого пути протоколу HTTPS требуется две дополнительных передачи, что даёт нам
1836 мс!А какой задержка будет для людей, живущих на суше?
Может показаться, что мы намеренно выбрали плохой пример со спутниковым Интернетом. Я выбрал его потому, что он иллюстрирует моё утверждение, но он странный. Впрочем, для живущих на суше задержка по множеству причин может быть ещё хуже:
- Мобильная связь 2G обычно имеет задержку от
300 мсдо1000 мс - Сети 3G могут иметь задержку от
100 мсдо500 мс - «Шумные» мобильные сети, допустим, в необычно переполненном месте наподобие музыкального фестиваля
- Серверы, которым приходится справляться с большими объёмами трафика
- Различные неприятности
Прерывистые соединения тоже могут вызывать утерю пакетов, из-за чего может потребоваться ещё один путь туда-обратно для получения утерянных пакетов.
Что вы можете сделать, узнав о правиле 14 КБ?
Разумеется, вы можете сделать ваш веб-сайт как можно меньше — вы же любите своих посетителей и хотите, чтобы они были довольны. Стремление к тому, чтобы каждая страница умещалась менее чем в 14 КБ — хорошая цель.
Эти 14 КБ включают в себя сжатие, то есть на самом деле распакованных данных может быть примерно 50 КБ, что довольно щедро. Напомню, что управляющие ЭВМ «Аполлона-11» имели всего 72 КБ памяти.
Как только вы избавитесь от видео с автоматическим воспроизведением, всплывающих окон, куки, разрешающих куки баннеров, кнопок социальных сетей, скриптов слежения, фреймворков Javascript и CSS и от всего остального мусора, который никому не нравится, то, скорее всего, достигнете желаемого.
И даже если вы изо всех сил пытались уместить всё в 14 КБ, но не смогли, правило 14 КБ всё равно остаётся полезным.
Постарайтесь сделать так, чтобы первые 14 КБ передаваемых посетителям данных можно было использовать для рендеринга чего-то полезного, например, это могут быть какие-то критически важные CSS, JS и первые несколько параграфов текста, объясняющие, как пользоваться вашим приложением.
Примечание: в правило 14 КБ включаются и HTTP-заголовки, которые не упаковываются (даже с использованием HTTP/2 в первом ответе), а также изображения, поэтому загружайте только то, что находится наверху, и делайте их очень маленькими, или используйте заглушки, чтобы посетители знали, что их ждёт что-то хорошее.
Некоторые особенности этого правила
Правило 14 КБ — это эмпирическое правило, а не фундаментальный закон:
- Некоторые серверы увеличили окно медленного старта TCP с 10 до 30 пакетов
- Иногда сервер знает, что он может начать с большего количества пакетов, потому что использовал TLS handshake для определения того, что можно использовать большее окно.
- Серверы могут кэшировать количество пакетов, которое может выдержать соединение, и отправлять в следующий раз большее количество.
- Есть и другие особенности: вот более глубокая статья о том, что правило 14 КБ применимо не всегда
HTTP/2 и правило 14 КБ
Кто-то считает, что правило 14 КБ неактуально при использовании HTTP/2. Я прочитал по этой теме всё возможное, пока мне это не наскучило, но не встретил никаких свидетельств того, что серверы, использующие HTTP/2, больше не применяют в начале медленный старт TCP с 10 пакетами.
HTTP/3 и QUIC
Аналогично существует мнение, что HTTP/3 и QUIC отменяют правило 14 КБ, но на самом деле это не так. QUIC рекомендует использовать то же правило 14 КБ.
Дополнительные источники
Основная часть содержимого этого поста взята из следующих ресурсов:
Комментарии (178)
dendude
26.08.2022 16:39+3То есть нужно иметь каждый файл не более 14кБ чтобы всё работало фить-фить. При этом картинки такого размера найти нереально, вместо них lazy load ?
LuggerFormas
26.08.2022 16:55+3CDN уже давно стандарт вроде.
alfixer
26.08.2022 17:49+11Как раз вчера смотрел интервью с мужиком, нехило шарящим в подобном, который обьяснял, почему CDN - просто маркетинговая пыль в глаза тем, кто не понимает техчасти.
AlexVS85
26.08.2022 23:40+1Я так понимаю, это правда только в случае когда статика (картинки, скрипты, стили) раздаются тем же сервером что и сама страница (html) - тогда браузер может переиспользовать tcp соединение и не тратить время на открытие нового.
Но в случаи нагруженных сервисов (или больших объемов) статика чаще всего где-то на другом сервере (AWS S3, GCS, ...) и тут не вижу проблем в CDN
поправьте меня если я не прав
alfixer
27.08.2022 01:15+1Именно так. Или когда сервер и ЦА находятся в противоположных частях света или разбросаны по миру, также защита от DDOS. Тогда да, однозначно должно быть. В противных случаях в этом нет смысла и даже может навредить.
AlexVS85
27.08.2022 01:43+1по сути можно свести к двум ситуациям:
сайт достаточно простой что все можно раздать с одного сервера - CDN может замедлить за счет лишнего коннекта (+ время на резолв домена?). Это в случаи если все правильно настроено, а не Wordpress на бесплатном/дешевом shared hosting
статика раздается отдельно от HTML, тут сложно придумать случай вреда CDN
так что:
Как раз вчера смотрел интервью с мужиком, нехило шарящим в подобном, который обьяснял, почему CDN - просто маркетинговая пыль в глаза тем, кто не понимает техчасти.
звучит как преувеличение
andreishe
26.08.2022 17:30+1Браузер переиспользует соединения для запросов с одного хоста, т.ч. через одно соединение может быть прокачано больше данных, даже если каждый запрос будет меньше 14k. И еще имейте в виду HTTP заголовки.
alfixer
26.08.2022 17:30Речь о первом пакете, в который нужно уместить сжатый HTML+важный CSS, чтобы показать хотя бы основу сайта. Помнить о критерии CLS. На картинки поставить заглушки или skeleton loader. Далее пакеты удваиваются с каждой итерацией.
Aquahawk
26.08.2022 22:45нет, благодаря keep-alive который является дефолтной опцией по стандарту http 1.1 соединение продолжит использоваться дальше и его параметры скорее всего улучшатся. Речь только о новых соединениях где качество соединения заранее нетзвестно и пихать всё в сеть со стороны сервера не разумно.
pae174
28.08.2022 13:48На freebsd есть hostcache - хранилище статистики по качеству связи с теми хостами, с которыми сервер уже успел поработать. Так что если какой-то клиент с толстым каналом уже работал с сервером и у него было наработано большое cwnd, то послу ухода и последующего возвращения этого клиента у него сразу будет большое cwnd без всяких там начальных 14 килобайт.
Breathe_the_pressure
26.08.2022 17:39+33А эта статья у вас на 28,21 кБ. Вам надо бы поработать над размером. :)
ermouth
26.08.2022 17:53+1Было бы круто, если б в перевод не затаскивалась прямо вся разметка из оригинала. Автор оригинала явно злоупотребляет разметкой.
aborouhin
26.08.2022 18:12+11А не проще ли на сервере увеличить initcwnd / initrwnd (то самое количество пакетов, с которого мы начинаем) этак до 30, чтобы без лишних задержек пролетали страницы бóльшего размера? Пользователи с хорошим каналом получат прирост в скорости, а пользователи с еле живым - и так привыкли, что у них всё зависает :)
ryo_oh_ki
26.08.2022 19:03+1Жаль, что в HTML-тегах внешних ресурсов типа img, script, iframe и так и не появился атрибут etag, представляющий аналогичный заголовок HTTP. Это позволило бы самой странице управлять кешированием собственного контента, и всё бы влезало в эти 14 Кб... наверное.
andreymal
26.08.2022 19:14+1Вообще, у некоторых тегов есть атрибут integrity, содержащий хэш содержимого по ссылке. Возможно, в будущем его добавят для картинок и задействуют в кэшировании, но пока что не судьба
ifap
26.08.2022 23:53Вряд ли, SRI - это про совсем другое и прикручивать хэш к ресурсам на same host - увеличивать размер кода во славу непонятно чего.
andreymal
27.08.2022 00:20Ну не знаю, лично для меня идентификация ресурсов по их хэшу выглядит вполне логичной (предполагая, что у sha256 не найдут нехороших коллизий в обозримом будущем)
По крайней мере, если issue на гитхабе за год не закрыли — значит W3C тоже считает это логичным, возможно?
ifap
27.08.2022 00:36Я исхожу из того, что если мы допускаем доступ третьих лиц к своему веб-серверу на запись, то изменение ими какой-нибудь .css - меньшее из возможных зол, а значение хэша они в html поправят уж как-нибудь. W3C ИМХО исходят из того же посыла, упоминая в драфте следующей рекомендации SRI сторонние хосты как источник излишеств всяких нехороших. Впрочем, 1 пример у них приведен без схемы, т.е. скрипт загружается с same host...
Это я все к тому, что SRI вряд ли будут затачивать под кэширование.
andreymal
27.08.2022 01:27+1При чём тут третьи лица? Просто проверяем актуальность закэшированного ресурса по хэшу вместо etag или даты
pae174
28.08.2022 14:26SRI не имеет никакого отношения к кэшированию и предназначен для предотвращения неприятностей в случае кагда ваш сайт использует на своих страницах какие-то штуки с других сайтов. Например, если вы на своём сайте размещаете <script src=http://какой-то-чужой-сайт/какой-то-там-скрипт.js>. Эта штука вообще бессмысленна применительно к собственным ресурсам.
pae174
28.08.2022 14:32-1Жаль, что в HTML-тегах внешних ресурсов типа img, script, iframe и так и не появился атрибут etag,
ETag с самого начала был везде - это свойство протокола а не какого-то конкретного формата файлов.
mayorovp
28.08.2022 14:58Речь идёт о способе подсказать etag ресурса ещё до попытки загрузить этот самый ресурс.
pae174
28.08.2022 16:02Я ничего не понял про подсказку etag ресурса.
Сейчас есть три механизма:
1) Сервер отдает браузеру Expires дата или Cache-control max-age=срок и браузер больше не беспокоит сервер запросами по поводу ресурса до истечения этого срока.
2) Сервер отдает браузеру Last-Modified дата а браузер потом посылает серверу заголовок If-Modified-Since дата . В ответ на это сервер может либо ответить 304 Not modified, либо отдать новый контент и новую дату в Last-Modified.
3) Сервер отдает браузеру ETag некий_тег а браузер потом посылает серверу If-None-Match некий_тег . Сервер опять же может ответить 304 или отдать новый контент и новый тег. При этом алгоритм расчета этого некоего_тега никак не стандартизирован и разные сервера создают его разными способами.
Собственно мой вопрос - на чьей стороне, в какой момент времени и по какому правилу должно происходить предсказание etag до фактической загрузки ресурса?
mayorovp
28.08.2022 17:53Ну вот смотрите. Допустим, на странице есть условный тэг вида
<img src=foo etag=bar>. При этом, у клиента (браузера) уже есть в кеше ресурс foo с тэгом bar. В таком случае он может вообще не делать запроса, а сразу показать кешированную картинку.
ivan386
28.08.2022 18:17Выше уже предложили использовать для этой цели не etag а integrity (Subresource Integrity) атрибут который уже используется для скриптов и стилей но не для кеширования.
pae174
28.08.2022 18:28-1Настройте сервер так, что бы он в ответ на запрос /foo отдавал бы только Expires через_сто_лет и браузер не будет перезапрашивать этот ваш /foo целых сто лет (ну или до тех пор, пока /foo не будет выкинут из кэша браузера по каким-то причинам).
mayorovp
28.08.2022 21:14Ага, а если таки foo изменится — то уведомить об этом клиента уже не получится
pae174
28.08.2022 21:33То есть вы хотите что бы закэшированный контент /foo оставался бы в кэше до тех пор, пока сервер каким-то образом не выкинет его оттуда сам по своей инициативе, так что ли?
mayorovp
29.08.2022 10:43Это не я хочу, этого хотят все кто хоть раз задумывался об оптимальном кешировании.
ris58h
29.08.2022 10:52Он хочет, чтобы сервер увидел, что его просят загрузить картинку с какими-то путём и хешем и, если в кеше есть картинка с таким путём и кешем, взял бы её из кеша.
php7
26.08.2022 19:37Вот есть канал 100МБит/с
Это примерно [8.7к пакетов по 1500 байт]/с
А если слать пакеты по 150 байт, это будет 87к пакетов/с? Или так же 8.7к?
andreymal
26.08.2022 20:03В теории в идеальной сети да, но на практике у меня между Петербургом и Москвой в iperf3 с пакетами по 150 байт получились 52% потерь пакетов (по 400 байт — 16% потерь, по 600 байт — 7% потерь, по 800 байт — 4% потерь, по 1000 байт — 3% потерь)
arheops
26.08.2022 22:31А чего это у вас внутри страны 3% потерь пакетов? Вроде как больше 1% — можно жаловаться провайдеру, не?
andreymal
26.08.2022 22:40Не знаю, как провайдеры должны реагировать на запредельное число пакетов, но если не выпендриваться и ставить размер 1500 (точнее 1460) байт, то потерь нет, так что всё нормально, наверное?
arheops
26.08.2022 22:58Неа, вдруг у вас VOIP просто. Потери больше 1% почти всеми провайдерам воспринимаются как «надо чинить». А тут на 1000 байт 3%.
andreymal
26.08.2022 23:30А тут на 1000 байт 3%.
Ну, если не жестить и прописать чуть более скромные хотелки (скорость 92 мегабита), то потери пропадают. Но при размере пакета 150 байт потери пропадают только на скорости 25 мегабит, так что не надо слишком мелкие пакеты слать)
arheops
26.08.2022 23:33+1А, так это у вас просто кривой шейпер или роутер не умеющий много пакетов. Так бывает.
cepera_ang
27.08.2022 18:27Да, скорее всего просто роутер не потянул, причём скорее всего собственный же домашний (или на втором конце).
arheops
26.08.2022 22:30К пакетам по 150 байт добавятся еще куча заголовков в процесе пересылки.
Вообще обычно выгодно посылать как раз пакеты побольше. Кроме случая, когда у вас протокол и контент переживут потери чего-то в средине и совсем уж убитый канал.
pae174
28.08.2022 14:39это будет 87к пакетов/с? Или так же 8.7к
Зависит от возможностей сетевой карты и промежуточного оборудования так как у каждого пакета есть заголовок, обрабатывать который оборудование должно независимо от размера полезной нагрузки в этом пакете.
Helltraitor
26.08.2022 19:42-1Загрузчик 512 байт, размер TCP пакта 16 кб. Может стоит обновить стандарты?
rzerda
26.08.2022 20:23+1Ну обновите Вы стандарты, а оборудование во всём мире кто и за чей счёт будет обновлять?
rzerda
26.08.2022 20:32+8Я аж в календарь посмотрел от этой статьи. Это всё в вебе было интересно до примерно середины 2010-х, пока массово не приехал HTTPS и HTTP/2. При этом прямо в самой статье есть ссылка на «более глубокий анализ», в котором с дампами трафика поясняется, почему эта статья вредная.
Дорогие товарищи! Не верьте во всякие «вот как я увеличила свой бюст на шесть дюймов», профилируйте и измеряйте эффекты сами, в компьютерах это сравнительно дёшево.
nuclight
28.08.2022 05:36А что, initial cwnd в них как-то изменился? Он и в QUIC такой же.
rzerda
28.08.2022 07:47Никак не изменился, просто проблемы с быстродействием в вебе стали богаче, чем «давайте сэкономим один rtt на первом холодном заходе». Тот же набор сертификатов TLS легко может быть 5 килобайт, но оригинальный автор прямо в 2022 году пишет, что TLS используется «иногда». Пример с мобильными сетями отличный, но там кроме задержки ещё и потери есть, до состояния «в соединении с полумегабайтом переданных данных никогда не было cwnd больше 10».
В общем, статья на мой вкус «пропишите вот это в sysctl и будет счастье». Буквально все ссылки в статье лучше, чем сама статья, потому что там либо HPBN, либо дампы трафика и утилиты для анализа происходящего.
tohntobshi
26.08.2022 20:57+1Мне кажется, на сайт, который реально имеет какую-то ценность, заходить будут в любом случае, какой бы медленный и убогий UX у него бы не был, алиэкспресс тому пример. А бесполезный ресурс никакие оптимизации не спасут, как бы он не летал.
PavlovM
27.08.2022 08:12+5Между крайностями "сайт, который делает что-то жизненно важное и на который зайдут при любом раскладе" и "барахло, о котором никто не узнает в любом случае" существует множество остальных сайтов, у которых есть конкуренты и которые очень заботятся о скорости загрузки для удобства пользователей.
И поисковики, кстати, ее в ранжировании тоже учитывают.
Areso
26.08.2022 21:30Хочу напомнить, что существует офигенный ежегодный https://js13kgames.com/ , который уже идёт и будет идти до 13-го числа!
Больше игр, хороших и разных. И да, умещающихся в 13К!
Slavik7
27.08.2022 05:05А какие есть способы отладки всего это счастья? Могу я как-то научить браузер после загрузки первых 14кб останавливаться, чтобы посмотреть, что получилось? И заодно узнать, отдает ли веб-сервер 14кб или больше в качестве первой пачки.
ToSHiC
27.08.2022 12:27Можно задампить трафик в Wireshark, вас все равно только tcp уровень интересует, контент можно не расшифровывать.
Slavik7
27.08.2022 15:45Как раз интересно посмотреть, как браузер отрендерит эти самые первые 14кб. Вот после прочтения статьи мне стало интересно подготовить заглушку в 14кб для пользователей с плохим интернетом. Как вариант стырить пакеты с wireshark, сохранить в файл, потом открыть в браузере... Но может уже есть готовые более простые варианты для отладки.
nuclight
28.08.2022 05:40Для прикладного программиста это нет смысла отлаживать — оно ж и так работает. Столбиков с временем загрузки и так достаточно.
AlexG37G
27.08.2022 09:14+2Клуб 10 КБ - это коллекция веб-сайтов, размер домашних страниц которых не превышает 10 КБ в сжатом виде.
ggo
27.08.2022 09:27Не увидел как проводили тесты, чем меряли, какие сайты были в выборке, как анализировали результаты. и т.д.
AVX
27.08.2022 16:49Короче, делайте сайты "короче", в смысле избавьте от хлама. Уже лет 8 назад встречал статьи (в т.ч. на хабре), что сайты стали слишком жирные. Майкрософт ком страничка в 150 МБ - как это? И ещё куча таких, весьма популярных. А ведь если https (а оно сейчас поголовно), то при плохом соединении просто всё отваливается по таймауту, когда сайт толстый.
Отдельная песня - перенос нагрузки на клиентов. То есть сайты переносят часть логики в виде скриптов на сторону браузера - и тонны скриптов иногда даже не могут переварить не очень быстрые компьютеры (с одним ядром, например). Как пример - сайты ситилинка, днс, и куча других. Да даже яндекс почта таким грешит, благо, хоть может предоставлять более лёгкий вариант страниц, если что-то не так (если не убрали, давно не проверял).
Сейчас порой в интернет не хочется заходить со смартфона, ибо тормозит половина сайтов, гораздо проще получается прочитать тот же контент в каких-то чатах или каналах телеграм, там всё это же намного быстрее загружается и отображается. Просто все привыкли, что у всех 100 мегабит и комп 8 ядер и 16ГБ оперативки. Разработчикам (или скорее тестировщикам) нужно выдавать для проверки ВМ с одним ядром и 1 гигом памяти, и полосу в 256кбит. Хотя кого я обманываю - в половине случаев никакого тестирования не делают толком! (а, на пользователях и потестим :)
makkarpov
27.08.2022 22:36+3Майкрософт ком страничка в 150 МБ - как это?
Понимаю, что для демонстрации современного бездуховного мира все средства хороши, но можно ли воочию это увидеть?
Hidden text
AVX
27.08.2022 22:55Я эту цифру запомнил с тех времён, сейчас не проверял, каюсь. Может изменилось уже.
psydvl
28.08.2022 02:43+1Было бы неплохо отключить ещё всякие блокировщики и выключить кеш (галочка сверху) и, возможно, запускать вне России, чтоб фейсбук всё смог загрузить
Получится хоть и немного, но больше
makkarpov
28.08.2022 09:25+1Это была чистая загрузка через Ctrl+F5 с чешского адреса (на что намекает cs-cz в заголовке).
Убирание uBlock ничего особо не меняет, было 812kB + 2.8MB, стало 829kB + 2.8MB
pae174
28.08.2022 15:11Получится хоть и немного, но больше
Неа. 2.8 мегабайта в разжатом виде на всё - хомяк, все стили, скрипты и прочее (всего 80 запросов). Чистая установка Firefox на чистой машине c Win10, Амстердам.
cepera_ang
27.08.2022 18:29+1Хорошая цель, уложиться в десять пакетов в мире, где 14 мегабайт на сайте никто не заметит, лол.
doomguy49
28.08.2022 01:21Краткое содержание статьи: лучше – меньше, а ещё вот есть такая константа, равная 14kb
Это, конечно, замечательно, что существует такая константа, но к чему она вообще, если ничто не влезет в неё?
vasyash
28.08.2022 10:07Размер окна разве не во время хэндшейка определяется?
Хэндшейк, а потом только передача http. Мне кажется задержка появляется из-за фрагрментации кадров на промежуточных узлах
TsarS
Я сейчас сделал
ng new projectс Angular — мне больно от вашей статьиRive
Впрочем популярные фреймворки пытаются сильно сжать код сайта с помощью кучи ухищрений (избирательное включение модулей, минификаторы, та же архивация).
Всё содержимое папки node_modules на клиент не пойдёт.
gmtd
Дело совсем в другом
Современные JavaScript фреймворки позволяют сделать SPA и даже PWA
А значит на повторных заходах на сайт первый запрос будет за только json-ом нужных данных - всё остальное будет уже в браузере
Так что тут автор немного сел в лужу с советом не пользоваться клиентскими фреймворками.
0xd34df00d
Я в веб-разработке ничего не понимаю, но разве «обычный сайт» не осядет в кеше, с аналогичным избеганием скачивания при последующих заходах на сайт?
Короче, личный блог мне на фреймворках переписывать или не надо?
gmtd
Зависит от настроек кэширования ресурсов на сервере.
Для ресурсов типа html обычно всё равно идет запрос - изменился ли файл
Данная страница. например, запускает 80 запросов
0xd34df00d
Предположим, что мы всё настроили оптимально (что бы это ни значило). Что тогда получается?
gmtd
Аскетичный сайт-визитку можно засунуть в 14кб index.html, остальные ресурсы закешировать. Тогда подход автора сработает
Блог - вряд ли
От такого минимализма даже олдскульщики уже отошли
0xd34df00d
Ну хз, я свой блог генерю статически из кучи маркдауна, и JS там, считайте, нет.
Но за 14 килобайтами, конечно, не гонюсь, но и без этого — главный html 10 килобайт, главный css 3 килобайта. Потом, правда, ещё немного css на 5 кило, картинок на 4 кило, ну и Fira Code на сотыч.
TimsTims
Можно все разнести на разные dns имена. Тогда браузер будет к ним подключаться в параллели.
vanxant
не советуйте, если не разбираетесь, пожалуйста.
К этим разным dns именам браузер будет делать хэндшейки https, а в случае одного домена - переиспользовать существующее http2/3 соединение
TimsTims
Как-то грубовато прозвучало. Давайте уважать друг друга.
vesper-bot
Не так. В http/2 есть возможность серверу передавать данные в одном соединении как несколько потоков, при этом ни один поток не обязан ждать других. Проблема, какую вы описали, существует в http/1.1.
TimsTims
Спасибо. В изначальном посте не было речи про используемый протокол, значит мои слова всё же были верны для http 1.1.
0xd34df00d
Ну, с одной стороны, если судить по вкладке Network в хромовских «Инструментах разработчика», то там и так всё достаточно параллельно:
С другой — для меня nginx настроить уже проблема, какие там разные dns-имена.
urvanov
Можно внутрь html запихнуть и css, а заодно избавиться от кастомного шрифта. Тогда ещё лучше будет
0xd34df00d
А это интересный вопрос. Тогда ведь целых лишних 3-7 килобайт с каждой страницей будут приходить, которые могли бы быть закешированы.
Целая лишняя секунда на диалапе!Люди в веб-разработке на это всё равно забивают и инлайнят мелкие вещи?
Ну, это шрифт для примеров кода, в котором гарантированно есть весь использованный в коде юникод. Ну и лигатуры там красивые, чего уж.
Плюс, шрифты-то грузятся асинхронно и рендеринг страницы не блокируют, да и кешируются хорошо, поэтому меня это не так сильно волнует.
vanxant
Каждый лишний запрос это дополнительные байты (в http2 от нескольких сотен байт до нескольких килобайт, если страница обвешана куками как новогодняя ёлка), и, что хуже, это дополнительный раундтрип. Поэтому например всякие иконки размером до пары кб выгоднее инлайнить в css. А также инлайнить в html самый базовый css, необходимый для отображения самого первого экрана сайта, ну хотя бы чтобы текст не прыгал по экрану в процессе загрузки.
0xd34df00d
Хм, разумно. Повод запилить инлайнинг ресурсов в hakyll.
alexnozer
В любой системе, будь то Windows, macos, и тд есть набор стандартных шрифтов, причём с щасечками, без засечек и моноширинный (как раз для кода).
Кроме того, шрифты грузятся синхронно, потому что они нужны для отрисовки страницы (браузер по ним считает размеры).
gmtd
Есть варианты как грузятся шрифты
HTML и CSS этим управляют
alexnozer
В HTML можно изменить приоритет загрузки и получить шрифт к моменту, когда парсер CSS его обнаружит. Можно ещё заинлайнить подключение в HTML, тогда он просто будет обнаружен чуть раньше.
Говоря про CSS, там можно лишь влиять на поведение браузера до загрузки шрифта (отображать ли стандартный шрифт, подождать немного или ничего не показывать до окончания загрузки).
Шрифты, конечно, можно загрузить асинхронно, но это уже требует js. Но так не делают, асинхронная загрузка шрифта приводит к перерисовкам (FOUT), а с этим как раз и пытаются бороться вышеуказанными способами в HTML/CSS.
0xd34df00d
Ну и что? В худшем случае у вас будет одна перерисовка [примеров кода] при первом заходе на сайт (или после выкидывания шрифта из кэша). Не вижу в этом особой проблемы.
vanxant
Единственный способ избежать перерисовки - инлайнить шрифт в CSS.
Да-да, через
Все остальные способы приведут к перерисовке и, хуже всего, "прыганию" макета.
alexnozer
Бесспорно можно инлайнить. Только вот base64 от файла со шрифтом будет весить в среднем на 20-30% больше, чем просто файл со шрифтом. 2-3 таких инлайна и размер файла CSS увеличивается, следовательно он дольше загружается и дополнительные (пусть и небольшие) накладные расходы на преобразование. А CSS ресурс блокирующий.
Единственный способ избежать "прыжков" шрифта - использовать system-ui и перечень web-safe шрифтов.
Далее если шрифт сабсетить по набору глифов, использовать unicode-range в сочетании с предзагрузкой, это тоже позволит избежать прыжков в большинстве случаев.
vanxant
именно это нам и требуется
Да, только он передаётся сжатым. А gzip/brottli от base64 от файла будет весить на 0,1% больше. Проверено
Нет, не единственный. Во-первых, указанное вами решение не работает, ну по крайней мере для не-английских сайтов. Во-вторых, описанное мной - единственное, которое работает.
Нет конечно. Вы, прежде чем переписывать методичку твиттора, хотя бы попробуйте заменить какой-нибудь Tactic Sans на системный шрифт.
alexnozer
Ну не знаю... Все пытаются избежать или сократить насколько возможно блокировку основного потока для более быстрого рендеринга страницы. У вас, видимо, свой путь, если вам блокировка нужна. Интересно ваше мнение, зачем она нужна.
Попробую на досуге проверить. Однако даже от самых заядлых оптимизиторов, назовём их так, я таких советов не слышал и никогда в проде такое не встречал.
Не "прыгает" шрифт если его нет. В том смысле, что нет деклараций. Тогда будет использоваться системный шрифт из системы. Причем доя кириллицы тоже. Об этом и речь - если отказаться от кастомных шрифтов, прыжков не будет. Если кастомный шрифт есть, он может не прыгать, если загрузится достаточно быстро.
Твиттер не читаю, тут мимо. Сказанное основывается на моих экспериментах, копании в сайтах и чтении пары публикаций от Adobe (думаю в шрифтах они разбираются лучше нас). Не знаю причём тут замена шрифта tactic sans и сабсеттинг (который подразумевает разделение шрифта на более мелкие сабсеты), о котором я писал в сообщении, которое вы цитируете.
vanxant
А вы, видимо, даже не задавались вопросом, ЗАЧЕМ сокращать блокировку основного потока. Т.е. даже не гуглили, потому что гугл как раз объясняет в первом же ответе, ссылкой на лайтхаус (бывший pagespeed).
будет, да. Но если только вы не сопливый стартапер из ООО "три студента", у вас в конторе есть дизайнер с арт-директором. И они вас за "системный шрифт" просто уволят за профнепригодность.
Ну просто пример, из недавних. Если Times слишком мелкий, то вот этот - очень крупный. И страница без инлайнинга этого шрифта просто кровь-кишки-разваливается при его загрузке, при любом значении font-display
urvanov
В современных ОС шрифты сразу содержат кучу символов, не только английские буквы, но и иероглифы, математические, смайлики и кучу других. Сейчас не 2000-ые
0xd34df00d
Если прыгание не ведёт к тому, что дёргается открытая после загрузки часть, и если загрузка дополнительных шрифтов выполняется достаточно быстро, чтобы пользователь не успел поскроллить после загрузки в случае ссылки на якорь, то в чём проблема с прыганьем?
vanxant
Если у вас всё настолько квадратно-гнездовое, что окончание загрузки шрифта не приводит к изменению размеров элементов на странице, то...
Это всё равно некрасиво!
Вам, возможно, это трудно понять, но остальным 90% населения это очевидно. (
0xd34df00d
Но в них не обязаны быть все нужные символы.
Даже я знаю, что нет.
font-display: swap;, всё такое.CoolCmd
вот это правильно, ведь у пользователей не установлено моноширинного шрифта!
0xd34df00d
Не факт, что в установленном у пользователя моноширинном шрифте есть какой-нибудь ℕ или ∀.
Aleksandr-JS-Developer
0xd34df00d
Это хорошо, но когда я на своих андроидодевайсах открываю кое-какие свои исходники на гитхабе, то там нередки квадратики в тех местах, где квадратиков быть не должно.
urvanov
CoolCmd
мат. символы занимают сотыч?
0xd34df00d
Сотыч килобайт? Да, спокойно.
Я знаю, что там можно как-то выковыривать только используемые глифы, но делать это (и делать это корректно, чтобы шрифт перегенерировался при добавлении нового поста в блог с новыми используемыми закорючками) как-то слишком сложно и неинтересно по сравнению с ожидаемым профитом.
vanxant
Математических, инженерных и научных символов в Юникоде - примерно 5000 штук. Было 20 лет назад.
dynamicult
Суть PWA в том, что при открытии сайта, браузер вообще не пойдет в сеть. Он обратится к сервис-воркеру, который является javascript-приложением, а тот достанет ответ из кэш-стора или вообще его сгенерирует динамически прямо на клиенте. А если захочет, то и обратится в сеть. Таким образом PWA, однажды открытый на клиентском устройcтве, может работать даже без интернета. Сам браузер будет в сети только проверять не обновился ли сервис-вокрер, и если да, то в фоне загружать новую его версию. Все остальные сетевые запросы к сайту в области ответственности установленного воркера, будут проксироваться через него.
При обыкновенном баузерном кэшировании этого не случится. При отсутсвии интернета браузер вам покажет страницу ошибки. А при наличии сети все равно отправит запросы в сеть. Никакими настройками сервера и выставлением нужных заголовков вы не добьетесь поведения аналогичному или хотя бы приближенному к PWA.
Вот пример PWA-приложения. Его достаточно один раз открыть на устройстве, после чего вы можете пользоваться им даже при отсутствии сети.
Сама концепция PWA не нова, как и все хорошо забытое. Не многие помнят такую вещь, как автономные веб-страницы в IE. Это почти то же самое, только более прогрессивное и стандартизированное. Теперь разработчик может сам контролировать эту автономность и программировать её логику.
vanxant
только это всё никак не поможет при первом открытии сайта.
0xd34df00d
А какая там логика для совершенно статического контента? Ну, то есть, я даже не знаю, что там контролировать, и механизм кеширования браузера по идее должен сам отлично справляться.
Собственно, когда я подобные статические сайты без всяких сервис воркеров открываю на планшете, случайно забыв включить вайфай, то они вполне себе отлично показывают кешированную версию (показывая «Оффлайн» в адресной строке, но неважно).
Меньше сотни байт. Это можно пережить:
arheops
Броузер спрашивает не обновилась ли страничка.
Вообще это от настроек кеша зависит, но в современных броузерах именно так. Как минимум для index.html
0xd34df00d
Для меня со стороны попытки спрашивать, не обновилась ли страничка при детектируемом отсутствии соединения, и вывод плашки «нету интернета» при наличии кешированной версии выглядят как недоработка браузера. Почему её должны затыкать 100500 владельцев сайтов вместо двух разработчиков движков — непонятно.
k4ir05
Так браузеры ведут себя в соответсвии с заголовком Cache-Control (и некоторыми другими). Если там указано, что кэш надо перепроверять (must-revalidate, например, и кэши протухли), то они будут это делать. Если разработчик указал, что ресурс неизменяемый, то браузер и не будет перепроверять, а возьмёт из кэша.
mayorovp
Вы как будто на идрисах ничего не писали.
У браузера нет доказательства того, что контент сайта не обновился. Значит, нужен запрос к серверу.
Если разрешать отображение старого контента без доказательств — сайты просто будут "ломаться".
Кстати, можно без всяких сервис воркеров разрешить вечное кеширование, это всего лишь пара заголовков. Недостаток этого способа — в том, что когда вам сайт понадобится-таки обновить — вы замаетесь объяснять пользователям как им почистить кеш их браузера и почему вы не можете сделать так, чтобы этого делать не пришлось.
0xd34df00d
Если бы браузеры доказывали что-то про веб как на идрисах, то они бы ещё HTML 3.2 не реализовали бы.
Если есть возможность сделать запрос — конечно, пусть браузер делает, я ж не против. Но если такой возможности нет (будь то отсутствие интернета, или сам сайт лежит), то отображение старой версии сайта в куче случаев (в подавляющем большинстве?) будет лучше, чем отображение пустой страницы. Особенно если это чисто контентный сайт.
Я это понимаю, и хочу что-то среднее — отображение прокешированной версии, если нет возможности загрузить новую.
dynamicult
Вот я только что открыл ваш блог. Дождался полной его загрзуки. После чего выключил интернет и перезагрузил страницу.
Если бы у вас был сервис-воркер с заскпритованной логикой кэширования, я бы снова увидел контент вашего блога, а не страницу с ошибкой.
То, что браузер на вашем планшете показывает вам страницу из кэша при отстуствии сети - это вольная прихоть самого браузера на мобильном устройстве, а не стандартное поведение. Оно не предсказуемо и не контролируемо, в отличии он концепции PWA.
0xd34df00d
Мой поинт в том, что это разумное поведение, и его разумно ожидать и у других браузеров.
ИМХО стандартной должна быть только семантика, а не, в подавляющем большинстве случаев, презентация или поведение. Презентация (размер шрифтов, шрифт основного текста, или, возможно даже, цветовая гамма) или поведение — это прихоть и удобство пользователя, а не автора сайта, который решил «я так вижу» за всех. Откуда я там знаю, что пользователь хочет? Моё дело — дать ему семантически размеченный контент, а его просмотрщик пусть делает с ним что хочет.
Но, опять же, я не шарю в веб-разработке. Для меня это так, способ записать какие-то свои мыслишки и под настроение побаловаться с CSS как с одной из максимально далёких от моего обычного стека технологий. Может, это всё не имеет смысла.
[ из соседней ветки ]
Блин, сколько буков, чтобы просто сказать браузеру, что кешируемые ресурсы можно, ну, кешировать.
Эх, лучше бы этот ваш гугл добавил и популяризовал какой-нибудь X-Allow-Static-Caching вместо всяких когортных реклам.
k4ir05
Такое поведение разумно, разве что для каких-нибудь блогов, и прочих статичных статей. Но часто бывают случаи, когда нужно показывать именно актуальную страницу (и прочие ресурсы), а не из кэша.
Так для этого уже давно придуманы более простые способы. Эти сервис-воркеры нужны именно для веб-приложений, а не для простых сайтов в виде одной или нескольких статичных страничек.
PsyHaSTe
Что мешает показывать плашку "показать закешированную версию" аналогично с попыткой зайти на сайт с просроченным серитфикатом? А ещё лучше действительно рулить поведением хедером, уж автор сайта наверное знает когда можно использовать его сайт из кэша а когда нельзя. Сколько раз я открывал какой-нибудь блог, а потом у меня ноут обновлялся и в поезде я не мог почитать то что открыл потому что видите ли интернета нет. Да мне плевать что там 3 комментария появилось с тех пор, я их все равно не читаю.
Дедфуд выше прав и ничего не сделать
Ну а простым сайтам как быть? Вот я веду бложик в гитхаб пейджс скажем, я хочу одной строкой задать allow_caching_on_client = true и не хочу писать тонну кода эмулируя все механизмы кэширования которые в хроме наизобретали за последине 20 лет. Что я должен сделать если я хочу чтобы мои странички люди могли читать без интернета?
k4ir05
Ну похожее поведение с кэшем я видел, кажется, в Brave. По поводу сертификата, имхо, это может быть небезопасно в некоторых случаях.
Так автор сайта ведь и рулит хедером. Это всё в настройках веб-сервера указывается.
Размещать их на подконтрольном себе сервере. А так это гитхаб решает, раз он предоставляет к ним доступ. Новые механизмы наизобретали для других целей.
PsyHaSTe
Подскажите тогда пожалуйста каким хедером это рулится. Чтоб настроил и можно в оффлайне смотреть было. Потому что это конечно же идеальный сценарий, который хочется иметь
k4ir05
Полагаю, что
Cache-Control: only-if-cached. Сам этим не пользовался. Можно тут поподробнее почитать.PsyHaSTe
Не нашел only-if-cached или чего-либо похожего по ссылке что вы скинули
k4ir05
Так это общая статья о кэшировании. Значения заголовка Cache-Control есть в справке по нему. Извеняюсь, мой косяк, это значение для запроса. Для ответа должно подойти
immutableV1RuS
RSS
PsyHaSTe
Помню делал поддержку RSS лет 10 назад. Казалось что достаточно удобный и компактный формат, особенно atom (или как они там). Но кажется что оно не очень распространено.
Смысл ведь в том, что все уже готово для этого, нужна галка "вместо грустной рожицы нет интернета покажи хоть что-то". Это не требует целого отдельного формата.
V1RuS
Ну, в таком случае — запилить новый браузер (или очередной форк хромиума). Потому что убедить разработчиков хрома сделать нормально, я думаю, не получится.
vedenin1980
Давно уже есть в стандарте html5 (ниже)
Но ведь есть же cache manifest в html5, пишем в html
и в cache.appcache прописываем все файлы которые нужно кешировать или не кешировать. Все это занимает несколько минут на создание одного файла и одного тега.
Зачем тогда тут нужен PWA?
dynamicult
Нет его уже давно нет и его поддержка в браузерах удалена, именно по причине того, что есть сервис-воркеры.
vedenin1980
Вот за это терпеть не могу веб, невозможно просто сделать один раз сайт и забыть, или выучить, что-то и пользоваться.
Дурная привычка java мира — всегда рассчитывать на сохранение обратной совместимости.
nuclight
Почему дурная и почему java? Во всех нормальных языках так делают — сохраняют совместимость.
PsyHaSTe
Может вы тогда ответите на вопрос из https://habr.com/ru/post/684836/#comment_24670152 (чуть выше задал? Манифест выглядит как штука которая решала эту задачу, а как сделать чтобы сервис воркер решал что-то не понимаю. Можно показать на пальцах, чтобы я такой "ааа понял, как я сразу не догадался"?
mayorovp
Если коротко, то надо сложить вот сюда — https://developer.mozilla.org/en-US/docs/Web/API/Cache — все статические ресурсы, а потом ловить вот это — https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent — и отдавать кешированную версию.
PsyHaSTe
Это кажется сильно больше 1 строчки, нет?..
Кажется что очень многие этого не делают как раз потмоу что это неинтуитивно и нераспространно. Хотя многие блоги выиграли бы от подобного. Почти все собственно, единожды написана инфа не меняется
ivan386
#comment_24668604
PsyHaSTe
Ну это скорее костыль. Потому что нам нужен сценарий:
mayorovp
Насколько я помню, с тем старым механизмом была проблема в том, что непонятно как часто надо запрашивать с сервера сам cache.appcache. И что делать если ссылка на него поменялась.
ivan386
Он же вроде зарашивается браузером каждый раз при новом открытии страницы.
mayorovp
Ну вот и проблема: интернета нет, запросить манифест не получается...
vedenin1980
А в чем проблема-то? Нет интернета — отдавать то, что уже закешировалось с прошлого раза. Какие еще варианты?
Так будет работать с любой системой.
ivan386
Сайт отображается из кеша сразу. Паралельно делается запрос манифеста. Если он изменился то в фоне подгружается новая версия сайта. Если манифест не изменился или не доступен то не обновляется.
ivan386
Была технология по проще которую к сожалению таки выпилили из браузеров. Называлась application cache которая позволяла тоже самое без единой строчки Javascript.
Альтернативой теперь осталось вечное кеширование(Cache-Control: immutable) которое не удобно делать для главной страницы сайта. Ну и так-же недостатком этого HTTP заголовка является то что если мы хотим чтобы пользователь получил новые данные вместо закешированных то надо их запрашивать по другому URL.
dynamicult
Если вы хотите контролировать кэширование и доступность вашего блога на клиенте, вам совершенно не обязательно переписывать его на что-либо.
Достаточно написать один единственный скрипт ServiceWorker со всей нужной логикой обработки запросов и сохранением чего-либо в кэш. Как и все остальное в вебе это можно делать без использования сторонних инструментов.
0xd34df00d
Давайте помедленнее, я глупый и не осилил JS.
У меня есть страница, она состоит из чистого HTML и CSS. Вот прям сервер отдаёт клиенту HTML. Куда мне тут воткнуть Service Worker и какие запросы он будет обрабатывать? Чем его кэш принципиально лучше кэша браузера?
dynamicult
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
superconductor
Не умаляя достоинств PWA и сервис-воркеров, не могу не отметить, что использование сервис-воркеров вряд ли оправдано для простых статичных визиток, т.к.:
сервис-воркер добавляет сложность - как минимум заставляет думать про совместимость версий приложения, воркера и бэкендного api,
даже при наличии воркера необходимо скачать всю статику и положить в Кеш,
у особенных пользователей какая-то часть статики может в Кеш не поместиться, и это тоже надо корректно обработать,
неудачно поставленный сервис-воркер может замедлить выполнение запросов к сайту,
на медленных устройствах сходить в сеть может быть быстрее, чем прочитать-с-диска-воркер-выполнить-прочитать-с-диска-статику-повторить-для-всех-запросов.
Т.е. это не лекарство от медленной сети, а гибкий инструмент для определенных потребностей.
vedenin1980
И есть CACHE MANIFEST который легко и прозрачно позволяет настроить кеширование статических сайтов.
dynamicult
AppCache давным давно DEPRECATED и не поддерживается браузерами. https://caniuse.com/offline-apps
k4ir05
Но ведь в статье речь идёт о веб приложениях (web application), а не о статичных сайтах.
Moskus
Вам очень хочется выиграть в игру "поймай другого на слове", но это не выйдет, потому что автор статьи не делал никаких глупых абсолютных утверждений, а описал конкретный механизм, который зависит от передаваемого клиенту объёма, но не зависит от содержимого этого объёма. Он не отрицал эффект кэширования. Потому что даже когда у клиента что-то уже лежит в кэше, всё равно есть какие-то "первые 14Кб" и последующие данные. А как уж распорядиться этим знанием в разных ситуациях - вопрос предпочтений разработчика.
gmtd
Я не собирался никого ловить на слове. Просто заявлю
Для 99.999% вебразработчиков информация от автора не имеет практического резона (они ею не будут пользоваться)
Следовательно эти изыскания чисто теоретические
Фреймворки (которые как раз работают на практике) намного намного лучше решают проблему быстрого открывания современных! сайтов (не "хэлло ворлд"), чем данный подход
Можно, конечно, интегрировать сферического коня в вакууме, но если нужно будет делать сайт, то пригодятся фреймворки, а не советы автора
Под "фреймворками" в данном случае имеется ввиду Serviсe Workers и концепция SPA
Хотя соглашусь, если в самом начале показывать самодостаточную страницу-лоадер, то при первом заходе на сайт алгоритм автора имеет смысл
Но эта страница - не веб-сайт (см. заголовок)
ivan386
Если бы они лучше решали эту проблему сайты бы не тормозили. А так я часто замечаю длительные прогрузки там где казалось бы получил JSON и отобразил данные. Но нет. При этом похоже JavaScript перелопачивает всю страницу заново и уже от скорости интернета это не зависит. Тормозят уже скрипты.
gmtd
Программер с кривыми руками и на чистом javascript-e сделает тормознутый сайт
В сети хватает быстрых удобных богатых по функционалу сайтов на фреймворках
0x131315
Чтобы решать такие проблемы, на это нужен бюджет, и опытная (дорогая) команда - такие условия имеют всего несколько процентов сайтов на рынке.
Поэтому и имеем то, что наблюдаем. Заказчик хочет платить исключительно за функционал, и ничего более оплачивать не намерен, он экономит каждую копейку. Оптимизация получается в основном по остаточному принципу: что-то, что явно мешает работе функционала конечно будет исправлено, но то, что невооруженным глазом не видно, предпочтут оставить как есть и не тратить на это деньги.
И все бы ничего, но заказчики проверяют свои сайты из Москвы/Питера, т.е. из крупных хабов вблизи датацентров, с толстыми каналами и минимальными пингами. Не удивительно, что даже очень тяжелые и плохо сделанные сайты показывают неплохие результаты. В результате большинство реальных проблем не замечаются или списываются как незначительные.
О том ,что работу сайтов нужно проверять не только из столиц, но и из отдаленных точек страны, тут уже не раз писали. У значительной части посетителей нет высокоскоростных стабильных каналов, но мало кто из них будет жаловаться - проблемы так и остаются нерешенными, наладить качественную обратную связь у многих просто не получается. А ведь в условиях нестабильной связи роль играют не только задержки и скорость соединения, проблемы кратно усугубляются сетевыми проблемами и особенностями протоколов, о чем хорошо написано тут
Moskus
Вы сказали, что автор "сел в лужу", при этом вы используете аргумент "соломенное чучело", споря с тем, что автор не утверждал. Это ни что иное, как попытка поймать на слове.