Gzip ve Brotli Sıkıştırma: Dosya Boyutunu Küçültme Rehberi

Gzip ve Brotli nedir? HTTP sıkıştırma nasıl çalışır?

HTTP sıkıştırma, sunucunun dosyaları tarayıcıya göndermeden önce boyutunu küçülteceği anlamına gelir. Tarayıcı sunucuya istek gönderirken hangi sıkıştırma formatlarını desteklediğini Accept-Encoding başlığıyla bildirir. Sunucu desteklediği bir format seçer, dosyayı sıkıştırır ve Content-Encoding başlığıyla hangi formatın kullanıldığını tarayıcıya iletir. Tarayıcı dosyayı alır, açar ve işler. Tüm bu süreç kullanıcıya görünmez; yalnızca daha hızlı yükleme olarak hissedilir.

Gzip, 1992'den beri kullanılan ve tüm modern tarayıcıların desteklediği bir sıkıştırma standardıdır. HTML, CSS ve JavaScript gibi metin tabanlı dosyalarda %60-80 boyut azaltımı sağlayabilir. Sıkıştırma seviyesi 1 (hızlı, az sıkıştırma) ile 9 (yavaş, fazla sıkıştırma) arasında ayarlanır; çoğu sunucuda varsayılan değer 6 olarak gelir ve iyi bir denge noktasıdır.

Brotli, Google'ın 2015'te geliştirdiği daha yeni bir formattır. Gzip'e kıyasla aynı dosyada %15-25 daha iyi sıkıştırma oranı sunar. Sıkıştırma seviyesi 0 ile 11 arasında değişir; yüksek seviyeler (10-11) çok daha iyi sıkıştırma yapar ama CPU maliyeti katlanarak artar. Tüm modern tarayıcılar Brotli'yi destekler; yalnızca IE11 ve çok eski tarayıcılar Brotli bilmez — bu durumlarda sunucu otomatik olarak Gzip'e düşer.

Sunucuda sıkıştırma nasıl etkinleştirilir?

Nginx kullanan bir sunucuda Gzip'i etkinleştirmek birkaç satır konfigürasyonla yapılır: gzip on; direktifi temel etkinleştirme sağlar, gzip_types ile hangi içerik türlerinin sıkıştırılacağı belirlenir, gzip_comp_level ile seviye ayarlanır. Brotli için Nginx'te ngx_brotli modülü gereklidir; Apache'de mod_brotli kullanılır.

CDN kullananlar için durum daha basittir: Cloudflare, Fastly ve AWS CloudFront Brotli ve Gzip'i kontrol panelinden tek tıkla etkinleştirmeyi destekler. CDN sıkıştırmayı edge noktasında yapar; origin sunucu bu yükü taşımaz, hem performans hem maliyet avantajı elde edilir.

Sıkıştırmanın gerçekten çalışıp çalışmadığını doğrulamak için Chrome DevTools Network sekmesini kullanın. İncelemek istediğiniz kaynağa tıklayın; Response Headers bölümünde content-encoding: br (Brotli) veya content-encoding: gzip (Gzip) görünüyorsa sıkıştırma aktiftir. WebPageTest ve GTmetrix raporlarında "Compression" bölümü hangi kaynakların sıkıştırılmadan gönderildiğini açıkça listeler.

• Nginx için temel Gzip konfigürasyonu: gzip on, gzip_vary on, gzip_min_length 1024 (1KB altı dosyaları sıkıştırma), gzip_comp_level 6.
• Build time Brotli: Sık değişmeyen statik dosyalar için sunucu anında sıkıştırma yerine derleme sürecinde önceden sıkıştırılmış .br dosyaları üretin; sunucu CPU'su korunur.
• CDN ile sıkıştırma: Cloudflare ve benzeri CDN hizmetleri sıkıştırmayı edge noktasında yapar; konfigürasyon genellikle ayar panelinden etkinleştirilir.
• Doğrulama: Her deployment sonrası kritik kaynakların sıkıştırma başlığını kontrol edin; konfigürasyon değişikliğinin bazen geri döndüğü görülür.

Etkin sıkıştırma kararı için mevcut aktarım boyutunu ve CPU maliyetini birlikte ölçün

