Gzip ve Brotli Karşılaştırması

Bir site hız testi çalıştırdığınızda karşınıza çıkan ilk uyarılardan biri neredeyse her zaman "metin tabanlı kaynakları sıkıştırın" olur. Gzip ve Brotli tam olarak bu işi yapan iki sıkıştırma algoritmasıdır: HTML, CSS, JavaScript ve JSON gibi metin dosyalarını sunucudan tarayıcıya göndermeden önce küçültür, tarayıcı da açıp kullanır. Aradaki fark birkaç kilobayt gibi görünse de, 300 KB'lık bir JavaScript paketinin 90 KB yerine 75 KB inmesi mobil bağlantıda ölçülebilir bir kazanç demektir.

Bu rehberde gzip ve Brotli'nin nasıl çalıştığını, hangi durumda hangisinin daha mantıklı olduğunu, sıkıştırma seviyesinin CPU maliyetini nasıl değiştirdiğini ve Nginx, Apache ile LiteSpeed üzerinde nasıl doğru yapılandırılacağını anlatacağım. Ayrıca "her şeyi sıkıştıralım" refleksinin neden yanlış olduğunu, hangi dosya tiplerinin sıkıştırılmaması gerektiğini ve sıkıştırmanın gerçekten çalışıp çalışmadığını nasıl doğrulayacağınızı göstereceğim.

Sıkıştırma HTTP Katmanında Nasıl Çalışır#

HTTP sıkıştırması bir pazarlık (negotiation) mekanizmasıdır. Tarayıcı her istekte hangi sıkıştırma biçimlerini desteklediğini Accept-Encoding başlığıyla bildirir; sunucu bu listeden birini seçer, içeriği sıkıştırıp Content-Encoding başlığıyla hangi biçimi kullandığını söyler. Tarayıcı da aynı algoritmayla açar. Modern bir tarayıcının gönderdiği başlık genellikle şuna benzer:

# Tarayıcının gönderdiği istek başlığı
Accept-Encoding: gzip, deflate, br, zstd

# Sunucunun döndüğü yanıt başlığı
Content-Encoding: br
Vary: Accept-Encoding

Buradaki br Brotli'yi, gzip ise klasik DEFLATE tabanlı gzip'i temsil eder. Vary: Accept-Encoding başlığı ise ara katmandaki önbelleklere "bu yanıtın sıkıştırılmış ve sıkıştırılmamış sürümlerini ayrı ayrı sakla" der. Bu başlığı unutursanız, bir CDN veya proxy Brotli destekleyen bir tarayıcıya verdiği yanıtı destekleyemeyen eski bir istemciye de servis edebilir ve karşınıza bozuk sayfalar çıkar.

Bir noktayı baştan netleştirelim: tarayıcılar br desteğini pratikte yalnızca HTTPS bağlantılarda ilan eder. Yani sitenizde Brotli'yi açtınız ama hâlâ gzip görüyorsanız, ilk bakacağınız yer sertifikanız ve bağlantının gerçekten TLS üzerinden kurulup kurulmadığıdır. Sertifika tarafında eksiğiniz varsa SSL sertifikası sayfasındaki seçenekler işi birkaç dakikada halleder.

Gzip: Kanıtlanmış, Her Yerde Çalışan Standart#

Gzip 1990'ların başından beri hayatımızda ve DEFLATE algoritmasını kullanır: önce LZ77 ile tekrar eden dizileri geriye referansla değiştirir, sonra Huffman kodlamasıyla sık geçen sembolleri daha kısa bitlerle temsil eder. Sıkıştırma seviyesi 1 ile 9 arasında ayarlanır; 1 en hızlı ama en zayıf, 9 en yavaş ama en iyi sıkıştırandır. Pratikte 9'un 6'ya göre kazandırdığı yüzde birkaçlık fark, harcadığı ekstra CPU'yu genellikle hak etmez.

Gzip'in en güçlü yanı evrenselliğidir. Yeryüzünde HTTP konuşan ve gzip anlamayan bir istemci bulmak neredeyse imkânsız; bu yüzden gzip'i asla tamamen kapatmayın. Brotli'yi eklerken bile gzip yedek olarak açık kalmalıdır. Nginx'te tipik ve dengeli bir gzip yapılandırması şöyle görünür:

# /etc/nginx/conf.d/gzip.conf
gzip on;
gzip_vary on;                 # Vary: Accept-Encoding başlığını ekler
gzip_comp_level 5;            # 1-9 arası; 5 hız/oran dengesi için iyi bir nokta
gzip_min_length 256;          # 256 bayttan küçük yanıtları sıkıştırma
gzip_proxied any;             # proxy arkasından gelen istekleri de sıkıştır
gzip_types
    text/plain
    text/css
    text/xml
    application/javascript
    application/json
    application/xml
    application/rss+xml
    image/svg+xml;

