Введение в Shared Compression Dictionaries
Новый интересный способ сжатия поверх HTTP подъехал. Точнее, относительно новый и относительно подъехал, но обо всё по порядку.
Скорее всего в ваших проектах есть автоматическое GZIP-сжатие на сервере всякого текстового, что отправляется в браузеры. Это настолько стандарт, что зачастую оно просто включено по умолчанию, даже думать про это не надо, потому что все современные браузеры в GZIP давно умеют. Это довольно простой метод сжатия на основе алгоритма DEFLATE.
Если для вашего проекта важен перфоманс, то, возможно, вы даже игрались с Brotli или Zstandard. Тут алгоритмы уже посложнее, при этом под капотом используются специальные словари, которые увеличивают вероятность того, что повторные куски текста передавать не придётся. И включить их тоже уже относительно просто, есть готовые решения почти на любой вкус.
Был ещё такой проект, SDCH (Shared Compression Dictionary over HTTP). К сожалению, его реализация была супер-небезопасной, из-за чего браузеры перестали его поддерживать.
Но работа над идеей не остановилась. А идея такая. Скорее всего у вас в проекте есть какие-то файлы, которые от релиза к релизу меняются частично. Например, вы поправили конкретную кнопку, для чего переписали немного JS и добавили новых стилей в CSS. Во время релиза у вас собрался бандл, который содержит крайне мало правок, но из-за того, что это всё же новый файл, нельзя пользоваться кэшированием браузера — пользователю приходится перекачивать весь файл целиком. (Часто здесь перфоманс-инженеры начинают играться с чанками, но универсального решения всё равно нет.)
А что было бы, если бы браузеру можно было сказать, чтобы он взял старую версию файла (из кэша, чтобы почти мгновенно), а потом поверх неё применил только дифф, как в
Похожую идею можно применить и для динамических сайтов. Скорее всего у вас есть футер и шапка, какое-нибудь меню. И все они от релиза к релизу одинаковые. Можно добавить их в словарь, который браузер закэширует, а загружать для каждой страницы нужно будет только различия. Что тоже может нехило сэкономить байтики.
Лабораторные тесты показывают, что новый формат может как ничего не давать полезного вообще (тот же Brotli вполне себе мощный из коробки), так и экономить до 80% трафика. Так что не стоит бросаться внедрять просто потому что, начать стоит с пробных замеров.
И как же этим пользоваться, если всё-таки готовы?
- Поддержка нового формата появится в Chrome 130, но так как формат подразумевает фолбек на обычное скачивание обычных файлов, то можно использовать его как прогрессивное улучшение.
- Amazon CloudFront, Cloudflare и Fastly уже поддержали этот формат у себя. Думаю, другие CDN тоже скоро подтянутся, потому что это позволяет на том же железе зарабатывать в разы больше на раздаче статики. Золотая жила.
- В статье есть ссылки на рецепты, как прикрутить новый формат к себе, но там прям надо хорошо разбираться и уметь патчить запросы на уровне заголовков. Ещё и сборку проекта нехило так нужно дописать, чтобы помимо нового бандла хранить дифф со старым бандлом. Но если у вас уже настроена тонкая настройка Brotli или Zstandard, то дотюнить под новые словари будет не так сложно.
- Хоть и выглядит всё довольно сложно, верю, что автоматизацию в случае успеха в Chrome подвезут быстро. Когда-то нужно было `.gz`-версии файликов подкладывать руками рядом с обычными версиями, чтобы твой сайт работал быстрее, чем у конкурентов, а сейчас многие даже и не в курсе, что у них на сервере gzip-сжатие срабатывает автоматически.
https://www.debugbear.com/blog/shared-compression-dictionaries
Новый интересный способ сжатия поверх HTTP подъехал. Точнее, относительно новый и относительно подъехал, но обо всё по порядку.
Скорее всего в ваших проектах есть автоматическое GZIP-сжатие на сервере всякого текстового, что отправляется в браузеры. Это настолько стандарт, что зачастую оно просто включено по умолчанию, даже думать про это не надо, потому что все современные браузеры в GZIP давно умеют. Это довольно простой метод сжатия на основе алгоритма DEFLATE.
Если для вашего проекта важен перфоманс, то, возможно, вы даже игрались с Brotli или Zstandard. Тут алгоритмы уже посложнее, при этом под капотом используются специальные словари, которые увеличивают вероятность того, что повторные куски текста передавать не придётся. И включить их тоже уже относительно просто, есть готовые решения почти на любой вкус.
Был ещё такой проект, SDCH (Shared Compression Dictionary over HTTP). К сожалению, его реализация была супер-небезопасной, из-за чего браузеры перестали его поддерживать.
Но работа над идеей не остановилась. А идея такая. Скорее всего у вас в проекте есть какие-то файлы, которые от релиза к релизу меняются частично. Например, вы поправили конкретную кнопку, для чего переписали немного JS и добавили новых стилей в CSS. Во время релиза у вас собрался бандл, который содержит крайне мало правок, но из-за того, что это всё же новый файл, нельзя пользоваться кэшированием браузера — пользователю приходится перекачивать весь файл целиком. (Часто здесь перфоманс-инженеры начинают играться с чанками, но универсального решения всё равно нет.)
А что было бы, если бы браузеру можно было сказать, чтобы он взял старую версию файла (из кэша, чтобы почти мгновенно), а потом поверх неё применил только дифф, как в
git? И ещё сжал этот дифф, потому что он же тоже текст. Если максимально упростить и опустить море деталей, в этом и суть Delta Compression. Старую версию используем как словарь, а новая получается применением диффа.Похожую идею можно применить и для динамических сайтов. Скорее всего у вас есть футер и шапка, какое-нибудь меню. И все они от релиза к релизу одинаковые. Можно добавить их в словарь, который браузер закэширует, а загружать для каждой страницы нужно будет только различия. Что тоже может нехило сэкономить байтики.
Лабораторные тесты показывают, что новый формат может как ничего не давать полезного вообще (тот же Brotli вполне себе мощный из коробки), так и экономить до 80% трафика. Так что не стоит бросаться внедрять просто потому что, начать стоит с пробных замеров.
И как же этим пользоваться, если всё-таки готовы?
- Поддержка нового формата появится в Chrome 130, но так как формат подразумевает фолбек на обычное скачивание обычных файлов, то можно использовать его как прогрессивное улучшение.
- Amazon CloudFront, Cloudflare и Fastly уже поддержали этот формат у себя. Думаю, другие CDN тоже скоро подтянутся, потому что это позволяет на том же железе зарабатывать в разы больше на раздаче статики. Золотая жила.
- В статье есть ссылки на рецепты, как прикрутить новый формат к себе, но там прям надо хорошо разбираться и уметь патчить запросы на уровне заголовков. Ещё и сборку проекта нехило так нужно дописать, чтобы помимо нового бандла хранить дифф со старым бандлом. Но если у вас уже настроена тонкая настройка Brotli или Zstandard, то дотюнить под новые словари будет не так сложно.
- Хоть и выглядит всё довольно сложно, верю, что автоматизацию в случае успеха в Chrome подвезут быстро. Когда-то нужно было `.gz`-версии файликов подкладывать руками рядом с обычными версиями, чтобы твой сайт работал быстрее, чем у конкурентов, а сейчас многие даже и не в курсе, что у них на сервере gzip-сжатие срабатывает автоматически.
https://www.debugbear.com/blog/shared-compression-dictionaries