Mobil tarafta düşük işlem gücü ve yüksek ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür. Tek sayıya bakıp karar vermek riskli; dağılıma bakın: p50, p75, p90 değerlerini karşılaştırın.

Çoğu ekip hemen iyileştirmeye geçer. Sorunun kaynağını netleştirmeden yapılan değişiklikler geçici rahatlama sağlar, kalıcı çözüm üretmez. Sıkıştırma stratejinizde ilerleme istiyorsanız önce gözlemi kaydedin: tarih, cihaz tipi, sayfa türü, metrik sonucu. Hangi adım gerçekten fayda sağladı? Veri olmadan bilemezsiniz.

• Gerçek kullanıcı verisi: CrUX raporlarından p75 değerlerini takip edin. Coğrafya ve bağlantı tipine göre kırılım yapın.
• Laboratuvar testi: Lighthouse ve WebPageTest ile kontrollü ortamda test edin. 3G throttling kullanın.
• Cihaz kırılımı: Düşük-orta-yüksek segment cihazlarda ayrı ayrı ölçün. Sorun genelde düşük segmentte belirginleşir.
• Zaman karşılaştırması: Haftalık trend grafiği tutun. Ani düşüşler deployment ile ilişkilendirin.

Kullanıcı sayfa ile akıcı etkileşime girmeli, içerik stabilite korumalı, bekleme hissi azalmalı. Agresif sıkıştırma CPU yükünü artırabilir ve TTFB'yi yükseltebilir. Değişiklik öncesi ve sonrası aynı koşullarda ölçün; belirlediğiniz eşikleri sürüm notlarına işleyin.

Aktarım süresindeki asıl kaynağı bulmak için katmanlı analiz gerekir

Sıkıştırma etkisini ayrıştırırken render blocking kaynakları ve JavaScript yürütme maliyetini aynı testte incelemek yanlış teşhisi azaltır.

Sıkıştırma optimizasyonu yapmadan önce asıl darboğazı bulun. Belki sorun sıkıştırmada değil, 5MB'lık görsellerde. Belki Render-blocking CSS'te. Belki ana iş parçacığını bloke eden JavaScript'te. Ya da sunucu 800ms TTFB döndürüyor. Yanlış yere odaklanırsanız zaman kaybedersiniz.

Chrome DevTools Network sekmesini açın. Transfer size ve resource size sütunlarını karşılaştırın. Fark büyükse sıkıştırma çalışıyor demektir. Fark yoksa sunucu sıkıştırma göndermiyordur. Coverage sekmesine bakın: kullanılmayan CSS/JS var mı? Lighthouse'u çalıştırın, "Opportunities" bölümüne odaklanın.

• Ağır medya: Görseller WebP/AVIF formatında mı? Boyutlar responsive mi? Lazy loading aktif mi?
• Bloklayan kaynak: CSS ve JS dosyaları defer/async kullanıyor mu? Critical CSS inline mı?
• Ana iş parçacığı yükü: Long Task'lar var mı? JavaScript execution time yüksek mi?
• Sunucu gecikmesi: TTFB 200ms'nin altında mı? CDN kullanılıyor mu? Database sorguları optimize mi?

Sıkıştırma önemli ama tek başına yeterli değil. Kullanıcı deneyimi çok faktörlü: hız, stabilite, etkileşim. Bir alanı iyileştirirken diğerini bozmayın. Örnek: agresif minification bazen source map'leri bozar, debug zorlaşır. Ya da inline CSS çok büyürse HTML parse süresi uzar.

Değişiklik öncesi snapshot alın. Sonra tek değişken yapın, tekrar ölçün. Fark net görünür. Ekip içinde bu disiplini koruyun: her PR'da performans etkisi değerlendirilmeli. Eşikler belirlenmeli: "Transfer size 10KB'dan fazla artarsa alarm". Otomatik kontrol CI/CD'ye entegre edilmeli.

Sıkıştırma seviyesi seçiminde etki-maliyet dengesi belirleyicidir

Bazı değişiklikler büyük etki yaratır az efor gerektirir; bazıları çok efor ister az kazanç sağlar. Etki büyüklüğü ve uygulama maliyetini matrisleyin; yüksek etki + düşük maliyet adımları önce uygulanır, düşük etki + yüksek maliyet adımları ertelenir.

