Комментарии 53
Нет причины, по которой GitHub не может поддерживать Brotli
Как правило, Brotli лучше, чем gzip, а gzip лучше, чем ничего. gzip настолько малозатратен, что он на серверах по умолчанию включен, а вот Brotli на порядок медленнее.
Вы же сами ответили на свой вопрос.
Гитхаб это не обычный веб-сайт, это сервис, в котором исходники часто отдают по https а не ssh, и гитхаб могут использовать для различных активностей, автоматизации, даже синхронизации конфигов с различных устройств, в том числе и смарт-устройств, работающих на 1-5 ватт, где процессор может быть запитан от маломощной батарейки.
Дать пользователям выбор наверное было бы лучшим вариантом, но видимо может быть софт до 2016-2017 года, который автоматом это не подхватит. Не знаю, я честно говоря не могу сказать насколько легко оставить обратную совместимость.
Речь о GitHub Pages, который для исходников, конфигов и прочего (обычно) не используется.
HTTP-клиент передает допустимые форматы в загаловке Accept-Encoding, сервер далее имеет право сжимать только каким-либо из этих форматов. Проблем с совместимостью благодаря этому быть не должно.
Это вообще бред, что вы несете. Да если бы youtube приложение/chrome не использовало gzip там было бы 6 мбайт данных (не мбит) в секунду на одном тексте... Так и есть в ffmpeg/mpv, так как там gzip и br не поддерживается. https://github.com/mpv-player/mpv/issues/14360
После сжатия 300 кбайт.
Не вижу в вашем комментарии логики. Откуда вообще взялся Ютуб и почему вы вообще рассматриваете вариант неиспользования gzip?
Никто не рассматривает вариант неиспользования gzip, кроме вас. Это баг в ffmpeg. https://trac.ffmpeg.org/ticket/7158
Youtube использует такой DASH для live стримов.
Сервер будет сжимать только если клиент сам ему скажет "Accept-Encoding: gzip, br".
А зачем использовать неэффективный алгоритм, который ради прироста сжатия на 15% использует на порядок больше вычислительных ресурсов?
Потому что 90% времени процессор всё равно простаивает, дожидаясь данных через сеть.
Это утверждение далеко не всегда верно. У нас в проекте есть необходимость доставлять на виртуалки питонячий энв. По-сути, нужно скачать и распаковать на диск архивчик размером в пару гигов. Так вот, оказалось, что скачивать и распаковывать несжатый tar быстрее, чем скачивать и распаковывать сжатый tar.xz или tar.gz.
А если lz4?
Для @GennPen- если ресурс статический, и можно 1 раз сжать и 1000 раз отдать контент, то потратить на порядок больше времени, получив -15% к размеру, становится выгоднее.
.xz был создан для исходного кода и бинарников типо elf, специально. Он всё ещё обеспечивает лучше сжатие через zstd, дефолтный архив apt-get. И у вас же не 14 Intel, и вообще xz не очень оптимизирован, но после скандала с бекдором его стали пилить как не в себя.
Большие архивы это не веб страницы, web страницы надо ещё отрендерить, чем быстрее начнешь рендерить тем лучше.
Вы раз минусуете, то я вас ещё рассказу. Вы знаете, что nvme и hdd такие медленные, что если сжать exe и dll то распаковка в оперативке займет меньше времени?
Причем тут nvme и hdd, exe и dll?
Объясняю, почему Brotli нельзя включать на проде.
Заходим на официальный репозиторий, далее ищем в нем ссылку на большой тест алгоритмов сжатия.
В нем ищем нужные результаты:
Compression Compressed size Decompresser Total size Time (ns/byte)
Program Options enwik8 enwik9 size (zip) enwik9+prog Comp Decomp Mem Alg Note
------- ------- ---------- ----------- ----------- ----------- ----- ----- --- --- ----
brotli 18-Feb-2016 -q 11 -w 24 25,764,698 223,597,884 542,385 s 224,140,269 3400 5.9 437 LZ77 48
gzip 1.3.5 -9 36,445,248 322,591,995 38,801 x 322,630,796 101 17 1.6 LZ77Сжатие XML-файла примерно на 30% эффективней. Но самое главное - это колонка "Time Comp" по которой видно, что brotli сжимается в 34(!) раза медленней и памяти требуется в 273(!) раза больше.
Скрытый текст
Вы видимо плохо понимаете как читать результаты и какие вообще требования к алгоритмам сжатия сегодня. А сегодня требуется максимальная гибкость, чтобы использовать один алгоритм для всего, вместо вороха разных, в особенности эта концепция развита в zsd, когда на минимальном сжатии мы примерно по скорости как lz4, а на максимуме жмем рекордно как 7zip, и нам все равно сколько времени это займет.
11 уровень у бротли это ультра, максимальное сжатие, но если вы попробуете другие уровни, то внезапно окажется что Brotli жмет процентов на 10% лучше чем gzip да и еще делает это заметно быстрее.
А если мне надо 1 раз во время билда сжать css-js в пару мб, то я включу это самое ультра сжатие, заплачу за него целую секунду работы процессора, вместо миллисекунд для gzip, зато сэкономлю трафик и время пользователя.
Ну сжать билд или сжать ответ это разные вещи)
вы читать написанное умеете? ;) первый абзац, бротли это не gzip, у которого параметры сжатия +- в узких пределах. У бротли 12 уровней сжатия, 6-ой стандартный, его используйте для обычного ответа. Это будет быстрее по времени чем gzip (на макс) и лучше по уровню сжатия. Есть расширенная версия 7zip ZS, там и бротли и zstd, можно поэкспериментировать. Есть еще такое https://quixdb.github.io/squash-benchmark/
Ну бенчмарк это хорошо, только я по прежнему не понимаю как мне поможет бротли в динамике и как он ведёт себя с тонким клиентом. У меня вот есть гзип или даже нечего иногда. Все работает, ттб в норме. Бротли уже не мало лет, кроме его реализации браузерами, его распространение сомнительное, цена его использование - вычеслительная мощность в архитектуре. Зачем? Ради пары килобайт? Как это повлияет на конверсию?
Чисто вот по факту, есть допустим высконагруженный проект, в плане посетителей. Картинки, текст, и прочее. Сменю я гзип на бротли. Цена этого? В плате за сервер и ттб на клиенте
его распространение сомнительное
все зависит от квалификации людей. вот facebookу надо - он вкладывается в zstd, а некоторые даже на http2 перейти не могут. Вопрос в другом, зачем нужен gzip если есть brotli который жмет лучше процентов на 10% и работает быстрее, причем все что надо от администратора это или поменять пару строчек в конфиге или выбрать другой пункт из дропдауна. цену я за вас определить не могу, для этого надо знать объем текстового трафика в сутки, но учитывая, что в большинстве случаев brotli сегодня включается элементарно и поддерживается уже всеми клиентами, я не понимаю в чем проблема его включить. в принципе новые алгоритмы и пакуют быстрее и распаковывают тоже, так что тонкому клиенту будет лучше. Глобально все оптимизации дают по 5-10%, если их рассматривать индивидуально, а интегрально набежит на порядок больше;) в chrome dev tools можно установить параметры как у сотовой сети, возможно получится заметить latency глазом
все зависит от квалификации людей
ой да хватит))
ну дело ваше, страшно включать или лень, не включайте, мне с этого ничего не перепадает) я просто к тому, что нет рациональных причин его не использовать, если с вашей точки зрения рационально использовать gzip. Единственный случай когда я бы не использовал сжатие, это если с сервера приходят маленькие респоны
Как раз в браузерах он уже вроде везде поддерживается, это же гугл его продвигает.
В 2017 году он поддерживался уже всеми популярными браузерами, в том числе и curl, а также популярными серверами (apache/nginx)
Скомпилировал для nginx модуль https://github.com/google/ngx_brotli. Так динамическое сжатие уменьшило исходящий трафик где-то в три раза, на некоторых файлах экономия доходила до шести раз.
Можно было бы сжать статические файлы и отдавать их (nginx и такое умеет), но больше возни с настройками, повышение нагрузки на процессоры не замечено.
ну так прогресс же.
Многие вещи могут сдерживаться по разным причинам. Просто руки не дошли, нет времени и ресурсов на апгрейд инфраструктуры, ибо просто включить опцию это не просто так, а в крупной компании нужно обосновать, проанализировать, протестировать, обосновать не с точки зрения производительности, а с точки зрения выгоды компании.
Например если есть два провайдера, один включил сжатие, другой не включил. А в конце месяца взаиморасчеты по трафику, и тут то бротли оказывается плохой
А много ли статичного контента в интернете? Лично я его уже практически не вижу. Даже якобы статичный контент зачастую генерируется динамически. А всякие css/js прекрасно кэшируются на стороне клиента, что экономит кучу трафика.
И еще на сколько помнится, gzip использует блочную компрессию, что позволяет начинать распаковывать валидные данные при частичном получении данных. Про brotli я подобной информации не нашел, возможно плохо искал.
они все блочные, что бротли что zstd, на максимальном уровне сжатия размер блока увеличивается вдвое от стандартного, других нюансов не помню. единственно, что zstd умеет еще делать пред прогон всего файла перед сжатием и составлять по нему оптимальный словарь. но думаю и в этом случае сжатие идет блочно, хотя это и более сложный случай.
про статический контент было как пример, когда сжатие нужно максимальное. оно пригодится когда пользователь открывает сайт в первый раз (и с мобилки), для бизнеса это тоже критичная метрика. в других случаях ставьте среднее, все равно будет лучше gzip.
что zstd умеет еще делать пред прогон всего файла перед сжатием и составлять по нему оптимальный словарь. но думаю и в этом случае сжатие идет блочно, хотя это и более сложный случай.
Это же противоречит блочности.
Каждый блок должен был независим от другого блока, чтобы иметь возможносьт сжать блок, передать и разжать на той стороне, пока начинает сжиматься и передаваться второй блок.
надо смотреть как это технически устроено, я никогда не использовал. принципиально это не мешает сжимать и распаковывать блоки параллельно, после осмотра всего файла, в худшем случае они будут зависеть от первого блока или какого-то файла, чатгпт говорит что распаковка и в этом случае идет отдельными блоками и может осуществляться параллельно. но это опциональная фича, на сколько помню она заметно повышает степень сжатия. в принципе этот словарь можно использовать потом и для сжатия похожих файлов. ну т.е. вы потренировали zstd на своих реквестах-респонсах и после используете эти данные во время работы приложения. года 4 назад на хабре про это писали. но это все фичи для мобильного приложения, браузеры не умеют работать с zstd пока. В общем случае имеем такую же блочную манеру обработки как и в gzip.
Если блок зависит от другого блока, он не может распаковываться параллельно. Это как солид архив.
Как раз паралельно можно разжимать независимые блоки. Либо передавать тогда весь словарь до того, как начали разжимать блоки.
В бротли есть встроенный словарь популярных слов для web, что собственно и дает ему первичный прирост в 10-15% даже на сопоставимом с zip уровне сжатия на всяких xml/html/css. Там вроде около 120 кб.
Хорошо, вы уменьшили трафик, но что начет отображение контента? Насколько дольше он теперь отображается. У меня например оригинал статьи с лагом в несколько секунд дозагружается на вашем блоге)) 5 секунд по факту. Это настольный пк.
И с заметным прыганьем. И как-то смешно считать эти килобайты, когда шрифт на странице весит 800кб+
I want to provide a smooth experience to my site visitors
Вообще не смузи) Еще и какой-то пустой скрол в несколько экранов
Но все очень интересно, так держать)
A different comment says librewolf disables webgl by default, breaking OP's decompression.
Нашел ответ) На маке лучше, но там все равно блинк контента, скрол и мы попрежнему, вместо - скачать страницу -> отрендерить получаем - скачать страницу -> скачать сжатый файлик -> анзип -> и только тут рендер. А если гидрация нужна, подождем еще.
странная цель - делать сайт как можно меньше в ущерб его производительности.
90 килобайт - сущие копейки. комментатор выше верно подметил: своей "оптимизацией" вы ускорили загрузку страницы на несколько миллисекунд, но взамен сильно замедлили её отображение
Согласен полностью и хочу добавить, что бизнесу и пользователям важнее время отображения, а не загрузки данных. Загрузку данных в теории можно исправить на уровне железа и сети, а вот если всё упирается в алгоритмы отображения, то кроме как переписываем кода проблему не решить. Конечно сжатие важно, но его нужно применять с умом и где это действительно нужно, а не ради сохранения 90 килобайт во вред производительности.
Как правило, Brotli лучше, чем gzip, а gzip лучше, чем ничего. gzip настолько малозатратен, что он на серверах по умолчанию включен, а вот Brotli на порядок медленнее.
Начем с того, что это не правда. Brotli всегда лучше и всегда быстрее чем gzip. Просто надо использовать адекватный уровень сжатия.
Ждал в конце чего-то в духе: "на проде, конечно, мы так делать не будем".
Но не дождался.
Так что восприятие статьи перешло из жанра триллера в ужасы.
декомпрессор xz (https://github.com/tukaani-project/xz-embedded) собранный wasm - 6373 байта.
при том руками оптимизированный на асм для х86 там вообще в меньше кБ, так что есть куда расти.
а жать он должен получше webp.
А можно протестировать Avif и JpegXL?
WebP — формат сжатия веб-страниц