Comments 204
Я сейчас сделал ng new project с Angular — мне больно от вашей статьи
Впрочем популярные фреймворки пытаются сильно сжать код сайта с помощью кучи ухищрений (избирательное включение модулей, минификаторы, та же архивация).
Всё содержимое папки node_modules на клиент не пойдёт.
Дело совсем в другом
Современные JavaScript фреймворки позволяют сделать SPA и даже PWA
А значит на повторных заходах на сайт первый запрос будет за только json-ом нужных данных - всё остальное будет уже в браузере
Так что тут автор немного сел в лужу с советом не пользоваться клиентскими фреймворками.
Зависит от настроек кэширования ресурсов на сервере.
Для ресурсов типа html обычно всё равно идет запрос - изменился ли файл
Данная страница. например, запускает 80 запросов
Аскетичный сайт-визитку можно засунуть в 14кб index.html, остальные ресурсы закешировать. Тогда подход автора сработает
Блог - вряд ли
От такого минимализма даже олдскульщики уже отошли
Можно все разнести на разные dns имена. Тогда браузер будет к ним подключаться в параллели.
не советуйте, если не разбираетесь, пожалуйста.
К этим разным dns именам браузер будет делать хэндшейки https, а в случае одного домена - переиспользовать существующее http2/3 соединение
а в случае одного домена — переиспользовать существующее http2/3 соединениеОднако если файлов будет сотни, то это одно соединение, даже по QUIC, будет закачивать файлы по одному. В таком случае, параллельные соединения на разные (штук 5) доменов даже с учётом хэндшейков выигрывают. Не так ли?
не советуйте, если не разбираетесь, пожалуйста.Как-то грубовато прозвучало. Давайте уважать друг друга.
Можно внутрь html запихнуть и css, а заодно избавиться от кастомного шрифта. Тогда ещё лучше будет
Люди в веб-разработке на это всё равно забивают и инлайнят мелкие вещи?
Каждый лишний запрос это дополнительные байты (в http2 от нескольких сотен байт до нескольких килобайт, если страница обвешана куками как новогодняя ёлка), и, что хуже, это дополнительный раундтрип. Поэтому например всякие иконки размером до пары кб выгоднее инлайнить в css. А также инлайнить в html самый базовый css, необходимый для отображения самого первого экрана сайта, ну хотя бы чтобы текст не прыгал по экрану в процессе загрузки.
В любой системе, будь то Windows, macos, и тд есть набор стандартных шрифтов, причём с щасечками, без засечек и моноширинный (как раз для кода).
Кроме того, шрифты грузятся синхронно, потому что они нужны для отрисовки страницы (браузер по ним считает размеры).
Есть варианты как грузятся шрифты
HTML и CSS этим управляют
В HTML можно изменить приоритет загрузки и получить шрифт к моменту, когда парсер CSS его обнаружит. Можно ещё заинлайнить подключение в HTML, тогда он просто будет обнаружен чуть раньше.
Говоря про CSS, там можно лишь влиять на поведение браузера до загрузки шрифта (отображать ли стандартный шрифт, подождать немного или ничего не показывать до окончания загрузки).
Шрифты, конечно, можно загрузить асинхронно, но это уже требует js. Но так не делают, асинхронная загрузка шрифта приводит к перерисовкам (FOUT), а с этим как раз и пытаются бороться вышеуказанными способами в HTML/CSS.
Единственный способ избежать перерисовки - инлайнить шрифт в CSS.
Да-да, через
@font-face {
font-family: 'Open Sans';
font-style : normal;
font-weight: 400;
src : url("data:application/font-woff2;charset=utf-8;base64,d09GMgA......
}Все остальные способы приведут к перерисовке и, хуже всего, "прыганию" макета.
Бесспорно можно инлайнить. Только вот base64 от файла со шрифтом будет весить в среднем на 20-30% больше, чем просто файл со шрифтом. 2-3 таких инлайна и размер файла CSS увеличивается, следовательно он дольше загружается и дополнительные (пусть и небольшие) накладные расходы на преобразование. А CSS ресурс блокирующий.
Единственный способ избежать "прыжков" шрифта - использовать system-ui и перечень web-safe шрифтов.
Далее если шрифт сабсетить по набору глифов, использовать unicode-range в сочетании с предзагрузкой, это тоже позволит избежать прыжков в большинстве случаев.
CSS ресурс блокирующий
именно это нам и требуется
base64 от файла со шрифтом будет весить в среднем на 20-30% больше
Да, только он передаётся сжатым. А gzip/brottli от base64 от файла будет весить на 0,1% больше. Проверено
Единственный способ избежать "прыжков" шрифта - использовать system-ui и перечень web-safe шрифтов.
Нет, не единственный. Во-первых, указанное вами решение не работает, ну по крайней мере для не-английских сайтов. Во-вторых, описанное мной - единственное, которое работает.
Далее если шрифт сабсетить по набору глифов, использовать unicode-range в сочетании с предзагрузкой, это тоже позволит избежать прыжков
Нет конечно. Вы, прежде чем переписывать методичку твиттора, хотя бы попробуйте заменить какой-нибудь Tactic Sans на системный шрифт.
именно это нам и требуется
Ну не знаю... Все пытаются избежать или сократить насколько возможно блокировку основного потока для более быстрого рендеринга страницы. У вас, видимо, свой путь, если вам блокировка нужна. Интересно ваше мнение, зачем она нужна.
Да, только он передаётся сжатым. А gzip/brottli от base64 от файла будет весить на 0,1% больше. Проверено
Попробую на досуге проверить. Однако даже от самых заядлых оптимизиторов, назовём их так, я таких советов не слышал и никогда в проде такое не встречал.
Нет, не единственный. Во-первых, указанное вами решение не работает, ну по крайней мере для не-английских сайтов. Во-вторых, описанное мной - единственное, которое работает.
Не "прыгает" шрифт если его нет. В том смысле, что нет деклараций. Тогда будет использоваться системный шрифт из системы. Причем доя кириллицы тоже. Об этом и речь - если отказаться от кастомных шрифтов, прыжков не будет. Если кастомный шрифт есть, он может не прыгать, если загрузится достаточно быстро.
Нет конечно. Вы, прежде чем переписывать методичку твиттора, хотя бы попробуйте заменить какой-нибудь Tactic Sans на системный шрифт.
Твиттер не читаю, тут мимо. Сказанное основывается на моих экспериментах, копании в сайтах и чтении пары публикаций от Adobe (думаю в шрифтах они разбираются лучше нас). Не знаю причём тут замена шрифта tactic sans и сабсеттинг (который подразумевает разделение шрифта на более мелкие сабсеты), о котором я писал в сообщении, которое вы цитируете.
Все пытаются избежать или сократить насколько возможно блокировку основного потока для более быстрого рендеринга страницы. У вас, видимо, свой путь
А вы, видимо, даже не задавались вопросом, ЗАЧЕМ сокращать блокировку основного потока. Т.е. даже не гуглили, потому что гугл как раз объясняет в первом же ответе, ссылкой на лайтхаус (бывший pagespeed).
будет использоваться системный шрифт из системы.
будет, да. Но если только вы не сопливый стартапер из ООО "три студента", у вас в конторе есть дизайнер с арт-директором. И они вас за "системный шрифт" просто уволят за профнепригодность.
Не знаю причём тут замена шрифта tactic sans и сабсеттинг
Ну просто пример, из недавних. Если Times слишком мелкий, то вот этот - очень крупный. И страница без инлайнинга этого шрифта просто кровь-кишки-разваливается при его загрузке, при любом значении font-display
А вы, видимо, даже не задавались вопросом, ЗАЧЕМ сокращать блокировку основного потока. Т.е. даже не гуглили, потому что гугл как раз объясняет в первом же ответе, ссылкой на лайтхаус (бывший pagespeed).
Я знаю, зачем нужно сокращать время блокировки потока. Но это вы пишите что это (блокировка потока) нам (кому?) и нужно. Из вашего ответа я делаю вывод, что вам нужна блокировка, что вызывает у меня недоумение и вопрос "зачем".
будет, да. Но если только вы не сопливый стартапер из ООО "три студента", у вас в конторе есть дизайнер с арт-директором. И они вас за "системный шрифт" просто уволят за профнепригодность.
Так мы, кажется, говорим в вакууме о возможностях оптимизации работы со шрифтами, а не о конкретном сайте. И отказ от шрифта это один из способов. И вполне годится для личного блога или чего-то такого. Для случаев с брендбуком и дизайнерами есть другие решения, о которых я говорил.
Ну просто пример, из недавних. Если Times слишком мелкий, то вот этот - очень крупный. И страница без инлайнинга этого шрифта просто кровь-кишки-разваливается при его загрузке, при любом значении font-display
А где я про замену говорю? Сабсеттинг это разбиение большого файла шрифта, допустим с 400 глифами, на несколько файлов с меньшим количеством глифов и подключением его через свойство unicode-range. В итоге если на странице нет ни одного символа из сабсета, файл просто не будет загружаться. Возможно это то, что вам нужно.
Сабсеттинг это разбиение большого файла шрифта, допустим с 400 глифами, на несколько файлов с меньшим количеством глифов и подключением его через свойство unicode-range. В итоге если на странице нет ни одного символа из сабсета, файл просто не будет загружаться.
К сожалению, это красиво звучит в теории (зачем нам загружать глифы арабской вязи или иероглифов), но не работает на практике.
На практике у нас есть связка Latin-1 + Cyr. От первого мы отказаться не можем, потому что там цифры, знаки препинания и т.д. От второго, собственно, тоже. Соответственно, грузить приходится оба.
Но, формат woff2 умеет объединять глифы, т.е. русская "С" и английская "С" будут ссылаться на один глиф, а чешская Č на два. И, конкретно, если мы берём Open Sans 400 regular, то latin-1 файл весит 14400 байт, cyr - 9400, а вот объединённый файл с обоими страницами 17852 байта, а не 23800 (и это не считая доп. расходов на второй http-запрос).
Согласен, есть такой момент с объединением. Но если ваш ресурс на русском, можно сделать свой сабсет кириллицы, но ещё добавить в него цифры, знаки препинания и прочие подобные символы. А латиницу сделать другим сабсетом на случай англоязычных надписей, но без знаков препинания, цифр. Тогда если на странице нет латиницы, она не загрузится (при условии грамотного указания unicide-range). Ну а если есть, чтож, догрузится и она.
Но если у вас гарантировано на странице будет кириллица+знаки и латиница, тогда и делить смысла нет, это справедливо.
ну по крайней мере для не-английских сайтов
В современных ОС шрифты сразу содержат кучу символов, не только английские буквы, но и иероглифы, математические, смайлики и кучу других. Сейчас не 2000-ые
Да, только автор сайта не знает, какие именно шрифты и диапазоны символов есть на конкретном девайсе. Там сломано вообще всё, что только можно сломать - serif/sans-serif, @ font-face src: local(), всё. Вместо font-family: sans-serif вам нужно писать что-то вроде system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif
ну и Fira Code на сотыч.
вот это правильно, ведь у пользователей не установлено моноширинного шрифта!
только это всё никак не поможет при первом открытии сайта.
Вообще это от настроек кеша зависит, но в современных броузерах именно так. Как минимум для index.html
Так браузеры ведут себя в соответсвии с заголовком Cache-Control (и некоторыми другими). Если там указано, что кэш надо перепроверять (must-revalidate, например, и кэши протухли), то они будут это делать. Если разработчик указал, что ресурс неизменяемый, то браузер и не будет перепроверять, а возьмёт из кэша.
Вы как будто на идрисах ничего не писали.
У браузера нет доказательства того, что контент сайта не обновился. Значит, нужен запрос к серверу.
Если разрешать отображение старого контента без доказательств — сайты просто будут "ломаться".
Кстати, можно без всяких сервис воркеров разрешить вечное кеширование, это всего лишь пара заголовков. Недостаток этого способа — в том, что когда вам сайт понадобится-таки обновить — вы замаетесь объяснять пользователям как им почистить кеш их браузера и почему вы не можете сделать так, чтобы этого делать не пришлось.
Мой поинт в том, что это разумное поведение, и его разумно ожидать и у других браузеров.
Такое поведение разумно, разве что для каких-нибудь блогов, и прочих статичных статей. Но часто бывают случаи, когда нужно показывать именно актуальную страницу (и прочие ресурсы), а не из кэша.
Блин, сколько буков, чтобы просто сказать браузеру, что кешируемые ресурсы можно, ну, кешировать.
Так для этого уже давно придуманы более простые способы. Эти сервис-воркеры нужны именно для веб-приложений, а не для простых сайтов в виде одной или нескольких статичных страничек.
Такое поведение разумно, разве что для каких-нибудь блогов, и прочих статичных статей. Но часто бывают случаи, когда нужно показывать именно актуальную страницу (и прочие ресурсы), а не из кэша.
Что мешает показывать плашку "показать закешированную версию" аналогично с попыткой зайти на сайт с просроченным серитфикатом? А ещё лучше действительно рулить поведением хедером, уж автор сайта наверное знает когда можно использовать его сайт из кэша а когда нельзя. Сколько раз я открывал какой-нибудь блог, а потом у меня ноут обновлялся и в поезде я не мог почитать то что открыл потому что видите ли интернета нет. Да мне плевать что там 3 комментария появилось с тех пор, я их все равно не читаю.
Дедфуд выше прав и ничего не сделать
Так для этого уже давно придуманы более простые способы. Эти сервис-воркеры нужны именно для веб-приложений, а не для простых сайтов в виде одной или нескольких статичных страничек.
Ну а простым сайтам как быть? Вот я веду бложик в гитхаб пейджс скажем, я хочу одной строкой задать allow_caching_on_client = true и не хочу писать тонну кода эмулируя все механизмы кэширования которые в хроме наизобретали за последине 20 лет. Что я должен сделать если я хочу чтобы мои странички люди могли читать без интернета?
Что мешает показывать плашку "показать закешированную версию" аналогично с попыткой зайти на сайт с просроченным серитфикатом?
Ну похожее поведение с кэшем я видел, кажется, в Brave. По поводу сертификата, имхо, это может быть небезопасно в некоторых случаях.
А ещё лучше действительно рулить поведением хедером, уж автор сайта наверное знает когда можно использовать его сайт из кэша а когда нельзя.
Так автор сайта ведь и рулит хедером. Это всё в настройках веб-сервера указывается.
Ну а простым сайтам как быть? Вот я веду бложик в гитхаб пейджс скажем, я хочу одной строкой задать allow_caching_on_client = true и не хочу писать тонну кода эмулируя все механизмы кэширования которые в хроме наизобретали за последине 20 лет. Что я должен сделать если я хочу чтобы мои странички люди могли читать без интернета?
Размещать их на подконтрольном себе сервере. А так это гитхаб решает, раз он предоставляет к ним доступ. Новые механизмы наизобретали для других целей.
Так автор сайта ведь и рулит хедером. Это всё в настройках веб-сервера указывается.
Подскажите тогда пожалуйста каким хедером это рулится. Чтоб настроил и можно в оффлайне смотреть было. Потому что это конечно же идеальный сценарий, который хочется иметь
Полагаю, что Cache-Control: only-if-cached. Сам этим не пользовался. Можно тут поподробнее почитать.
Не нашел only-if-cached или чего-либо похожего по ссылке что вы скинули
Так это общая статья о кэшировании. Значения заголовка Cache-Control есть в справке по нему. Извеняюсь, мой косяк, это значение для запроса. Для ответа должно подойти immutable
Что я должен сделать если я хочу чтобы мои странички люди могли читать без интернета?
RSS
Помню делал поддержку RSS лет 10 назад. Казалось что достаточно удобный и компактный формат, особенно atom (или как они там). Но кажется что оно не очень распространено.
Смысл ведь в том, что все уже готово для этого, нужна галка "вместо грустной рожицы нет интернета покажи хоть что-то". Это не требует целого отдельного формата.
Эх, лучше бы этот ваш гугл добавил и популяризовал какой-нибудь X-Allow-Static-Caching вместо всяких когортных реклам.
Давно уже есть в стандарте html5 (ниже)
Оно не предсказуемо и не контролируемо, в отличии он концепции PWA.
Но ведь есть же cache manifest в html5, пишем в html
<html manifest="/cache.appcache" >и в cache.appcache прописываем все файлы которые нужно кешировать или не кешировать. Все это занимает несколько минут на создание одного файла и одного тега.
Зачем тогда тут нужен PWA?
Дурная привычка java мира — всегда рассчитывать на сохранение обратной совместимости.
Может вы тогда ответите на вопрос из https://habr.com/ru/post/684836/#comment_24670152 (чуть выше задал? Манифест выглядит как штука которая решала эту задачу, а как сделать чтобы сервис воркер решал что-то не понимаю. Можно показать на пальцах, чтобы я такой "ааа понял, как я сразу не догадался"?
Если коротко, то надо сложить вот сюда — https://developer.mozilla.org/en-US/docs/Web/API/Cache — все статические ресурсы, а потом ловить вот это — https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent — и отдавать кешированную версию.
Это кажется сильно больше 1 строчки, нет?..
Кажется что очень многие этого не делают как раз потмоу что это неинтуитивно и нераспространно. Хотя многие блоги выиграли бы от подобного. Почти все собственно, единожды написана инфа не меняется
Альтернативой теперь осталось вечное кеширование(Cache-Control: immutable) которое не удобно делать для главной страницы сайта. Ну и так-же недостатком этого HTTP заголовка является то что если мы хотим чтобы пользователь получил новые данные вместо закешированных то надо их запрашивать по другому URL.
Насколько я помню, с тем старым механизмом была проблема в том, что непонятно как часто надо запрашивать с сервера сам cache.appcache. И что делать если ссылка на него поменялась.
Он же вроде зарашивается браузером каждый раз при новом открытии страницы.
Ну вот и проблема: интернета нет, запросить манифест не получается...
Так будет работать с любой системой.
Сайт отображается из кеша сразу. Паралельно делается запрос манифеста. Если он изменился то в фоне подгружается новая версия сайта. Если манифест не изменился или не доступен то не обновляется.
Таким образом PWA, однажды открытый на клиентском устройcтве, может работать даже без интернета.
Была технология по проще которую к сожалению таки выпилили из браузеров. Называлась application cache которая позволяла тоже самое без единой строчки Javascript.
Альтернативой теперь осталось вечное кеширование(Cache-Control: immutable) которое не удобно делать для главной страницы сайта. Ну и так-же недостатком этого HTTP заголовка является то что если мы хотим чтобы пользователь получил новые данные вместо закешированных то надо их запрашивать по другому URL.
Не умаляя достоинств PWA и сервис-воркеров, не могу не отметить, что использование сервис-воркеров вряд ли оправдано для простых статичных визиток, т.к.:
сервис-воркер добавляет сложность - как минимум заставляет думать про совместимость версий приложения, воркера и бэкендного api,
даже при наличии воркера необходимо скачать всю статику и положить в Кеш,
у особенных пользователей какая-то часть статики может в Кеш не поместиться, и это тоже надо корректно обработать,
неудачно поставленный сервис-воркер может замедлить выполнение запросов к сайту,
на медленных устройствах сходить в сеть может быть быстрее, чем прочитать-с-диска-воркер-выполнить-прочитать-с-диска-статику-повторить-для-всех-запросов.
Т.е. это не лекарство от медленной сети, а гибкий инструмент для определенных потребностей.
Вам очень хочется выиграть в игру "поймай другого на слове", но это не выйдет, потому что автор статьи не делал никаких глупых абсолютных утверждений, а описал конкретный механизм, который зависит от передаваемого клиенту объёма, но не зависит от содержимого этого объёма. Он не отрицал эффект кэширования. Потому что даже когда у клиента что-то уже лежит в кэше, всё равно есть какие-то "первые 14Кб" и последующие данные. А как уж распорядиться этим знанием в разных ситуациях - вопрос предпочтений разработчика.
Я не собирался никого ловить на слове. Просто заявлю
Для 99.999% вебразработчиков информация от автора не имеет практического резона (они ею не будут пользоваться)
Следовательно эти изыскания чисто теоретические
Фреймворки (которые как раз работают на практике) намного намного лучше решают проблему быстрого открывания современных! сайтов (не "хэлло ворлд"), чем данный подход
Можно, конечно, интегрировать сферического коня в вакууме, но если нужно будет делать сайт, то пригодятся фреймворки, а не советы автора
Под "фреймворками" в данном случае имеется ввиду Serviсe Workers и концепция SPA
Хотя соглашусь, если в самом начале показывать самодостаточную страницу-лоадер, то при первом заходе на сайт алгоритм автора имеет смысл
Но эта страница - не веб-сайт (см. заголовок)
Если бы они лучше решали эту проблему сайты бы не тормозили. А так я часто замечаю длительные прогрузки там где казалось бы получил JSON и отобразил данные. Но нет. При этом похоже JavaScript перелопачивает всю страницу заново и уже от скорости интернета это не зависит. Тормозят уже скрипты.
Программер с кривыми руками и на чистом javascript-e сделает тормознутый сайт
В сети хватает быстрых удобных богатых по функционалу сайтов на фреймворках
Чтобы решать такие проблемы, на это нужен бюджет, и опытная (дорогая) команда - такие условия имеют всего несколько процентов сайтов на рынке.
Поэтому и имеем то, что наблюдаем. Заказчик хочет платить исключительно за функционал, и ничего более оплачивать не намерен, он экономит каждую копейку. Оптимизация получается в основном по остаточному принципу: что-то, что явно мешает работе функционала конечно будет исправлено, но то, что невооруженным глазом не видно, предпочтут оставить как есть и не тратить на это деньги.
И все бы ничего, но заказчики проверяют свои сайты из Москвы/Питера, т.е. из крупных хабов вблизи датацентров, с толстыми каналами и минимальными пингами. Не удивительно, что даже очень тяжелые и плохо сделанные сайты показывают неплохие результаты. В результате большинство реальных проблем не замечаются или списываются как незначительные.
О том ,что работу сайтов нужно проверять не только из столиц, но и из отдаленных точек страны, тут уже не раз писали. У значительной части посетителей нет высокоскоростных стабильных каналов, но мало кто из них будет жаловаться - проблемы так и остаются нерешенными, наладить качественную обратную связь у многих просто не получается. А ведь в условиях нестабильной связи роль играют не только задержки и скорость соединения, проблемы кратно усугубляются сетевыми проблемами и особенностями протоколов, о чем хорошо написано тут
Вы сказали, что автор "сел в лужу", при этом вы используете аргумент "соломенное чучело", споря с тем, что автор не утверждал. Это ни что иное, как попытка поймать на слове.
То есть нужно иметь каждый файл не более 14кБ чтобы всё работало фить-фить. При этом картинки такого размера найти нереально, вместо них lazy load ?
Как раз вчера смотрел интервью с мужиком, нехило шарящим в подобном, который обьяснял, почему CDN - просто маркетинговая пыль в глаза тем, кто не понимает техчасти.
А ссылки у вас не сохранилось? Интересно посмотреть.
Он просто не умеет готовить CDN
Я так понимаю, это правда только в случае когда статика (картинки, скрипты, стили) раздаются тем же сервером что и сама страница (html) - тогда браузер может переиспользовать tcp соединение и не тратить время на открытие нового.
Но в случаи нагруженных сервисов (или больших объемов) статика чаще всего где-то на другом сервере (AWS S3, GCS, ...) и тут не вижу проблем в CDN
поправьте меня если я не прав
Именно так. Или когда сервер и ЦА находятся в противоположных частях света или разбросаны по миру, также защита от DDOS. Тогда да, однозначно должно быть. В противных случаях в этом нет смысла и даже может навредить.
по сути можно свести к двум ситуациям:
сайт достаточно простой что все можно раздать с одного сервера - CDN может замедлить за счет лишнего коннекта (+ время на резолв домена?). Это в случаи если все правильно настроено, а не Wordpress на бесплатном/дешевом shared hosting
статика раздается отдельно от HTML, тут сложно придумать случай вреда CDN
так что:
Как раз вчера смотрел интервью с мужиком, нехило шарящим в подобном, который обьяснял, почему CDN - просто маркетинговая пыль в глаза тем, кто не понимает техчасти.
звучит как преувеличение
Браузер переиспользует соединения для запросов с одного хоста, т.ч. через одно соединение может быть прокачано больше данных, даже если каждый запрос будет меньше 14k. И еще имейте в виду HTTP заголовки.
Речь о первом пакете, в который нужно уместить сжатый HTML+важный CSS, чтобы показать хотя бы основу сайта. Помнить о критерии CLS. На картинки поставить заглушки или skeleton loader. Далее пакеты удваиваются с каждой итерацией.
Нет, грубо говоря, достаточно иметь "легкий" /index.htm
нет, благодаря keep-alive который является дефолтной опцией по стандарту http 1.1 соединение продолжит использоваться дальше и его параметры скорее всего улучшатся. Речь только о новых соединениях где качество соединения заранее нетзвестно и пихать всё в сеть со стороны сервера не разумно.
На freebsd есть hostcache - хранилище статистики по качеству связи с теми хостами, с которыми сервер уже успел поработать. Так что если какой-то клиент с толстым каналом уже работал с сервером и у него было наработано большое cwnd, то послу ухода и последующего возвращения этого клиента у него сразу будет большое cwnd без всяких там начальных 14 килобайт.
А эта статья у вас на 28,21 кБ. Вам надо бы поработать над размером. :)
Было бы круто, если б в перевод не затаскивалась прямо вся разметка из оригинала. Автор оригинала явно злоупотребляет разметкой.
А не проще ли на сервере увеличить initcwnd / initrwnd (то самое количество пакетов, с которого мы начинаем) этак до 30, чтобы без лишних задержек пролетали страницы бóльшего размера? Пользователи с хорошим каналом получат прирост в скорости, а пользователи с еле живым - и так привыкли, что у них всё зависает :)
Жаль, что в HTML-тегах внешних ресурсов типа img, script, iframe и так и не появился атрибут etag, представляющий аналогичный заголовок HTTP. Это позволило бы самой странице управлять кешированием собственного контента, и всё бы влезало в эти 14 Кб... наверное.
Service Workers
Страница сама управляет кешированием
И вообще всем
Вообще, у некоторых тегов есть атрибут integrity, содержащий хэш содержимого по ссылке. Возможно, в будущем его добавят для картинок и задействуют в кэшировании, но пока что не судьба
Вряд ли, SRI - это про совсем другое и прикручивать хэш к ресурсам на same host - увеличивать размер кода во славу непонятно чего.
Ну не знаю, лично для меня идентификация ресурсов по их хэшу выглядит вполне логичной (предполагая, что у sha256 не найдут нехороших коллизий в обозримом будущем)
По крайней мере, если issue на гитхабе за год не закрыли — значит W3C тоже считает это логичным, возможно?
Я исхожу из того, что если мы допускаем доступ третьих лиц к своему веб-серверу на запись, то изменение ими какой-нибудь .css - меньшее из возможных зол, а значение хэша они в html поправят уж как-нибудь. W3C ИМХО исходят из того же посыла, упоминая в драфте следующей рекомендации SRI сторонние хосты как источник излишеств всяких нехороших. Впрочем, 1 пример у них приведен без схемы, т.е. скрипт загружается с same host...
Это я все к тому, что SRI вряд ли будут затачивать под кэширование.
SRI не имеет никакого отношения к кэшированию и предназначен для предотвращения неприятностей в случае кагда ваш сайт использует на своих страницах какие-то штуки с других сайтов. Например, если вы на своём сайте размещаете <script src=http://какой-то-чужой-сайт/какой-то-там-скрипт.js>. Эта штука вообще бессмысленна применительно к собственным ресурсам.
Etag не зависит от mime типа
Жаль, что в HTML-тегах внешних ресурсов типа img, script, iframe и так и не появился атрибут etag,
ETag с самого начала был везде - это свойство протокола а не какого-то конкретного формата файлов.
Речь идёт о способе подсказать etag ресурса ещё до попытки загрузить этот самый ресурс.
Я ничего не понял про подсказку 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 до фактической загрузки ресурса?
Ну вот смотрите. Допустим, на странице есть условный тэг вида <img src=foo etag=bar>. При этом, у клиента (браузера) уже есть в кеше ресурс foo с тэгом bar. В таком случае он может вообще не делать запроса, а сразу показать кешированную картинку.
Выше уже предложили использовать для этой цели не etag а integrity (Subresource Integrity) атрибут который уже используется для скриптов и стилей но не для кеширования.
Настройте сервер так, что бы он в ответ на запрос /foo отдавал бы только Expires через_сто_лет и браузер не будет перезапрашивать этот ваш /foo целых сто лет (ну или до тех пор, пока /foo не будет выкинут из кэша браузера по каким-то причинам).
Ага, а если таки foo изменится — то уведомить об этом клиента уже не получится
То есть вы хотите что бы закэшированный контент /foo оставался бы в кэше до тех пор, пока сервер каким-то образом не выкинет его оттуда сам по своей инициативе, так что ли?
... и этот "какой-то образ выкидываня" называется веб-воркером.
Это не я хочу, этого хотят все кто хоть раз задумывался об оптимальном кешировании.
Он хочет, чтобы сервер увидел, что его просят загрузить картинку с какими-то путём и хешем и, если в кеше есть картинка с таким путём и кешем, взял бы её из кеша.
Вот есть канал 100МБит/с
Это примерно [8.7к пакетов по 1500 байт]/с
А если слать пакеты по 150 байт, это будет 87к пакетов/с? Или так же 8.7к?
В теории в идеальной сети да, но на практике у меня между Петербургом и Москвой в iperf3 с пакетами по 150 байт получились 52% потерь пакетов (по 400 байт — 16% потерь, по 600 байт — 7% потерь, по 800 байт — 4% потерь, по 1000 байт — 3% потерь)
Не знаю, как провайдеры должны реагировать на запредельное число пакетов, но если не выпендриваться и ставить размер 1500 (точнее 1460) байт, то потерь нет, так что всё нормально, наверное?
больше 1% — можно жаловаться провайдеру, не?
удачи
Вообще обычно выгодно посылать как раз пакеты побольше. Кроме случая, когда у вас протокол и контент переживут потери чего-то в средине и совсем уж убитый канал.
А зачем стрелять себе в ногу, уменьшая размер пакета?
это будет 87к пакетов/с? Или так же 8.7к
Зависит от возможностей сетевой карты и промежуточного оборудования так как у каждого пакета есть заголовок, обрабатывать который оборудование должно независимо от размера полезной нагрузки в этом пакете.
Загрузчик 512 байт, размер TCP пакта 16 кб. Может стоит обновить стандарты?
Я аж в календарь посмотрел от этой статьи. Это всё в вебе было интересно до примерно середины 2010-х, пока массово не приехал HTTPS и HTTP/2. При этом прямо в самой статье есть ссылка на «более глубокий анализ», в котором с дампами трафика поясняется, почему эта статья вредная.
Дорогие товарищи! Не верьте во всякие «вот как я увеличила свой бюст на шесть дюймов», профилируйте и измеряйте эффекты сами, в компьютерах это сравнительно дёшево.
А что, initial cwnd в них как-то изменился? Он и в QUIC такой же.
Никак не изменился, просто проблемы с быстродействием в вебе стали богаче, чем «давайте сэкономим один rtt на первом холодном заходе». Тот же набор сертификатов TLS легко может быть 5 килобайт, но оригинальный автор прямо в 2022 году пишет, что TLS используется «иногда». Пример с мобильными сетями отличный, но там кроме задержки ещё и потери есть, до состояния «в соединении с полумегабайтом переданных данных никогда не было cwnd больше 10».
В общем, статья на мой вкус «пропишите вот это в sysctl и будет счастье». Буквально все ссылки в статье лучше, чем сама статья, потому что там либо HPBN, либо дампы трафика и утилиты для анализа происходящего.
Мне кажется, на сайт, который реально имеет какую-то ценность, заходить будут в любом случае, какой бы медленный и убогий UX у него бы не был, алиэкспресс тому пример. А бесполезный ресурс никакие оптимизации не спасут, как бы он не летал.
Между крайностями "сайт, который делает что-то жизненно важное и на который зайдут при любом раскладе" и "барахло, о котором никто не узнает в любом случае" существует множество остальных сайтов, у которых есть конкуренты и которые очень заботятся о скорости загрузки для удобства пользователей.
И поисковики, кстати, ее в ранжировании тоже учитывают.
А про поисковики - это легенда-суеверие или как-то подтвержденный факт? Я не сомневаюсь, что страница, которая вообще ужасно грузится - наверняка будет как-то "наказана". Но вот между страницами, одна из которых грузится за 1 сек, а вторая за 1.2 сек - будет заметна разница?
Поисковики ведь не афишируют свои алгоритмы (или уже афишируют)? Хотелось бы какую-то уверенность в этом. Потому что даже предлагая заказчику какую-то работу на тему ускорения сайта, надо убедительно ее обосновать.
Подтвержденных фактов я не знаю, но Гугл официально, в прес-релизах, заявлял, что скорость загрузки влияет на ранжирование.
Проверить это представляется весьма затруднительным, но, с другой стороны - смысл им об этом врать? Чтобы похихикивая смотреть, как весь интернет пытается сделать свои сайты быстрее? Возможно, конечно, и такое... Но, все таки, вряд ли.
Другой вопрос - на сколько влияет. Условный 1% к финальному рейтингу или 20%? Понятия не имею.
Есть ведь известная проблема (забыл название): как только какой-то критерий начинает использоваться для оценки людей или их действий - он тут же теряет свою ценность.
Человек в очках и пиджаке вызывает больше доверия, чем пират в бандане и с деревянной ногой? Тут же все мошенники наряжаются в пиджаки и очки. И дипломов о высшем образовании у них больше, чем у Перельмана.
Активный чиновник активнее "осваивает бюджет" (строит дороги и парки) и надо за это поощрять? Окей, только начали, и чиновники тут же начинают тратить очень много на все подряд. Даже не воруя, все равно имеют стимул "купить за углом на сто долларов дороже".
Письмо с PDF вложением редко бывает спамом, зато бывает важным деловым сообщением, которое очень опасно зря "зарубить"? Окей, только встроим этот критерий в популярный антиспам - тут же весь спам пойдет с PDFками.
Начали в поисковике нелюбить страницы с заголовками H1 красным цветом? Тут же все дорвейщики перерисовали свои шаблоны и перегенерировали свои дорвеи, теперь там сине-зеленые H2.
Очень часто критерий хорош только если о нем не знают, не принимают его в расчет. Доверять людям в белых халатах классно и удобно если мошенники еще не догадались наряжаться в халаты. И поисковик хочет найти "хорошие сайты", но не хочет находить сайты, которые намеренно стараются быть очень хорошими, потому что их делают "хитрые коварные злые сеошники", а злой сеошник может любой сайт превратить в конфетку. Поэтому, поисковику было бы полезно видеть какой-то признак сеошников, мол "да, этот сайт выглядит хорошо, но он хорош как девушка с тонной косметики и силикона" и относиться к нему нужно с бОльшим подозрением, в отличие от немного кривого-косого сайта, который точно "красив естественной красотой" и на нем болд и заголовки в самом деле выделяют темы, а не сеошным кейвордам веса набирают.
Все так, все правда. Но быстрые сайты на самом деле лучше для пользователей. И для Гугла скорость - это, наверняка, только один из параметров. Вероятно, далеко не самый важный.
В любой оптимизации надо сравнивать затраты и потенциальный "выхлоп", отталкиваясь от имеющихся данных.
Сайт на который 100 госслужащих, не имеющих альтернативы, выгружают отчеты раз в месяц. Страница грузится 5 секунд, чтобы оптимизировать, надо потратить неделю работы программиста с зарплатой $1K. Надо делать? Вероятно, нет. Может быть, позже.
Маркет-плейс с миллионами пользователей и страшными оборотами. Страница грузится 5 секунд, у конкурентов - 1,5. Чтобы оптимизировать, надо потратить месяц команды профи с общим бюджетом в $30K. Надо делать? Однозначно, да.
Хочу напомнить, что существует офигенный ежегодный https://js13kgames.com/ , который уже идёт и будет идти до 13-го числа!
Больше игр, хороших и разных. И да, умещающихся в 13К!
Раз пошла такая пьянка, "моя почта не ходит далее 500 миль!" (FAQ)
А какие есть способы отладки всего это счастья? Могу я как-то научить браузер после загрузки первых 14кб останавливаться, чтобы посмотреть, что получилось? И заодно узнать, отдает ли веб-сервер 14кб или больше в качестве первой пачки.
В заголовках HTTP указан обычно размер содержимого, Content-Length.
Можно задампить трафик в Wireshark, вас все равно только tcp уровень интересует, контент можно не расшифровывать.
Как раз интересно посмотреть, как браузер отрендерит эти самые первые 14кб. Вот после прочтения статьи мне стало интересно подготовить заглушку в 14кб для пользователей с плохим интернетом. Как вариант стырить пакеты с wireshark, сохранить в файл, потом открыть в браузере... Но может уже есть готовые более простые варианты для отладки.
Для прикладного программиста это нет смысла отлаживать — оно ж и так работает. Столбиков с временем загрузки и так достаточно.
Клуб 10 КБ - это коллекция веб-сайтов, размер домашних страниц которых не превышает 10 КБ в сжатом виде.
Не увидел как проводили тесты, чем меряли, какие сайты были в выборке, как анализировали результаты. и т.д.
Короче, делайте сайты "короче", в смысле избавьте от хлама. Уже лет 8 назад встречал статьи (в т.ч. на хабре), что сайты стали слишком жирные. Майкрософт ком страничка в 150 МБ - как это? И ещё куча таких, весьма популярных. А ведь если https (а оно сейчас поголовно), то при плохом соединении просто всё отваливается по таймауту, когда сайт толстый.
Отдельная песня - перенос нагрузки на клиентов. То есть сайты переносят часть логики в виде скриптов на сторону браузера - и тонны скриптов иногда даже не могут переварить не очень быстрые компьютеры (с одним ядром, например). Как пример - сайты ситилинка, днс, и куча других. Да даже яндекс почта таким грешит, благо, хоть может предоставлять более лёгкий вариант страниц, если что-то не так (если не убрали, давно не проверял).
Сейчас порой в интернет не хочется заходить со смартфона, ибо тормозит половина сайтов, гораздо проще получается прочитать тот же контент в каких-то чатах или каналах телеграм, там всё это же намного быстрее загружается и отображается. Просто все привыкли, что у всех 100 мегабит и комп 8 ядер и 16ГБ оперативки. Разработчикам (или скорее тестировщикам) нужно выдавать для проверки ВМ с одним ядром и 1 гигом памяти, и полосу в 256кбит. Хотя кого я обманываю - в половине случаев никакого тестирования не делают толком! (а, на пользователях и потестим :)
Майкрософт ком страничка в 150 МБ - как это?
Понимаю, что для демонстрации современного бездуховного мира все средства хороши, но можно ли воочию это увидеть?
Hidden text
Я эту цифру запомнил с тех времён, сейчас не проверял, каюсь. Может изменилось уже.
Было бы неплохо отключить ещё всякие блокировщики и выключить кеш (галочка сверху) и, возможно, запускать вне России, чтоб фейсбук всё смог загрузить
Получится хоть и немного, но больше
Это была чистая загрузка через Ctrl+F5 с чешского адреса (на что намекает cs-cz в заголовке).
Убирание uBlock ничего особо не меняет, было 812kB + 2.8MB, стало 829kB + 2.8MB
Получится хоть и немного, но больше
Неа. 2.8 мегабайта в разжатом виде на всё - хомяк, все стили, скрипты и прочее (всего 80 запросов). Чистая установка Firefox на чистой машине c Win10, Амстердам.
А если у меня интранет и Jumbo Frame везде настроены, можно до 89 кб расшириться? :)
Краткое содержание статьи: лучше – меньше, а ещё вот есть такая константа, равная 14kb
Это, конечно, замечательно, что существует такая константа, но к чему она вообще, если ничто не влезет в неё?
Размер окна разве не во время хэндшейка определяется?
Хэндшейк, а потом только передача http. Мне кажется задержка появляется из-за фрагрментации кадров на промежуточных узлах
Я так и не понял, весь сайт нужно в 14к уложить или только одну страницу. И если второе, то речь только об хтмл или остальные ресурсы тоже считаются?))
А так, интересно, конечно, поговорить про сфер коня в вакууме, но на практике сайтостроения это вряд ли можно использовать. А вот с точки зрения API бэкэндов будет любопытно, наверное)
Размер заголовка IP - 20 байт
Размер заголовка tcp - минимум 20 байт, он может быть и больше, но кратный 4.
Del
После сборки небольшого стенда, для проверки темы поста, получились такие данные...
Мне было интересно, на сколько это работает в среде среднестатистического пользователя. Я использовал обычный хостинг, обычную контрольную панель, и не производил никаких дополнительных настроек (apache, nginx). В качестве клиента был домашний компьютер (win, chrome), опять же без каких то специальных настроек. Всё как из коробки. И.. Оно действительно работает :) Как этим пользоваться дальше, каждый пусть решает сам, но то что оно есть - для меня - факт.
Правильно ли понимаю, что в правиле 14кб речь идет не о том, что ваша веб страница не должна превышать 14кб в объеме, как мне и многим в комментариях показалось, а о том, что любой TCP запрос в рамках выполнения кода на сайте, за раз не должен тянуть более 14кб трафика. В таком случае разбивание сайта на отдельные блоки автономно запрашивающие мелкие пакеты данных в конечном итоге улучшат производительность и отзывчивость сайта.
Почему ваш веб-сайт должен быть меньше 14 КБ