Gzip mi Brotli mı? Web sitenizde doğru sıkıştırma ayarı

Sıkıştırma ayarı, sitenin “sayfa açılış hızını” etkileyen en doğrudan parametrelerden biridir. Gzip ve Brotli, tarayıcı ile sunucu arasındaki veri transferini azaltır; bu da ilk yanıt süresini ve toplam indirme maliyetini düşürür. Ancak doğru eşleştirme yapılmazsa gereksiz CPU kullanımı veya beklenmedik uyumsuzluklar oluşur. Bu rehberde Gzip / Brotli sıkıştırma kararını, kapsamlı ama net test adımlarıyla yapacağınız şekilde ele alacağız.

Gzip ve Brotli neyi değiştirir? (Yanıt boyutu, CPU ve uyumluluk)

Sıkıştırma, HTTP yanıtlarını (genellikle HTML, CSS, JavaScript, bazı durumlarda JSON) tarayıcıya gönderilmeden önce küçültür. Bunun sonucu olarak:

• Transfer edilen bayt azalır (TTFB ve sayfa yükleme süresi iyileşebilir).
• Sunucuda CPU yükü artar (özellikle “dinamik sıkıştırma” senaryolarında).
• Uyumluluk açısından tarayıcı desteği önem kazanır.

İstemci (tarayıcı) ne ister? Accept-Encoding

Tarayıcılar sunucuya şu başlıkla hangi sıkıştırmaları kabul ettiklerini bildirir:

• Accept-Encoding: gzip, deflate, br

Burada br Brotli; gzip ise Gzip anlamına gelir. Sunucu, bu başlığa göre hangi algoritmayı kullanacağını seçer.

Statik mi dinamik mi? Önbellek (cache) etkisi

• Statik dosyalarda (ör. /assets/app.css) sıkıştırma bir kez yapılıp saklanabilir; CPU yükü düşer.
• Dinamik içerikte (ör. uygulama tarafından anlık üretilen HTML) sıkıştırma her istekle yapılabilir; CPU yükü artar.

Bu yüzden karar, sadece “hangisi daha iyi?” değil “hangi içerik türünde nasıl çalışıyor?” sorusudur.

Hangisi daha iyi? Net karşılaştırma (performans ve pratik sonuçlar)

Aşağıdaki karşılaştırma, genel davranışı özetler. Tek doğru seçim genellikle “Brotli varsa Brotli, yoksa Gzip” yaklaşımıdır; asıl mesele bunu doğru şekilde etkinleştirmektir.

Net sonuç: “Tekini seç” yerine “ikisini doğru sırayla sun”

Pratikte şu hedeflenir:

1. Tarayıcı Brotli (br) destekliyorsa Brotli yanıtı gönder.
2. Brotli desteklemiyorsa Gzip gönder.

Böylece en uyumlu ve en verimli algoritma otomatik seçilir.

Sunucu tarafında doğru ayar mantığı (1 tercih değil, 2 kural)

Sunucunuz Nginx mi Apache mi, yoksa yönetim paneliniz (ör. cPanel/DirectAdmin) mi kullanıyor; ayarların adı değişebilir. Ama mantık aynı kalır:

• br varsa onu tercih et (Brotli önceliği)
• gzip yedek olsun

Nginx için hedef davranış

Nginx yapılandırmasında amaç, aşağıdaki davranışa ulaşmaktır:

• Accept-Encoding içinde br geçen istemcilere Content-Encoding: br
• br yoksa Content-Encoding: gzip

Bu noktada kritik iki ayar vardır:

1. Sıkıştırma seviyesi (compression level): Çok yüksek seviye CPU’yu şişirir.
2. Hangi MIME türleri sıkıştırılıyor?: Yanlış türleri sıkıştırmak faydadan çok maliyet getirebilir.

Apache için hedef davranış

Apache tarafında da beklenen davranış şudur:

• Brotli modülü varsa ve istemci br kabul ediyorsa Brotli üret
• Yoksa Gzip devreye girsin

“Hangisi açık olmalı?” sorusunun net cevabı

Tek bir algoritma seçmek yerine, şu şekilde cevap vermek gerekir:

• Brotli açık olmalı. (Tarayıcı desteklediği sürece daha iyi sıkıştırma oranı sağlar.)
• Gzip açık kalmalı. (Brotli desteği olmayan istemciler ve bazı ara katmanlar için sağlam bir yedek olur.)

Yani doğru strateji: Brotli + Gzip birlikte açık, ama tarayıcı desteğine göre otomatik seçim.

Bunun istisnası, çok dar bir kullanım senaryosudur: - Çok eski tarayıcı yoğunluğu yoksa ve sunucu maliyetini minimumda tutmak istiyorsanız bile, Gzip’i tamamen kapatmak yerine çoğu durumda kapatmaya gerek kalmaz; çünkü otomatik yedek davranışı vardır.

Hangi dosyalar sıkıştırılmalı? CDN ve cache ile birlikte düşünün

Sıkıştırma, her içerikte aynı etkiyi vermez.

Açık bir hedef liste (önerilen MIME türleri)

Aşağıdaki türler genellikle en iyi kazancı sağlar:

• text/html
• text/css
• application/javascript (ve bazı durumlarda text/javascript)
• application/json
• application/xml / text/xml
• image/svg+xml (SVG vektör olduğu için sıklıkla fayda verir)
• application/font-woff / woff2 için dikkat: Fontlar çoğu zaman zaten optimize edilmiş olur; ekstra sıkıştırma bazen sınırlı fayda sağlar.

