Gzip, Brotli ve Sıkıştırma Teknikleri

Gzip, Brotli ve Sıkıştırma Teknikleri

Web performans optimizasyonunda en ucuz kazançlardan biri, gönderilen veriyi sıkıştırmaktır. Bir JavaScript dosyası veya HTML sayfası, sıkıştırıldığında boyutunun %70-80'ini kaybedebilir. Ancak "sıkıştır" demek yeterli değildir; hangi algoritma, hangi seviye ve hangi içerik için kullanılacağı, performans ve maliyet dengesini belirler.

1. Gzip: Evrensel Fallback

Gzip, DEFLATE algoritmasına dayanan, 1990'lardan beri kullanılan ve tüm tarayıcılar tarafından desteklenen tek sıkıştırma yöntemidir. Accept-Encoding: gzip başlığı, her istemciden gelir.

Avantajları:

Evrensel Uyumluluk: Hiçbir istemci Gzip'i reddetmez.
Hızlı Sıkıştırma: Brotli'ye göre çok daha az CPU tüketir. 1MB rastgele veri için Gzip ~26ms harcarken, Brotli ~1115ms harcar .
Düşük Bellek Kullanımı: Aynı testte Gzip 7.14MB bellek kullanırken, Brotli 131.4MB kullanmıştır .

Dezavantajları:

Daha Düşük Sıkıştırma Oranı: Özellikle metin tabanlı varlıklarda Brotli'nin gerisinde kalır.
Küçük Veride Verimsizlik: Çok küçük yüklerde sıkıştırma, orijinal boyuttan daha büyük çıktı üretebilir. Örneğin 84 byte'lık bir yük, Gzip ile 93 byte'a çıkmıştır .

2. Brotli: Modern Web İçin Optimize Edilmiş

Brotli, Google tarafından 2013'te geliştirilen ve özellikle HTTP içerik sıkıştırması için tasarlanmış bir algoritmadır. Modern tarayıcıların tamamı (Chrome 50+, Firefox 44+, Safari 11+, Edge 15+) Accept-Encoding: br başlığını destekler .

Avantajları:

Daha Yüksek Sıkıştırma Oranı: Metin, HTML, JS ve CSS'te Gzip'e göre %15-25 daha küçük çıktı üretir. Kalite seviyesi 11'de bu fark %25-40'a çıkar .
Yerleşik Sözlük: Brotli, web içeriğinde sık kullanılan kelimeleri (HTML etiketleri, JavaScript anahtar kelimeleri) içeren bir sözlükle gelir; bu, küçük dosyalarda bile etkili sıkıştırma sağlar.
Daha Hızlı Dekompresyon: İlginç bir şekilde, Brotli ile sıkıştırılmış verinin açılması Gzip'e göre daha hızlıdır. Raspberry Pi üzerinde yapılan bir ölçümde Brotli dekompresyonu 13.8μs sürerken, Gzip 29.2μs sürmüştür .

Dezavantajları:

Yavaş Sıkıştırma: Özellikle yüksek kalite seviyelerinde çok yavaştır. 1MB veri için 1 saniyeden fazla CPU harcayabilir .
Yüksek Bellek Tüketimi: Sıkıştırma sırasında Gzip'in ~18 katı bellek kullanabilir .

3. Kritik Ayrım: Statik vs. Dinamik İçerik

Sıkıştırma stratejisi, içeriğin ne zaman sıkıştırıldığına bağlıdır:

Statik Varlıklar (JS, CSS, font, görsel):
Bu dosyalar derleme zamanında (build-time) bir kez sıkıştırılır ve binlerce kez sunulur. Bu nedenle sıkıştırma hızı önemsizdir; en yüksek sıkıştırma oranı hedeflenmelidir. Brotli kalite seviyesi 11 ile önceden sıkıştırma yapın .

Dinamik Yanıtlar (HTML, API JSON):
Bu yanıtlar her istekte yeniden sıkıştırılır. Burada CPU maliyeti ve gecikme kritik hale gelir. Brotli kalite 11 bu senaryoda uygun değildir; bunun yerine:

