Browser Cache Nasıl Çalışır? Cache-Control Rehberi

Başlangıç ölçümünü netleştirin

Aynı sayfa farklı cihazda farklı sonuç verir. Normal.

Tek sayı üzerinden acele karar vermek yerine dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması, masaüstünde görünmeyen gecikmeleri büyütebilir. Birçok ekip iyileştirme adımına hızla geçer; sorunun kaynak katmanını netleştirmeden yapılan değişiklikler ise kısa süreli rahatlama sağlar.

Önce gözlemi kayıt altına alın. Ölçüm tarihi, cihaz tipi, sayfa türü ve metrik sonucu birlikte tutulduğunda hangi adımın gerçekten fayda sağladığı açık biçimde görünür. Kalıcı ilerleme bu disiplinle gelir.

• Gerçek kullanıcı verisi: Chrome UX Report verisini 28 günlük periyotlarda takip edin. P75 değeri 2.5 saniyenin altında mı?
• Laboratuvar testi: Lighthouse skorunu mobil ve masaüstü için ayrı ölçün. Throttling ayarlarını gerçek kullanıcı profilinize göre yapılandırın.
• Cihaz kırılımı: Düşük, orta ve yüksek performanslı cihazlarda ayrı test senaryoları oluşturun.
• Zaman karşılaştırması: Her değişiklik öncesi baseline ölçümü kaydedin, 7 gün sonra tekrar ölçün.

Dağılıma bakmadan tek sayıyla karar vermek, rastgele sonuç üretir.

Darboğazı katman katman ayırın

Render blocking kaynak analizi ve critical CSS uygulama rehberi birlikte incelendiğinde öncelik sırası daha net çıkar.

Performans sorunu tek kaynaktan gelmez.

Ağır medya dosyaları yüklenme süresini artırır. Bloklayan JavaScript render'ı geciktirir, ana iş parçacığı yükü etkileşim metriklerini bozar, sunucu gecikmesi ise TTFB'yi yükseltir. Tüm bunlar önbellek stratejisini etkiler.

Sorun kaynağını netleştirmeden yapılan değişiklikler kısa süreli rahatlama sağlar.

• Ağır medya: 1MB üzeri görseller varsa WebP'ye çevirin. Video için adaptive streaming kullanın.
• Bloklayan kaynak: CSS'i critical/non-critical olarak ayırın. JavaScript'i defer veya async ile yükleyin.
• Ana iş parçacığı yükü: Chrome DevTools Performance sekmesinde Long Task'leri tespit edin. 50ms üzeri görevleri parçalayın.
• Sunucu gecikmesi: TTFB 600ms üzerindeyse CDN kullanın veya sunucu tarafı önbellek ekleyin.

Her katmanın ayrı çözümü var. Hepsini birden düzeltmeye çalışmayın.

Öncelik sırası kurun

Her iyileştirme adımının etkisi farklıdır. Gerçek kullanıcı verisinde açıkça görülür.

Bazı değişiklikler büyük etki yaratır ama uygulama maliyeti yüksektir. Bazıları düşük risklidir ama geri dönüş süresi uzundur. Önceliklendirme matrisini net kurmadan iyileştirmeye başlamak, kaynakları yanlış alana harcamak demektir.

• Etki büyüklüğü: Değişiklik LCP'yi 500ms düşürüyorsa yüksek etki. 50ms düşürüyorsa düşük etki. Önce yüksek etkili adımları uygulayın.
• Uygulama maliyeti: Cache-Control header eklemek 1 saatlik iş. Tüm görselleri WebP'ye çevirmek 2 haftalık iş. Maliyeti düşük olanı önce yapın.
• Risk seviyesi: Statik varlık önbelleği düşük risk. Dinamik içerik önbelleği yüksek risk. Düşük riskli adımları önce test edin.
• Geri dönüş süresi: Header değişikliği 5 dakikada geri alınır. CDN konfigürasyonu 1 saatte geri alınır. Hızlı geri alınabilen adımları önce deneyin.

Yüksek etki + düşük maliyet + düşük risk = ilk adım.

