Brotli, web performans tartışmalarında uzun süredir Gzip'in yerini alması beklenen algoritma olarak anılır. Sıkıştırma karşılaştırmalarında ortalama %15–20 daha küçük çıktı üretir; tüm modern tarayıcılar destekler; büyük CDN sağlayıcılarının çoğunda artık varsayılan seçenektir. Bu tablo "Brotli her zaman daha iyidir" sonucuna götürür gibi görünse de asıl soru daha dardır: hangi sıkıştırma seviyesinde, hangi içerik türü için ve hangi altyapı koşulunda?

Brotli'nin sıkıştırma seviyeleri 0'dan 11'e uzanır. Seviye 11 maksimum oran üretir, ama CPU maliyeti Gzip'in maksimum seviyesine kıyasla yüzlerce kat yüksek olabilir. Dinamik HTML yanıtlarını her istekte Brotli-11 ile sıkıştırmaya çalışmak, sıkıştırma süresini yanıt süresinin belirleyici faktörüne dönüştürür. Bu yüzden pek çok sunucu Brotli'yi 4–6 arasında kullanır; bu aralıkta performans farkı daralır.

Doğru yapılandırma tek bir algoritma seçiminden ibaret değildir. İçerik statik mi, dinamik mi? Ön-sıkıştırma mümkün mü? CDN sıkıştırmayı devralıyor mu? Hangi MIME türleri hedefleniyor? Bu değişkenler kararı şekillendirir. Brotli ve Gzip'i bu bağlamda anlamak, hangisinin hangi koşulda anlam taşıdığını belirlemenin ön adımıdır.

"Brotli her zaman daha verimlidir" önermesinin sınırı

Brotli'nin üstün sıkıştırma oranı, algoritmanın içinde kullandığı statik sözlük ve LZ77 + Huffman kodlaması kombinasyonundan gelir. Bu sözlük, web içeriğinde sıkça tekrar eden HTML, CSS ve JavaScript kalıplarını önceden tanır; sıkıştırma öncesinde diziyi analiz eden bu mekanizma özellikle metin tabanlı varlıklarda Gzip'e karşı belirgin avantaj sağlar.

Bu avantaj seviyeden seviyeye büyük ölçüde değişir. Brotli-1 ile Gzip-6 arasındaki fark genellikle yüzde birkaç puandır; küçük dosyalarda bazen Gzip lehine bile dönebilir. Brotli-11 ise Gzip-9'a kıyasla %20–26 daha iyi oran üretebilir — ama bu orana ulaşmak için harcanan sıkıştırma süresi üretim ortamında genellikle kabul edilemez düzeydedir.

500 KB'lık sıkıştırılmamış bir JavaScript bundle'ı için somut farkı şöyle ortaya koymak mümkündür: Gzip-6 yaklaşık 170 KB, Brotli-6 yaklaşık 155 KB, Brotli-11 yaklaşık 140 KB çıktı üretir. 15 KB'lık ek kazanım yavaş bağlantılarda 2 saniyeye yakın fark yaratırken modern fiber hatlarda 1 ms'nin altına düşer. Kazanım gerçektir; ama pratik etkisi hedef kitleye göre değişir. Brotli'nin avantajı 1 KB'ın altındaki çok kısa içeriklerde de kaybolabilir; sıkıştırma başlık yükü içeriğin kendisinden büyük hale gelir.

Sıkıştırma oranı ve CPU maliyeti — seviye seçiminin belirleyiciliği

Brotli-11 seviyesi, referans uygulamada küçük dosyalar için bile saniyeler mertebesinde sıkıştırma süresi üretebilir. Caddy, Nginx ve Apache'nin Brotli modülleri dinamik sıkıştırma için genellikle 4–6 arası bir seviye önerir; bu seviyeler Gzip'ten daha iyi oran sunarken CPU maliyetini kontrol altında tutar. Gzip-6 ise uzun süredir üretim ortamlarının güvenli referans noktası olarak kalmaktadır: kabul edilebilir oran, düşük işlemci yükü, evrensel sunucu desteği.

