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

Sıkıştırma için başlangıç ölçümünü netleştirin

Aynı sayfa farklı cihazlarda farklı yüklenir.

Mobil tarafta düşük işlem gücü var, ağ dalgalanması yüksek. Masaüstünde bu gecikmeler görünmez. Tek sayıya bakıp karar vermek riskli. Dağılıma bakın: p50, p75, p90 değerlerini karşılaştırın. Hangi kullanıcı segmentinde sorun var?

Ç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.

Raporda güzel görünen skor yeterli değil.

Kullanıcı sayfa ile akıcı etkileşime girmeli, içerik stabilite korumalı, bekleme hissi azalmalı. Bir metriği iyileştirirken başka alanda sorun üretmek kolay. Örnek: agresif sıkıştırma CPU yükünü artırabilir, TTFB'yi yükseltebilir. Değişiklik öncesi ve sonrası aynı koşullarda ölçün. Ekip içi tartışma azalır, karar kalitesi yükselir. Belirlediğiniz eşikleri sürüm notlarına işleyin; yeni geliştirmeler performans çizgisini bozduğunda erken yakalarsınız.

Sıkıştırma darboğazını katman katman ayırın

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.

Performans sorunu çok katmanlı.

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 tarafında öncelik sırası kurun

Her iyileştirme eşit değil.

Bazı değişiklikler büyük etki yaratır, az efor gerektirir. Bazıları çok efor ister, az kazanç sağlar. Matris kurun: etki büyüklüğü (yüksek/orta/düşük) ve uygulama maliyeti (düşük/orta/yüksek). Önce yüksek etki + düşük maliyet işleri yapın. Düşük etki + yüksek maliyet işleri erteleyin veya hiç yapmayın.

Ö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.

Sıkıştırma değişikliklerini küçük yayınlarla doğrulayın

Büyük değişiklikler riskli.

Aynı anda 10 optimizasyon yaparsanız hangisi işe yaradı bilemezsiniz. Sorun çıktığında hangisi sebep oldu bulamazsınız. 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.

Sıkıştırma verisini yanlış okumayın

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.

Tek ölçüm aldatıcı.

Lighthouse skorunuz 95 olabilir ama gerçek kullanıcılar yavaş deneyim yaşıyor olabilir. Lab ortamı kontrollü: hızlı internet, güçlü CPU, temiz cache. Gerçek dünya kaotik: yavaş 3G, eski telefon, dolu cache, background app'ler çalışıyor. İkisini karıştırmayın.

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 için sürdürülebilir kontrol rutini kurun

Tek seferlik optimizasyon yetmez.

Performans borcu sürekli birikir. Yeni özellik eklersiniz, bundle size büyür. Üçüncü taraf script eklersiniz, yükleme süresi uzar. Görseller optimize edilmeden yüklenir. Bir ay sonra performans eskiye döner. Süreklilik için rutin kurun.

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.

Vaka: Agresif sıkıştırma CPU'yu tüketti

Bir e-ticaret sitesi tüm text dosyalarını Brotli level 11 ile sıkıştırıyordu.

Dosya boyutu %25 düştü. Transfer time iyileşti. Ama pik saatlerde sunucu CPU %95'e çıktı. TTFB 200ms'den 800ms'ye yükseldi. Kullanıcılar yavaşlık şikayeti yaptı. Sorun: agresif sıkıştırma CPU'yu tüketiyordu.

Ekip içerik tipine göre seviye politikası belirledi. HTML ve JSON için Brotli level 6 (dengeli). CSS ve JavaScript için level 4 (hızlı). Çok büyük dosyalar için pre-compression (build time'da sıkıştır, runtime'da sadece serve et). Sonuç: CPU kullanımı %60'a düştü, TTFB 250ms'ye indi, transfer size hala %20 daha küçük.

Ders: en yüksek seviye her zaman en iyi değil. Aktarım kazancı ile işlem maliyeti arasında denge kurun.