← Blog

CLOUDFLARE CACHE TUZAKLARI

Kendi sitemizden gerçek bir olay: immutable cache header, unutulan versiyon artışı ve CDN cache ile sunucu şablon cache'ini ayırt etmenin yolu.

Cloudflare Cache Tuzakları

Geçen hafta kendi sitemizde küçük bir görsel güncelleme yaptık, FTP'ye yükledik, sayfayı yeniledik — ve hâlâ eski hali görüyorduk. Sunucuda dosya doğruydu. Sorun tarayıcı cache'i de değildi. Sorun Cloudflare'ın kendisiydi, ve bu tuzağa daha önce de düşen çok kişi var.

immutable cache header'ının gizli maliyeti

PageSpeed skorunu 100 yapma sürecinde, statik dosyalara (CSS, JS) agresif bir cache header'ı ekledik:

Cache-Control: public, max-age=31536000, immutable

Bu, "bu dosya bir yıl boyunca hiç değişmeyecek, tekrar sorma" demek — ve tarayıcı performansı için harika. Ama ?v=4 gibi bir versiyon query'siyle birlikte kullanıldığında ("cache-busting" pattern'i), asıl mantık şu: dosya değiştiğinde versiyon numarasını da artırırsınız, app.css?v=5 tamamen yeni bir URL sayılır, eski cache'e dokunmaz.

Sorun şu: biz CSS'i güncelledik ama ?v= numarasını unutup artırmadık. Cloudflare, app.css?v=4 URL'inin bir yıl boyunca değişmeyeceğine söz verdiğimiz için, sunucudaki yeni dosyayı hiç sormadı — kendi edge cache'inden eskisini servis etmeye devam etti.

Neden "tarayıcı cache'ini temizle" işe yaramadı

Çünkü sorun tarayıcıda değil, Cloudflare'ın edge sunucularındaydı. Kullanıcının tarayıcısı Cloudflare'a soruyor, Cloudflare "bende var, işte" diyor — sunucumuza hiç uğramadan. cf-cache-status: HIT header'ı bunu ele veriyor; curl -sI ile bakınca hemen anlaşılıyor.

Çözüm — ve kural

Her app.css (veya versiyonlanan başka bir statik dosya) değiştiğinde, HTML'deki referansın versiyon numarasını da artırmak zorunlu:

<link rel="stylesheet" href="/assets/css/app.css?v=5">

Bu satırı içeren şablon dosyasını da deploy etmeyi unutmayın — sadece CSS'i yükleyip HTML'i unutursanız, tarayıcı hâlâ eski ?v=4 URL'ini isteyecektir.

Acil bir durumda (versiyon bump'ı unutulmuşsa) Cloudflare Dashboard → Caching → Configuration → Purge Cache ile belirli bir URL'i veya tüm cache'i elle temizleyebilirsiniz — ama bu bir kerelik kurtarma, kalıcı çözüm değil.

Bununla karıştırılan ayrı bir sorun: Twig şablon cache'i

Aynı oturumda ikinci bir katman daha vardı: sunucu tarafında Twig, derlenmiş şablonları var/twig-cache/ altında saklıyor. HTML şablonunu güncelleyip deploy ettiğinizde, auto_reload kapalıysa Twig eski derlenmiş halini kullanmaya devam eder. Bunun çözümü tamamen farklı — Cloudflare purge değil, sunucudaki var/twig-cache/ dizinini silmek.

İki katman birbirine benziyor ama farklı yerlerde yaşıyor: biri CDN'de (Cloudflare), diğeri sunucuda (Twig). Bir değişiklik canlıya yansımıyorsa, önce hangi katmanda sıkıştığını anlamak gerekiyor — curl -sI ile cf-cache-status header'ına bakmak bunun en hızlı yolu.

Çıkarım

Agresif cache header'ları performans için doğru — ama "doğru" ile "unutmaya dayanıklı" aynı şey değil. Versiyon numarasını artırmayı bir deploy checklist'ine yazılı kural haline getirmek, bu tuzağa bir daha düşmemenin tek garantili yolu.

Sitenizde benzer bir cache karmaşası mı yaşıyorsunuz? Bize yazın — genelde curl -sI ile 5 dakikada teşhis ediyoruz.

Bu konuda daha fazla bilgi almak ister misiniz?

Yazıda anlatılan çözümü kendi altyapınızda da hayata geçirmek ya da benzer bir ihtiyacı konuşmak isterseniz, ekibimizle iletişime geçin.

Bize ulaşın →