gzip_types listesinde text/html görmediğinize dikkat edin; Nginx HTML'i her zaman sıkıştırır ve listeye eklerseniz yapılandırma testinde uyarı alırsınız. gzip_min_length değeri de önemlidir: gzip'in kendi başlık ve sözlük yükü yaklaşık 20 baytdır, dolayısıyla 100 baytlık bir JSON yanıtını sıkıştırdığınızda dosya küçülmek yerine büyüyebilir.

Brotli: Web İçin Tasarlanmış Modern Alternatif#

Brotli, Google tarafından geliştirilen ve 2016'dan itibaren tarayıcılarda yaygınlaşan bir algoritmadır. Gzip'ten iki önemli farkı vardır. Birincisi, içinde web'de en sık geçen HTML etiketleri, CSS özellikleri ve JavaScript anahtar kelimelerinden oluşan yerleşik bir statik sözlük taşır; yani <!doctype html> ya da function gibi dizileri sıfırdan öğrenmek zorunda kalmaz. İkincisi, çok daha geniş bir kayan pencere (sliding window) kullanabilir, bu da büyük dosyalarda uzak mesafedeki tekrarları yakalamasını sağlar.

Sonuç olarak metin tabanlı içerikte Brotli tipik olarak gzip'ten %15 ila %25 daha iyi sıkıştırır. Ama bedeli vardır: seviye aralığı 0-11'dir ve üst seviyeler ciddi biçimde CPU yer. Aşağıdaki tablo, tipik bir modern JavaScript paketinde gördüğüm davranışı özetliyor. Rakamlar dosyanıza göre değişir, önemli olan eğilimdir:

Tablodan çıkan pratik kural şudur: dinamik içerikte Brotli 4-5, statik dosyalarda Brotli 11. Brotli 11'i canlı bir PHP çıktısına uygularsanız her istekte yüz milisaniyeleri bulan bir CPU maliyeti ödersiniz ve sunucunuz yoğun saatte tıkanır. Statik dosyada ise sıkıştırmayı bir kez build sırasında yaparsınız, sunucu sadece hazır dosyayı okur.

Nginx ve Apache Üzerinde Brotli'yi Açmak#

Nginx'te Brotli çekirdek dağıtımın parçası değildir; ngx_brotli modülünü dinamik modül olarak derlemeniz ya da dağıtımınızın hazır paketini kurmanız gerekir. Modül yüklendikten sonra yapılandırma gzip'e çok benzer:

# Modülleri yükle (nginx.conf'un en üstünde, http bloğundan önce)
load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

# http { } bloğu içinde
brotli on;
brotli_comp_level 5;          # dinamik yanıtlar için dengeli seviye
brotli_min_length 256;
brotli_static on;             # dosya.js.br varsa doğrudan onu servis et
brotli_types
    text/plain
    text/css
    application/javascript
    application/json
    application/xml
    image/svg+xml;

brotli_static on satırı en değerli kısımdır. Bu ayar açıkken Nginx, app.js istendiğinde aynı dizinde app.js.br dosyası olup olmadığına bakar; varsa hiç CPU harcamadan doğrudan onu gönderir. Böylece build sürecinizde en yüksek kalitede sıkıştırıp sunucuyu tamamen yükten kurtarabilirsiniz:

# Build çıktısındaki tüm statik dosyaları en yüksek kalitede önceden sıkıştır
find ./dist -type f \( -name '*.js' -o -name '*.css' -o -name '*.svg' \) \
  -exec brotli -q 11 -k {} \; \
  -exec gzip -9 -k {} \;

# -k anahtarı orijinal dosyayı korur, .br ve .gz yan yana durur

Apache 2.4.26 ve sonrasında Brotli mod_brotli ile gelir. Etkinleştirmek için modülü açıp bir filtre tanımlarsınız:

# Debian/Ubuntu üzerinde modülü etkinleştir
sudo a2enmod brotli
sudo systemctl reload apache2

# /etc/apache2/conf-available/brotli.conf
<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css
    AddOutputFilterByType BROTLI_COMPRESS application/javascript application/json
    AddOutputFilterByType BROTLI_COMPRESS image/svg+xml
    BrotliCompressionQuality 5
    BrotliCompressionMaxInputBlock 20
</IfModule>

Paylaşımlı hosting kullanıyorsanız sunucu yapılandırmasına erişemezsiniz ama .htaccess üzerinden aynı direktiflerin çoğunu tanımlayabilirsiniz; ayrıntılı örnekleri htaccess önbellek ve sıkıştırma yazısında bulabilirsiniz. LiteSpeed tabanlı sunucularda ise Brotli yerleşiktir ve genellikle kontrol panelinden tek bir onay kutusuyla açılır; LiteSpeed'in davranış farkları için LiteSpeed ve Apache karşılaştırması yazısına bakabilirsiniz.