Dinamik içerikte — her istekte sunucu tarafında üretilen HTML, JSON, XML — sıkıştırma anlık yapılır. CPU kaynaklı gecikme doğrudan TTFB'ye yansır. Yüksek trafikli bir uç noktada her sıkıştırma işlemi milisaniyeler mertebesinde olsa bile birikimli etki ölçülebilir. Brotli-11 ile sıkıştırma kazancı bu durumda TTFB artışıyla sıfırlanabilir, hatta net kayba dönüşebilir.

Statik içerikte bu kısıtlama ortadan kalkar. Bir kez sıkıştırıp depolayabileceğiniz dosyalar — CSS bundle'ları, JS chunk'ları, font dosyaları — için Brotli-11 sorunsuz kullanılabilir. Sıkıştırma maliyeti yalnızca bir kez ödenir; her istek için değil. Statik varlıklar için Brotli-11, dinamik yanıtlar için Brotli 4–6 veya Gzip-6 arasında tercih yapmak bu iki koşulun gereksinimlerini ayrı ayrı karşılar.

Statik ön-sıkıştırma ile dinamik sıkıştırmanın yapısal farkı

Ön-sıkıştırma (pre-compression), derleme veya deployment sırasında dosyaların bir kez sıkıştırılarak .br ve .gz uzantılı versiyonlarının sunucu yanında depolanmasıdır. İstek geldiğinde sunucu sıkıştırma yapmaz, yalnızca hazır dosyayı okur ve gönderir. Nginx'te brotli_static on ve gzip_static on direktifleri bu davranışı etkinleştirir; tarayıcının Accept-Encoding başlığına göre uygun varyant seçilir.

Build pipeline'ına ön-sıkıştırma entegre etmek fazla adım gerektirmez. Vite için vite-plugin-compression, Webpack için compression-webpack-plugin hem .gz hem .br çıktı üretebilir. Node.js'in yerleşik zlib modülü Brotli sıkıştırması için yeterlidir; ek bağımlılık gerekmez. Bu yaklaşım content hash ile versiyonlanmış varlıklar için idealdir — hem uzun süreli önbellekleme hem de maksimum sıkıştırma oranı aynı anda sağlanır.

CDN katmanında ön-sıkıştırma anlayışı değişir. Cloudflare, Fastly ve benzeri CDN'ler kendi sıkıştırma mekanizmalarını uygulayabileceğinden kaynak sunucudan gelen sıkıştırılmış içeriği kendi algoritmalarıyla yeniden işleyebilirler. Bazı CDN'ler Brotli'yi yalnızca edge'de destekler; kaynak sunucu ile aralarındaki iletişimde Gzip kullanır. Bu davranışı CDN dokümantasyonundan doğrulamak, beklenmedik sıkıştırma kayıplarını önceden engeller.

Hangi dosya türleri sıkıştırılmalı, hangileri sıkıştırılmamalı

Sıkıştırma her dosya türü için anlamlı değildir. En yüksek kazanım, tekrar eden kalıplar içeren düşük entropili metin dosyalarında ortaya çıkar. HTML, CSS, JavaScript, JSON, XML, SVG ve düz metin dosyaları bu kategorinin başını çeker. CSS ve JavaScript küçültme işlemi önce dosya boyutunu düşürür; sıkıştırma bu temiz tabanın üzerinde çalışır ve ikisi birlikte en yüksek boyut düşüşünü üretir. Küçültme yapılmadan sıkıştırma uygulamak, mümkün olan maksimum kazanımın altında kalır.

Sıkıştırmadan anlamsız veya zararlı sonuç alınan türler de mevcuttur. JPEG, PNG, WebP ve AVIF zaten kayıplı veya kayıpsız kendi sıkıştırma algoritmalarını içerir. Bu görseller üzerinde Gzip veya Brotli çalıştırmak çıktı boyutunu küçük miktarda artırabilir ya da en iyi ihtimalle birkaç byte azaltır; CPU tüketimi kazanıma değmez. WOFF2 font dosyaları kendi sıkıştırmasını içerdiğinden aynı kural geçerlidir. MP4, WebM gibi video ve ses formatları da sıkıştırma gerektirmez.