Örnek: Gzip'ten Brotli'ye geçmek yüksek etki + orta maliyet. Sunucu konfigürasyonu değişir, test edilir, canlıya alınır. Kazanç: %15-20 daha küçük dosya boyutu. Buna karşılık tüm inline script'leri harici dosyaya taşımak orta etki + yüksek maliyet olabilir. Refactoring gerekir, cache stratejisi değişir, test süresi uzar.

• Etki büyüklüğü: Transfer size'da kaç KB kazanç? LCP'de kaç ms iyileşme? %10+ kazanç yüksek etki.
• Uygulama maliyeti: Kaç saat geliştirme? Kaç sistem etkilenir? Geri dönüş planı var mı?
• Risk seviyesi: Değişiklik kritik path'te mi? Kullanıcı deneyimini bozma riski var mı?
• Geri dönüş süresi: Sorun çıkarsa ne kadar sürede eski haline dönersiniz? 5 dakika mı, 2 saat mi?

Teknik ekipte bu matris görünür olmalı. Backlog'da her item etiketlenmeli: "yüksek-etki-düşük-maliyet", "düşük-etki-yüksek-maliyet". Sprint planlamada öncelik net. Tartışma azalır, hız artar.

Bazı değişiklikler hemen yapılır: Gzip aktif değilse aktif edin (5 dakika, büyük kazanç). Bazıları araştırma gerektirir: Hangi dosyalar sıkıştırılmalı? Text-based dosyalar evet, zaten sıkıştırılmış görseller hayır. Eşik belirleyin: 1KB'dan küçük dosyalar sıkıştırılmasın (overhead fazla). Belirlediğiniz kuralları dokümante edin, ekip içinde paylaşın.

Her sıkıştırma konfigürasyon değişikliğini izole test edin

Aynı anda 10 optimizasyon yaparsanız hangisi işe yaradı bilemezsiniz. Küçük adımlarla ilerleyin: bir değişiklik, bir ölçüm, bir değerlendirme. Sonra bir sonraki adım.

Aşamalı yayın yapın. Önce %5 trafiğe açın, 24 saat izleyin. Sorun yoksa %25'e çıkarın. Sonra %50, sonra %100. Her aşamada metrikleri kontrol edin: error rate arttı mı? TTFB yükseldi mi? Conversion rate düştü mü? Anomali görürseniz hemen geri alın.

• Aşamalı yayın: Feature flag kullanın. Canary deployment yapın. A/B test edin.
• Önce test sonra canlı: Staging ortamında tam test edin. Load test yapın. Edge case'leri kontrol edin.
• Regresyon kontrolü: Automated test suite çalıştırın. Visual regression test yapın. Kritik user flow'ları manuel test edin.
• Geri alma planı: Rollback prosedürü hazır olsun. Önceki versiyon erişilebilir olsun. Geri alma süresi 5 dakikayı geçmesin.

Örnek senaryo: Brotli compression level 11'den 6'ya düşürüyorsunuz. CPU kullanımı azalacak, dosya boyutu biraz artacak. Önce staging'de test edin: dosya boyutu ne kadar arttı? %3 mü, %10 mu? Kabul edilebilir mi? Sonra %5 trafiğe açın. CPU kullanımı gerçekten düştü mü? TTFB iyileşti mi? Transfer time arttı mı? Tüm metrikleri kaydedin.

Her değişikliği dokümante edin: ne değişti, neden değişti, sonuç ne oldu. Ekip içinde paylaşın. Bir sonraki kişi aynı hatayı yapmasın, aynı testi tekrar etmesin. Zaman kazanırsınız, bilgi birikir.

Lab ortamı olumlu görünse de gerçek trafik farklı davranabilir

Karar verirken TTFB bileşen analizi ile CDN dağıtım etkisini birlikte okumak sıkıştırma sonuçlarını daha gerçekçi yorumlamayı sağlar.

Lab ortamı kontrollü: hızlı internet, güçlü CPU, temiz cache. Gerçek dünya kaotik: yavaş 3G, eski telefon, dolu cache, arka planda çalışan uygulamalar. Lighthouse skoru 95 olabilir; gerçek kullanıcılar yine de yavaş deneyim yaşıyor olabilir.