Brotli kalite 4-6: Gzip 6 ile benzer hızda, daha iyi oran .
Zstd: Cloudflare'in ölçümlerine göre Zstd, Brotli'ye yakın sıkıştırma oranı sunarken %42 daha hızlı sıkıştırır. Dinamik yanıtlar için güçlü bir alternatiftir .

4. ASP.NET Core'da Sıkıştırma Yapılandırması

ASP.NET Core, yerleşik Response Compression Middleware ile Brotli ve Gzip desteği sunar.

csharp

// Program.cs
builder.Services.AddResponseCompression(options =>
{
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(
        new[] { "image/svg+xml" }); // SVG'yi de sıkıştır
});

// Brotli kalite seviyesi (varsayılan: Fastest)
builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Optimal; // Daha iyi oran, daha yavaş
});

builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Fastest;
});

app.UseResponseCompression();

Varsayılan Davranış: İstemci br destekliyorsa Brotli, desteklemiyorsa Gzip kullanılır . Middleware, Accept-Encoding başlığına bakar; identity veya q=0 değerlerini dikkate almaz .

Dikkat Edilmesi Gerekenler:

HTTPS'te Sıkıştırma: EnableForHttps varsayılan olarak kapalıdır. Dinamik içerikte sıkıştırma, BREACH gibi güvenlik açıklarına zemin hazırlayabilir; yalnızca gerekliyse ve güvenlik önlemleri alındıysa açın .
MIME Tipleri: Varsayılan olarak application/javascript, application/json, text/css, text/html, text/plain, text/xml sıkıştırılır. Görseller (JPEG, PNG) zaten sıkıştırılmış olduğu için tekrar sıkıştırılmamalıdır .

5. Ne Zaman Hangi Algoritma?

Senaryo	Öneri	Gerekçe
Statik JS/CSS/font (build-time)	Brotli kalite 11	Sıkıştırma maliyeti bir kez ödenir; en iyi oran
Dinamik HTML/API (per-request)	Brotli kalite 4-6 veya Zstd	Hız/oran dengesi; Zstd Brotli'den %42 hızlı
Eski tarayıcı desteği	Gzip (fallback)	Evrensel uyumluluk
Çok küçük yükler (<100 byte)	Sıkıştırma yapmayın	Sıkıştırma çıktıyı büyütebilir
Zaten sıkıştırılmış içerik (JPEG, MP4)	Sıkıştırma yapmayın	Fayda sağlamaz, CPU israfı

6. En İyi Pratikler

Pratik	Açıklama
Statikleri önceden sıkıştırın	Build aşamasında Brotli 11 ile `.br` dosyaları üretin; sunucu bunları doğrudan sunsun
Dinamikte hız/oran dengesi kurun	Brotli kalite 4-6 veya Zstd kullanın; kalite 11 dinamikte intihardır
Gzip'i fallback olarak tutun	`Accept-Encoding` pazarlığında son çare olarak her zaman Gzip ekleyin
Vary başlığını ekleyin	`Vary: Accept-Encoding` ile CDN'lerin doğru varyantı önbelleklemesini sağlayın
Küçük yükleri atlayın	Sıkıştırma eşiği belirleyin (ör. <1KB sıkıştırmayın)

Sonuç

Gzip ve Brotli, birbirinin rakibi değil, tamamlayıcısıdır. Gzip, evrensel uyumluluğu ve düşük CPU maliyetiyle her zaman yedekte durmalıdır. Brotli ise özellikle statik varlıklarda en yüksek sıkıştırma oranını sunar; build-time'da kalite 11 ile sıkıştırıldığında, Gzip'e göre %25-40 daha küçük dosyalar elde edilir . Dinamik yanıtlarda ise kalite seviyesini düşürmek veya Zstd gibi daha hızlı bir alternatifi değerlendirmek gerekir. Unutmayın: Sıkıştırma, "ne kadar küçük" değil, "ne kadar küçük ve ne kadar hızlı" sorusunun dengesidir.