Küçük dosyalarda sıkıştırma kazanımı hızla düşer. Genel kural olarak 1 KB'ın altındaki dosyaları sıkıştırma dışında bırakmak önerilir; sıkıştırma başlık yükü bu boyuttaki içerik için net kayıp üretebilir. Render engelleyen kaynakları azaltmak ve gereksiz varlıkları temizlemek, sıkıştırmanın işleyeceği temel boyutu düşürür. Sıkıştırma bu adımların üzerine kurulan son katmandır, ilk değil.

Sunucu ve CDN yapılandırmasında iki algoritmayı birlikte kullanmak

Üretim ortamında iki algoritmanın birlikte yapılandırılması standart pratiktir. Tarayıcı Accept-Encoding: br, gzip başlığıyla tercihlerini iletir; sunucu desteklediği en iyi seçeneği uygular. Nginx'te Brotli için ngx_brotli modülünün derleme sırasında eklenmesi gerekir; standart Nginx paketine dahil değildir. Temel yapılandırma şu şekildedir:

# nginx.conf
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript application/json image/svg+xml;

gzip on;
gzip_comp_level 6;
gzip_types text/html text/css application/javascript application/json image/svg+xml;
gzip_vary on;

gzip_vary on direktifi yanıta Vary: Accept-Encoding başlığını ekler. Bu başlık CDN'lere ve proxy'lere, aynı URL için farklı sıkıştırma formatlarının ayrı önbellek girişleri oluşturması gerektiğini söyler. Direktif olmadan CDN, Brotli destekli kullanıcı için önbelleğe aldığı Gzip yanıtını Brotli desteklemeyen kullanıcıya sunabilir — ya da tam tersi. Cache-Control ve doğrulama mekanizmaları Vary başlığıyla birlikte doğru çalıştığında önbellek tutarlılığı sağlanır.

CDN katmanında davranış sağlayıcıya göre farklılaşır. Cloudflare Brotli'yi destekler, ama yalnızca HTTPS bağlantılarında ve sıkıştırma seviyesi Cloudflare tarafından kontrol edilir. Fastly, Brotli için VCL yapılandırması gerektirir. AWS CloudFront, Brotli desteğini belirli dağıtım ayarları üzerinden etkinleştirir. Önbellekleme stratejisi kurulurken CDN'in sıkıştırma davranışını önceden doğrulamak, sıkıştırılmamış içeriğin sessizce servis edilmesi gibi sorunları önler.

Apache'de mod_deflate ve mod_brotli modülleri benzer biçimde yapılandırılır. Node.js tabanlı uygulamalarda compression middleware'i Gzip ve Deflate'i destekler; Brotli için zlib.createBrotliCompress() doğrudan kullanılabilir. IIS'te Brotli desteği 10.0.17763 sürümünden itibaren mevcuttur ve yapılandırma site düzeyinde yapılır.

Brotli, doğru koşulda uygulandığında Gzip'e göre gerçek bir avantaj sunar — özellikle statik metin varlıkları, ön-sıkıştırılmış dosyalar ve CDN edge sıkıştırması söz konusu olduğunda. Ama bu avantaj yüksek sıkıştırma seviyeleri ve yüksek trafikli dinamik yanıtlarla birleştiğinde CPU maliyetiyle dengelenir. Fark her ortamda eşit değildir; yüksek CPU kaynaklı statik dosya servisi ile düşük gecikme gerektiren dinamik API arasında yapılandırma kararı ayrışmalıdır.

Pratikte önerilen yaklaşım şudur: statik varlıklar için build pipeline'ında Brotli-11 ile ön-sıkıştırma yapın, sunucuda brotli_static on ile servis edin. Dinamik yanıtlar için Brotli 4–6 veya Gzip-6 arasında sunucu kaynaklarına göre karar verin. Her iki durumda da Gzip'i kaldırmayın — Brotli desteklemeyen eski tarayıcılar ve bazı proxy'ler hâlâ Gzip bekler. Vary başlığını unutmayın; hem tarayıcı hem CDN katmanında doğru varyantın sunulmasının güvencesi oradadır.