Ortalama değer yanıltır. Ortalama LCP 2.5s olabilir ama %25 kullanıcı 5s+ bekliyor olabilir. p75 ve p90 değerlerine bakın. En kötü deneyimi yaşayan kullanıcılar kim? Onları iyileştirin. Coğrafya önemli: Avrupa'da hızlı, Asya'da yavaş olabilir. CDN edge location'ları yeterli mi? Cihaz sınıfı kritik: iPhone 14'te hızlı, Android Go'da yavaş. Düşük segment cihazları optimize edin.

• Tek ölçüm yanılgısı: Lab + RUM verilerini birlikte değerlendirin. Sadece birine güvenmeyin.
• Aşırı ortalama kullanımı: Median, p75, p90 değerlerini takip edin. Dağılıma bakın, outlier'ları inceleyin.
• Coğrafya farkı: Bölge bazlı metrik kırılımı yapın. CDN coverage'ı kontrol edin. Latency haritası çıkarın.
• Cihaz sınıfı etkisi: Düşük-orta-yüksek segment ayrı raporlayın. Düşük segment için özel optimizasyon yapın.

Metrik oyunu oynamayın. Lighthouse skorunu yükseltmek için kritik kaynakları gizlemek, lazy loading'i kötüye kullanmak kısa vadeli kazanç sağlar. Uzun vadede kullanıcı deneyimi bozulur. Gerçek hedef: kullanıcı hızlı, akıcı, stabil deneyim yaşasın. Metrikler araç, amaç değil.

Değişiklik öncesi ve sonrası aynı koşullarda ölçün: aynı cihaz, aynı ağ, aynı sayfa, aynı zaman dilimi. Farklı koşullarda ölçerseniz karşılaştırma anlamsız. A/B test yapın: %50 eski versiyon, %50 yeni versiyon. Aynı anda ölçün, karşılaştırın. İstatistiksel anlamlılık kontrol edin: fark gerçek mi, tesadüf mü?

Sıkıştırma konfigürasyonu değişmese bile boyut düzenli izlenmeli

Performans borcu sessizce birikir. Yeni özellik eklenince bundle boyutu büyür, üçüncü taraf scriptler yükleme süresini uzatır, görseller optimize edilmeden yüklenir. Bir ay sonra aktarım boyutu eskiye döner.

Haftalık performans denetimi yapın. Her Pazartesi sabahı 30 dakika: Lighthouse skorları kontrol edin, CrUX raporlarına bakın, anomali var mı? Transfer size arttı mı? LCP yükseldi mı? Erken fark ederseniz hızlı düzeltirsiniz. Geç fark ederseniz sorun büyümüş, düzeltmesi zor olmuştur.

• Haftalık denetim: Pazartesi sabahı 30 dakika. Lighthouse + CrUX + RUM verileri. Trend grafiği güncelleyin.
• Yayın öncesi kontrol: Her PR'da bundle size kontrolü. Lighthouse CI entegrasyonu. Eşik aşılırsa merge bloklansın.
• Otomatik alarm: Transfer size %10+ artarsa Slack bildirimi. LCP 2.5s'yi geçerse email. p75 değerleri kötüleşirse ticket açılsın.
• Dokümantasyon disiplini: Her optimizasyonu kaydedin: ne yaptınız, neden yaptınız, sonuç ne oldu. Wiki'de paylaşın.

CI/CD pipeline'a performans kontrolü ekleyin. Lighthouse CI, Bundle Analyzer, Size Limit gibi araçlar var. PR açıldığında otomatik çalışsın, rapor üretsin. Eşikler belirleyin: "JavaScript bundle 200KB'ı geçemez", "Transfer size 10KB'dan fazla artamaz". Eşik aşılırsa merge engellensin. Geliştirici hemen fark eder, hemen düzeltir.

Performans kültürü oluşturun. Ekip içinde performans şampiyonu belirleyin. Sprint retrospective'de performans konuşulsun. Başarılar kutlansın: "Bu sprint LCP'yi 500ms düşürdük!" Performans herkesin sorumluluğu olmalı, sadece bir kişinin değil.