Değişiklikleri küçük yayınlarla doğrulayın

Küçük değişiklikler yapın. Her birini ölçün.

Büyük değişiklikler risklidir. Hangi adımın fayda sağladığını, hangisinin sorun ürettiğini ayırt edemezsiniz. Küçük adımlar ise her birinin etkisini net gösterir, iyileştirme kalitesini belirleyen de bu yaklaşımdır.

• Aşamalı yayın: Önce %5 trafiğe açın. 24 saat sonra %25'e çıkarın. Sorun yoksa %100'e çıkarın.
• Önce test sonra canlı: Staging ortamında 3 gün test edin. Gerçek kullanıcı verisi toplamadan canlıya almayın.
• Regresyon kontrolü: Her değişiklik sonrası tüm metrikleri kontrol edin. LCP düzelirken CLS bozulmuş olabilir.
• Geri alma planı: Her değişiklik için geri alma senaryosu hazırlayın. Sorun çıkarsa 5 dakikada geri alabilmeli.

Bir metrik düzelirken diğeri bozulabilir. Hepsini izleyin.

Veriyi yanlış okumayın

Lighthouse raporunu doğru okuma ve TTFB katmanlarını ayırma yaklaşımı, önbellek kararlarının yanlış metrikle alınmasını engeller.

Metrikleri doğru yorumlamak hız çalışmasını sürdürülebilir yapar.

Tek ölçüm yanılgısı en yaygın hatadır. Bir kez ölçüp karar vermek, rastgele sonuç üretir. Aşırı ortalama kullanımı ise gerçek kullanıcı deneyimini gizler. P75 ve P95 değerlerine bakın.

• Tek ölçüm yanılgısı: Lighthouse skorunu 5 kez çalıştırın. Ortalamasını alın. Tek ölçüm güvenilir değil.
• Aşırı ortalama kullanımı: Ortalama LCP 2.5 saniye olabilir ama P95 değeri 8 saniye olabilir. P75 ve P95'e bakın.
• Coğrafya farkı: Avrupa'dan hızlı olan site Asya'dan yavaş olabilir. Farklı bölgelerden test edin.
• Cihaz sınıfı etkisi: iPhone 14'te hızlı olan site Android Go cihazında yavaş olabilir. Düşük performanslı cihazlarda test edin.

Ortalama 2.5 saniye ama %25 kullanıcı 8 saniye bekliyor? Sorun var.

Sürdürülebilir kontrol rutini kurun

Performans iyileştirmesi tek seferlik iş değildir.

Bir kez düzeltip unutursanız, yeni özellikler performans çizgisini bozar. Süreklilik modeli kurmak, her yayında performans kontrolü yapmak demektir.

• Haftalık denetim: Her Pazartesi Chrome UX Report verisini kontrol edin. P75 değeri eşiğin üzerine çıkmış mı?
• Yayın öncesi kontrol: Her deployment öncesi Lighthouse skorunu çalıştırın. Skor 10 puan düşmüşse yayını durdurun.
• Otomatik alarm: LCP 2.5 saniyeyi geçerse Slack'e bildirim gönderin. TTFB 600ms'yi geçerse e-posta gönderin.
• Dokümantasyon disiplini: Her değişikliği performance-log.md dosyasına kaydedin. Tarih, değişiklik, metrik sonucu yazın.

Otomatik alarm yoksa sorun fark edilmeden büyür.

Vaka: Güncellik ve hız dengesini kurmak

Bir haber platformunda bazı dosyalar gereksiz sık indirilirken bazı içerikler geç güncelleniyordu. Sebep, tüm kaynaklara aynı cache-control değerlerinin verilmesiydi. Ekip dosya sınıflarını ayırdı; sürümlü statik varlıklarda uzun süreli politika, hızlı değişen içeriklerde daha kısa doğrulama modeli uygulandı.

Hem tekrar ziyaret performansı iyileşti hem güncellik sorunu azaldı. Önbellek yönetiminde tek tip yaklaşımın yerine içerik yaşam döngüsüne göre karar verilmesi gerektiğini gösterdi.