Brotli в переважній більшості випадків стискає текстові файли сильніше за Gzip. Різниця в стисненні файлу для більшості сайтів становить від 15 до 30 відсотків залежно від типу вмісту та рівня стиснення. Для статичних ресурсів, які можна стиснути один раз під час збірки, вибір майже завжди на користь Brotli з максимальним рівнем якості. Для динамічного вмісту перевага не така однозначна. Сервер стискає його на льоту під кожен запит, і Gzip середнього рівня іноді дає нижче навантаження на процесор при порівнянному розмірі відповіді.
Обидва формати підтримуються практично всіма сучасними браузерами. Питання тут не в сумісності, а в тому, який ресурс і за яких умов стискається. Сервер або CDN обирає формат за заголовком Accept-Encoding, який надсилає клієнт. За замовчуванням варто налаштувати обидва варіанти: Brotli як пріоритетний, Gzip як резервний для клієнтів, що Brotli не підтримують.
Спільна основа: чому алгоритми схожі
Gzip з’явився в 1992 році як заміна застарілому compress. В основі він використовує формат DEFLATE. Це комбінація алгоритму LZ77, який замінює повтори посиланням на попередню появу тих самих байтів, і кодування Гаффмана, яке скорочує часті символи до коротших кодів. Brotli Google випустив у 2015 році, спочатку для стиснення шрифтів формату WOFF2, а згодом узагальнив для HTTP. Побудований він на тих самих двох принципах.
Це не два різні підходи до стиснення, а одна схема з різними параметрами і додатковими прийомами поверх неї. Розібратися, звідки береться перевага Brotli, можна лише подивившись, що саме додано до спільної основи.
Вікно пошуку повторів: головна технічна причина розриву
LZ77 шукає повтори не по всьому файлу, а в межах ковзного вікна фіксованого розміру. Саме розмір цього вікна найбільше пояснює різницю в результаті. У Gzip вікно жорстко обмежене 32 кілобайтами. Байт, розташований далі цієї межі, для алгоритму ніби вже не існує, навіть якщо це точна копія фрагмента, який щойно траплявся. У Brotli вікно налаштовується і сягає 16 мегабайт, тобто у 512 разів більше.
Порахувати наслідок неважко. Файл на 100 кілобайт Gzip фактично ділить на три непов’язані вікна по 32 кілобайти. Повтор на початку файлу та повтор наприкінці алгоритм між собою не зв’яже. Файл на 500 кілобайт це вже шістнадцять таких вікон. Файл на мегабайт, типовий розмір для несегментованого бандла JavaScript, дає тридцять два вікна для Gzip. Brotli при цьому вкладає той самий мегабайт у своє вікно з шістнадцятиразовим запасом. Весь файл для Brotli лишається одним суцільним контекстом. Що більший і що одноманітніший файл, то дорожче Gzip платить за це обмеження.
Статичний словник Brotli
Крім вікна, Brotli несе вбудований статичний словник розміром близько 122 кілобайт. У ньому заготовлені фрагменти, типові для вебу: службові слова HTML і CSS, поширені атрибути, конструкції JavaScript, частини URL. Алгоритм звертається до цього словника так само, як до вже стисненої частини файлу. Тому навіть короткий документ без внутрішніх повторів отримує виграш за рахунок збігів із заздалегідь відомим текстом.
У Gzip такого словника немає. Усе, що не повторюється всередині самого файлу, стискається лише за рахунок кодування Гаффмана. Саме тому короткі HTML-сторінки та невеликі CSS-файли, де внутрішніх повторів мало, показують один із найбільших розривів між форматами.
Звідки розбіжність між 15, 25 і 35 відсотками
Матеріали в мережі називають дуже різні цифри виграшу Brotli над Gzip. Від 15 до 30 відсотків в одних тестах, від 17 до 25 в інших, від 25 до 35 у третіх. Розбіжність не означає, що хтось із авторів помиляється. Вона означає, що тести порівнюють різні речі під однією назвою.
Перше джерело розбіжності це базовий рівень Gzip. Стандартний рівень 6 і максимальний рівень 9 дають різницю в кілька відсотків, і порівняння саме з рівнем 6 завжди показує Brotli у вигіднішому світлі. Друге джерело це сам режим Brotli. Рівень 11 придатний лише для одноразового стиснення під час збірки. Рівень для стиснення на льоту зазвичай четвертий або п’ятий, і виграш там помітно скромніший. Матеріал платформи Panelica за червень 2026 року прямо розводить ці два випадки. Brotli четвертого рівня випереджає Gzip шостого рівня приблизно на 15-20 відсотків за порівнянного навантаження на процесор. Попередньо стиснений Brotli одинадцятого рівня дає ще додаткові 25-35 відсотків над тим самим Gzip шостого рівня. Третє джерело розбіжності це тип вмісту: HTML, CSS і JavaScript стискаються по-різному через різну щільність повторів і різну частку збігів зі статичним словником.
Швидкість стиснення і декомпресії
За швидкістю стиснення перевага стабільно на боці Gzip. Максимальний рівень Brotli обробляє дані значно повільніше, і для великих обсягів різниця вимірюється не відсотками, а разами. Для статичних ресурсів це не проблема: вони стискаються один раз під час збірки і потім роздаються тисячі разів. Для унікального вмісту, який генерується під кожен запит, це вже проблема. Час на стиснення тут додається до часу відповіді сервера напряму.
Декомпресія влаштована інакше. Швидкість розпакування в Brotli близька до Gzip і в частині тестів навіть вища. Для браузера, який лише отримує і розпаковує файл, різниця в навантаженні мінімальна. Плата за це на боці Brotli в іншому: формат відмовився від контрольної суми CRC, яку Gzip перевіряє під час розпакування. Натомість Brotli покладається на цілісність, яку вже забезпечує транспортний рівень з’єднання.
Підтримка браузерами, CDN і протоколом
Підтримка Brotli серед браузерів перевищує 95 відсотків за даними caniuse.com станом на середину 2025 року. Практично всі актуальні версії Chrome, Firefox, Safari та Edge вміють як приймати, так і надсилати цей формат. Менш очевидний нюанс: Chrome і Firefox додають br до заголовка Accept-Encoding лише під час з’єднання по HTTPS. Для звичайного HTTP браузер цей формат навіть не пропонує клієнту.
Це пояснює типову ситуацію, коли Brotli несподівано перестає працювати на локальному сервері розробки без сертифіката. Причина не в конфігурації nginx чи Apache. Браузер узагалі не заявляє підтримку формату поза захищеним з’єднанням. Для Gzip такого обмеження немає: він працює однаково і по HTTP, і по HTTPS.
Обмеження і коли жоден варіант не підходить ідеально
Brotli на максимальному рівні непридатний для вмісту, що генерується щоразу заново: сторінки з персоналізованими даними, відповіді API з унікальним корисним навантаженням, потоки, які неможливо кешувати. Виграш у розмірі тут не компенсує витрат часу на стиснення, тому розумний компроміс це Gzip середнього рівня або Brotli на низькому рівні якості, підібраний під конкретне навантаження, а не взятий за замовчуванням.
Gzip, зі свого боку, лишається практично єдиним варіантом там, де клієнт явно не заявляє підтримку Brotli: старі боти, деякі бібліотеки HTTP-клієнтів, внутрішні інтеграції, написані без огляду на сучасні заголовки. Обидва формати однаково непридатні для вже стиснених даних, як-от зображень JPEG чи PNG, відео, архівів. Повторне стиснення такого вмісту здебільшого не дає ефекту або трохи збільшує розмір за рахунок службових даних формату.
Практичний висновок для налаштування сервера
Робоче правило для більшості проєктів виглядає так. Статичні файли, а саме CSS, JavaScript, HTML-шаблони та шрифти, варто стискати Brotli одинадцятого рівня один раз під час збірки або деплою, а готовий файл із розширенням br потім просто віддається знову і знову. Динамічний вміст, який неможливо кешувати, залишається на Gzip середнього рівня або на Brotli низького рівня, попередньо виміряному на реальному навантаженні. У кожному разі сервер повинен вміти віддати обидва формати залежно від заголовка клієнта.
| Параметр | Gzip | Brotli |
|---|---|---|
| Рік випуску | 1992 | 2015 |
| Базовий алгоритм | DEFLATE (LZ77 плюс Гаффман) | LZ77 плюс Гаффман плюс контекстне моделювання |
| Розмір вікна пошуку | 32 КБ, фіксований | до 16 МБ, налаштовуваний |
| Статичний словник | відсутній | близько 122 КБ |
| Швидкість стиснення | висока на всіх рівнях | низька на максимальному рівні |
| Швидкість розпакування | висока | порівнянна з Gzip |
| Підтримка браузерами | практично 100 відсотків | понад 95 відсотків, caniuse.com, середина 2025 року |
| Найкраще застосування | динамічний вміст, старі клієнти | статичні ресурси, попереднє стиснення |
Цифри про частку підтримки браузерами та про відсоток виграшу в розмірі наведені за станом на середину 2025 і на 2026 рік за посиланнями нижче. Специфікація DEFLATE і специфікація Brotli з того часу не змінювалися. Тому механізм, описаний вище, залишається чинним і тоді, коли конкретні відсотки в майбутньому зміняться разом із новими тестами.