Sıkıştırmamak gerekenler (net gerekçe)

• Zaten sıkıştırılmış dosyalar: JPG, MP4, bazı PNG varyantları, ZIP gibi arşivler.
• Dosya türüne göre sıkıştırma faydası çok düşer; CPU maliyeti geri dönmez.

Doğru ayarı doğrulama: 3 adımda net test

Kararı “hissiyatla” değil ölçümle verin. Aşağıdaki adımlar, Gzip/Brotli’nin gerçekten çalıştığını ve doğru algoritmanın tercih edildiğini net gösterir.

1) Tarayıcıdan başlık kontrolü

Chrome/Firefox’ta DevTools -> Network -> istenen dosya -> Response Headers bölümünde şu alanı arayın:

• Content-Encoding: br veya Content-Encoding: gzip

Ayrıca istek başlıklarında Accept-Encoding değerini kontrol edin.

2) Aynı dosyayı farklı istemci profilleriyle dene

• Brotli destekleyen bir tarayıcıyla (modern Chrome/Edge gibi) br görmelisiniz.
• Brotli desteklemeyen bir istemci simülasyonunda (ya da Accept-Encoding zorlayarak) gzip görmelisiniz.

3) Cache etkisini kontrol et (özellikle CDN kullanıyorsanız)

CDN veya proxy varsa şu risk oluşur: - CDN sıkıştırmayı farklı katmanda yapıyor olabilir. - Origin’de Brotli açıkken CDN tekrar sıkıştırmıyor/etmiyor olabilir.

Sonuçta hem performans hem de Content-Encoding başlığı beklediğiniz gibi gelmeyebilir.

Bu yüzden doğrulama testini: - CDN üzerinden final yanıtı alarak - ve mümkünse origin yanıtını da ayrı kontrol ederek yapın.

Performans bütçesi: CPU’yu nasıl kontrol edeceksiniz?

Brotli daha iyi sıkıştırma sunar; ancak yanlış kalite seviyesinde CPU maliyeti artar.

Net kontrol listesi

• Sunucuda CPU kullanımını yük testi sırasında ölçün.
• Yanıt süreleri (TTFB) bozuluyor mu bakın.
• “Sıkıştırma seviyesi”yi kademeli düşürme/yükseltme yapın.

Pratik strateji

• Yüksek trafik altında, Brotli kalite seviyesini çok agresif seçmek yerine dengeli bir ayar kullanın.
• Statik içerikte pre-compression (dosya önceden sıkıştırma) yaklaşımı varsa onu tercih edin.

Bu yaklaşım, her istekte sıkıştırma üretmek yerine önceden hazırlanmış içerik sunarak CPU yükünü düşürür.

Nginx/Apache/Panel farkı: “Açtım ama çalışmıyor” sorunlarının yaygın nedeni

Gzip veya Brotli görünür şekilde “açık” olsa bile çalışmama sık görülür. En yaygın nedenler:

• İlgili modül etkin değil (Brotli modülü yüklenmemiş)
• Vary: Accept-Encoding başlığı yanlış/eksik (yanlış önbellek varyantı servis edebilir)
• Cache katmanı sıkıştırmayı devralmış veya devre dışı bırakmıştır
• Sıkıştırma yalnızca belirli MIME türlerinde tanımlanmadığı için dosya türü kapsam dışıdır

Net teşhis yöntemi

• Aynı dosyanın yanıtında Content-Encoding var mı?
• Vary: Accept-Encoding yanıt başlığında görünüyor mu?
• CDN varsa, CDN loglarında sıkıştırma/encapsulation davranışı nasıl?

Karar: NetKıyas mantığıyla uygulama planı

Bu konuyu “tek seferlik ayar” değil “doğrulama + iterasyon” olarak ele alın. Önerilen plan:

1. Brotli + Gzip birlikte açık olacak şekilde sunucunuzu kurun.
2. Sadece kazancı yüksek MIME türlerini sıkıştırma kapsamına alın.
3. Content-Encoding ve Vary: Accept-Encoding başlıklarını test edin.
4. CDN kullanıyorsanız, testleri hem CDN öncesi hem sonrası yapın.
5. CPU yükü artıyorsa Brotli kalite seviyesini düşürün veya statik içerik için ön sıkıştırma yöntemini devreye alın.

Sonuç: “Gzip mi Brotli mi?” yerine “Brotli varken Brotli”

Net karar şudur: Brotli açık olmalı, çünkü destekleyen tarayıcılarda indirme maliyetini daha fazla düşürür. Gzip de açık kalmalı, çünkü Brotli desteği olmayan istemciler için tutarlı bir performans ve uyumluluk sağlar. En doğru adım, önce iki algoritmayı da uygun şekilde etkinleştirmek; ardından Content-Encoding başlığını doğrulayıp CPU/TTFB etkisini ölçerek ayarı sonlandırmaktır.

İsterseniz hedeflediğiniz sunucu (Nginx mi Apache mi), CDN kullanıp kullanmadığınız ve içerik türünüz (statik ağırlık mı dinamik mi) bilgisini yazın; buna göre hangi MIME türleriyle başlayacağınızı ve hangi ölçüm metriklerine bakmanız gerektiğini netleştirecek bir kontrol listesi çıkarabilirim.