Sıkıştırmanın Gerçekten Çalıştığını Doğrulamak#

Yapılandırmayı yazdınız, servisi yeniden yüklediniz; peki gerçekten çalışıyor mu? Bunu tarayıcı geliştirici araçlarına bakmadan, doğrudan komut satırından doğrulamak en temizidir. curl ile hangi kodlamayı kabul ettiğinizi kendiniz belirtirsiniz:

# Brotli desteği bildirerek yanıt başlıklarını al
curl -s -I -H 'Accept-Encoding: br' https://firmaniz.com/assets/app.js | grep -i -E 'content-encoding|content-length|vary'

# Beklenen çıktı:
# content-encoding: br
# content-length: 74210
# vary: Accept-Encoding

# Aynı dosyayı gzip ile iste, farkı gör
curl -s -I -H 'Accept-Encoding: gzip' https://firmaniz.com/assets/app.js | grep -i content-length
# content-length: 91884

Sıkıştırmasız boyutla karşılaştırmak isterseniz Accept-Encoding: identity gönderin. Üç rakamı yan yana koyduğunuzda kazancın gerçek büyüklüğünü görürsünüz. Toplam sayfa ağırlığının aylık trafiğinize etkisini merak ediyorsanız bant genişliği hesaplayıcı aracıyla kaba bir hesap yapabilirsiniz; metin ağırlıklı bir sitede Brotli'ye geçmek aylık çıkış trafiğinde gözle görülür bir düşüş yaratır.

Tarayıcı tarafında da doğrulama yapmak isterseniz Ağ (Network) sekmesinde bir isteğe tıklayıp yanıt başlıklarına bakın. Chrome'da "Size" sütununda iki satır görürsünüz: üstteki ağdan geçen sıkıştırılmış boyut, alttaki açılmış gerçek boyuttur. Bu ikisi eşitse sıkıştırma o istek için hiç uygulanmamış demektir.

Neyi Sıkıştırmamalısınız ve Diğer Tuzaklar#

En sık yapılan hata, "ne kadar çok sıkıştırırsam o kadar iyi" varsayımıyla tüm MIME tiplerini listeye eklemektir. JPEG, PNG, WebP, AVIF, MP4 ve ZIP dosyaları zaten kendi içlerinde sıkıştırılmıştır; bunları tekrar sıkıştırmak boyutu neredeyse hiç düşürmez ama her istekte CPU harcar ve bazen dosyayı birkaç bayt büyütür. Aynı şey woff2 yazı tipleri için de geçerlidir: WOFF2 formatı zaten Brotli ile paketlenmiştir, üstüne bir kat daha eklemek anlamsızdır.

İkinci tuzak, çok küçük yanıtları sıkıştırmaktır. Bir sağlık kontrolü ucundan dönen 40 baytlık {"status":"ok"} yanıtı sıkıştırıldığında 60 bayta çıkabilir. gzip_min_length ve brotli_min_length değerlerini 256 bayt civarında tutmak bu israfı önler.

Üçüncüsü Vary: Accept-Encoding başlığını unutmaktır. Nginx'te gzip_vary on ve brotli_vary on (modül destekliyorsa) bu başlığı ekler. Önünüzde bir CDN veya ters proxy varsa bu başlık olmadan yanlış istemciye yanlış kodlama servis edilebilir. Önbellek katmanlarının nasıl davrandığını daha derin incelemek isterseniz Nginx FastCGI cache yapılandırma yazısı önbellek anahtarlarının nasıl kurulduğunu açıklar.

Dördüncüsü güvenlik tarafındadır: kullanıcıya özel bir gizli değer (örneğin bir CSRF belirteci) içeren ve aynı zamanda kullanıcıdan gelen girdiyi yansıtan yanıtları sıkıştırmak, BREACH tipi yan kanal saldırılarına zemin hazırlayabilir. Pratikte bunu tetiklemek zordur ama oturum belirteci taşıyan API yanıtlarında sıkıştırmayı kapatmak ya da belirteci her yanıtta maskelemek makul bir önlemdir.

Son olarak, statik dosyalarınızı her istekte yeniden sıkıştırmayın. brotli_static ve gzip_static ayarları tam olarak bunun için vardır. Build aşamasında bir kez sıkıştırılan dosya, milyonlarca istekte sıfır CPU ile servis edilir. Bu, Brotli 11'in gerçek gücünü bedava kullanmanın tek yoludur.

Sıkça Sorulan Sorular#

Brotli gzip'in yerini tamamen alabilir mi#

Hayır, ikisini birlikte açık tutmalısınız. Brotli desteği yaygın olsa da eski istemciler, bazı komut satırı araçları ve HTTPS olmayan bağlantılar hâlâ yalnızca gzip anlar. Sunucu, tarayıcının Accept-Encoding başlığına bakarak zaten en iyisini seçer; Brotli varsa onu, yoksa gzip'i kullanır. Gzip'i kapatmanın hiçbir kazancı yoktur, yalnızca risk yaratır.

Brotli sıkıştırma seviyesi kaç olmalı#

Dinamik olarak üretilen HTML ve API yanıtları için 4 ya da 5 doğru cevaptır; bu seviyeler gzip'in varsayılanından daha iyi sıkıştırır ve CPU maliyeti kabul edilebilir kalır. Seviye 11'i yalnızca build sırasında önceden sıkıştırdığınız statik JavaScript, CSS ve SVG dosyaları için kullanın. Canlı trafikte seviye 11 kullanmak, yoğun saatlerde PHP-FPM havuzunuzu bekletecek kadar pahalıdır.

Sıkıştırma açıksa site ne kadar hızlanır#

Kazanç sitenizin içerik dağılımına bağlıdır. Metin ağırlıklı bir sayfada aktarılan bayt miktarı %60-75 azalır, bu da özellikle mobil ve yüksek gecikmeli bağlantılarda ilk yükleme süresine doğrudan yansır. Görsel ve video ağırlıklı bir sayfada ise toplam kazanç daha küçüktür, çünkü sayfa ağırlığının büyük kısmı zaten sıkıştırılamayan medya dosyalarından oluşur. Gerçek etkiyi görmek için sıkıştırmayı açıp kapatarak aynı sayfayı iki kez ölçün.

Paylaşımlı hostingde Brotli kullanabilir miyim#

Çoğu modern paylaşımlı hosting altyapısı Brotli'yi sunucu seviyesinde açık tutar; LiteSpeed tabanlı sistemlerde bu neredeyse standarttır. Kendi tarafınızdan doğrulamak için sitenize curl -I -H 'Accept-Encoding: br' isteği gönderip yanıtta content-encoding: br görüp görmediğinize bakın. Kapalıysa ve panelde bir seçenek yoksa destek ekibinden açılmasını isteyebilirsiniz; sunucu genelinde bir ayar olduğu için genellikle hızlı çözülür.

Sıkıştırma açık ama boyut değişmiyor, nedendir#

En yaygın üç sebep şunlardır: dosyanın MIME tipi gzip_types veya brotli_types listesinde yoktur, dosya min_length eşiğinin altındadır, ya da yanıt zaten sıkıştırılmış bir formattır. Ayrıca önünüzde bir CDN veya proxy varsa, sıkıştırmayı orada devre dışı bırakmış olabilirsiniz. Sunucudan doğrudan curl ile istek atarak katmanları teker teker eleyin; sunucu doğru davranıyorsa sorun aradaki katmandadır.

WordPress sitesinde sıkıştırmayı eklenti ile mi açmalıyım#

Mümkünse hayır. Sıkıştırma web sunucusunun işidir ve orada yapıldığında PHP'ye hiç uğramadan, çok daha verimli çalışır. Bir önbellek eklentisi sıkıştırma seçeneği sunuyorsa bunu yalnızca sunucu seviyesinde açamıyorsanız kullanın. Sunucuda ve eklentide aynı anda açmak, bazı yapılandırmalarda çift sıkıştırmaya ve bozuk sayfalara yol açabilir; birini seçip diğerini kapatın.

Kapanış#

Sıkıştırma, performans işlerinde emek-kazanç oranı en yüksek adımlardan biridir: birkaç satır yapılandırmayla sayfa ağırlığınızın büyük bölümünü ağdan silersiniz. Aklınızda kalması gereken dört şey var. Gzip'i asla kapatmayın, Brotli'yi yanına ekleyin. Dinamik içerikte Brotli 4-5, statik dosyalarda önceden sıkıştırılmış Brotli 11 kullanın. Zaten sıkıştırılmış medya ve yazı tipi dosyalarını listeye koymayın. Ve her değişiklikten sonra curl ile content-encoding başlığını gözünüzle doğrulayın.

Sunucu yapılandırmasına elinizi sürmeden Brotli açık, önbellekli ve ayarlanmış bir altyapı istiyorsanız Clou.TR paketleri bu işi hazır sunar. LiteSpeed tabanlı web hosting ve WordPress hosting paketlerimizde sıkıştırma varsayılan olarak etkindir; kendi Nginx yapılandırmanızı satır satır yazmak isterseniz tam root erişimli VDS sunucu seçeneklerimiz uygundur. Yapılandırmayı bizim üstlenmemizi tercih ederseniz sunucu yönetimi hizmetimiz sıkıştırma, önbellek ve TLS ayarlarını birlikte kurar.