CDN ve Tarayıcı Önbelleğinde Cache Busting Stratejileri

CDN ve Tarayıcı Önbelleğinde Neyi Çözdüğümüzü Netleştirelim

Önbellekleme ayarlarını “bir kere düzgün yapalım, sonra uzun süre dokunmayalım” dediğimiz her projede, birkaç deploy sonra aynı duvara çarpıyoruz: Kullanıcıların tarayıcıları eski CSS ve JavaScript dosyalarını tutuyor, CDN edge düğümleri güncel dosyaları görmüyor ve canlıda tuhaf hatalar ortaya çıkıyor. Tam da burada cache busting stratejileri devreye giriyor.

Cache busting, basitçe söylemek gerekirse, statik varlıklarınızın (CSS, JS, görseller vb.) içeriği değiştiğinde URL’lerini de değiştirme sanatıdır. Böylece hem tarayıcı hem CDN uzun TTL ile agresif önbellekleme yapabilir, hem de yeni sürümleriniz milisaniyeler içinde devreye girer. Daha önce tarayıcı ve CDN önbelleklemenin neden bu kadar kritik olduğunu anlattığımız rehberde performans tarafını detaylandırmıştık; bu yazıda ise odak tamamen strateji: version query string, dosya yeniden adlandırma (filename hashing) ve bunların deploy sürecine entegrasyonu.

DCHost olarak, hem küçük WordPress sitelerinde hem de yüksek trafikli Laravel/SPA projelerinde aynı sorunu onlarca kez çözdük: “CSS dosyamı güncelledim ama bazı kullanıcılarda hâlâ eski tasarım görünüyor” şikâyeti. Bu yazıda, o şikâyeti kökten bitirecek, uzun vadede sizi yormayacak, CI/CD süreçlerinizle uyumlu cache busting modelini adım adım birlikte kurgulayalım.

Temel Mekanik: Tarayıcı Önbelleği, CDN ve Origin Arasındaki Dans

Cache busting’e girmeden önce, kısa ama kritik bir çerçeve çizelim. Üç ana oyuncumuz var:

• Tarayıcı önbelleği: Kullanıcının cihazında, URL bazlı dosya saklar. Aynı URL’ye tekrar istek geldiğinde, HTTP başlıklarına göre ya direkt yerelden sunar ya da sunucuya koşulsuz/koşullu istek atar.
• CDN edge önbelleği: Dünya geneline dağılmış düğümlerde, yine URL bazlı dosya saklar. Cache-key’inde çoğu zaman host + path + (bazı durumlarda) query string bulunur.
• Origin (DCHost üzerindeki hosting/VPS/dedicated sunucunuz): Uygulamanızın gerçek dosyalarının durduğu kaynak.

İdeal senaryo şudur: CSS/JS gibi statik varlıklara uzun TTL (Cache-Control: max-age=31536000, immutable gibi) verirsiniz, CDN ve tarayıcı bunları uzun süre saklar, origin üzerindeki yükünüz dramatik şekilde düşer. Ancak bu durumda tek bir şart var: İçerik değiştiğinde URL de değişmeli. Bunu yapmanın farklı yolları var; işte cache busting stratejileri tam olarak burada devreye giriyor.

Cache Busting Yaklaşımları: Seçenekleri Masaya Yatıralım

1) Version Query String: style.css?v=123 Mantığı

En çok görülen yöntemle başlayalım. URL şu hale getirilir:

• /assets/css/style.css?v=1.0.3
• /js/app.js?ver=20240102

Buradaki fikir çok basit: Dosya adı aynı kalır, ancak query string içindeki versiyon parametresi değiştikçe URL de değişmiş sayılır.

Artıları:

• Uygulama kodunda basitçe bir versiyon değişkeni tanımlamak çoğu framework ve CMS için çok kolaydır.
• Dosya sistemi tarafında yeni dosya üretmenize gerek kalmaz; hep aynı style.css üstüne yazabilirsiniz.
• Klasik projelerde, küçük WordPress/PHP sitelerinde hızlıca devreye alınabilir.

Eksileri:

• Bazı CDN’ler, varsayılan konfigürasyonda query string’i cache-key’e dahil etmez veya sadece belirli parametreleri dikkate alır. Bu durumda ?v=123 ile ?v=124 aynı cache entry’sini kullanabilir.
• Tarayıcı tarafında çoğunlukla işe yarar ama CDN önünde yanlış konfigüre edilmişse beklenmedik “eski dosya” sorunları çıkabilir.
• Dosyanın içeriği büyük ölçüde değişmese de, sürüm numarası değiştirdiğiniz her deploy’da tüm varlıklar yeniden inmek zorunda kalır; bu da ilk ziyaret süresini artırabilir.

Version query string kullanacaksanız, mutlaka CDN tarafında cache-key konfigürasyonunu kontrol etmelisiniz. Bununla ilgili detayları, CDN önbellekleme, Cache-Control ve edge kuralları rehberimizde pratik örneklerle anlattık.

2) Dosya Yeniden Adlandırma: style.123.css ve Filename Hashing

Daha modern ve uzun vadede çok daha sağlıklı yöntem: dosyanın adına versiyon (tercihen hash) gömmek.

• /assets/css/style.1.0.3.css
• /assets/css/style.3f2a9c1.css (içerik hash’i)
• /js/app.9b8e7f.min.js

Burada prensip şu: İçerik değişirse hash değişir, hash değişirse dosya adı değişir. Yani, dosyanın yeni sürümü URL bazında tamamen farklıdır. Bu, CDN ve tarayıcı önbelleği açısından en sağlam çözümdür.

Artıları:

• CDN’lerin büyük çoğunluğu query string’ten bağımsız olarak path’i cache-key’in ana parçası olarak kullanır. Dosya adı değiştiğinde, yeni entry garanti edilir.
• İçerik değişmeyen dosyalar için hash değişmediği sürece aynı URL korunur. Böylece sadece değişen varlıklar yeniden indirilir.
• Uzun TTL + immutable stratejisiyle mükemmel uyumludur. Yani 1 yıl önbellek verebilirsiniz ve sadece URL değiştiğinde yeni içerik devreye girer.

Eksileri:

• Basit projelerde, manuel olarak bu isimleri takip etmek zahmetli olabilir.
• Genellikle bir build aracı veya pipeline kullanmayı gerektirir (Webpack, Vite, Laravel Mix, Gulp, Rollup vb.).
• Back-end tarafında, orijinal isim → hash’li isim eşleştirmesini bilmek için çoğu zaman bir “asset manifest” okuma ihtiyacı doğar.

Bugün modern frontend dünyasında (React, Vue, Angular, SPA’ler) neredeyse tüm toolchain’ler, otomatik olarak filename hashing desteği sunuyor. Bu yüzden, yeni bir projeye başlıyorsanız ilk tercihiniz mutlaka dosya yeniden adlandırma / hashing olmalı.

3) Asset Manifest ve HTML Entegrasyonu

Dosya yeniden adlandırma kullandığınızda, canlı HTML çıktısında doğru dosya adını kullanmak kritik hale gelir. Bunu çözmek için genellikle bir manifest dosyası üretilir:

{
  "style.css": "style.3f2a9c1.css",
  "app.js": "app.9b8e7f.min.js"
}

Back-end tarafında bir yardımcı fonksiyon ile şunu yaparsınız:

• asset('css/style.css') çağrısı, HTML’de /assets/css/style.3f2a9c1.css çıktısını üretir.

Bu yaklaşım, özellikle Laravel, Symfony, Django gibi framework’lerde oturmuş bir pratiktir. Statik site generator (Jamstack) kullananlarda da aynı mantık geçerlidir. DCHost üzerinde statik site + CDN kombinasyonlarında, bu modelle neredeyse sıfır cache sorunu ile yıllarca çalışan projeler görmek mümkün.

CDN Açısından Cache Busting: Cache-Key, Query String ve Purge

Cache busting’in asıl sınavı CDN tarafında verilir. Tarayıcı çoğu zaman query string’e daha özenli davranırken, CDN konfigürasyonunda ufak bir hata sizi saatlerce uğraştırabilir.

Cache-Key ve Query String Politikaları

Birçok CDN, cache-key’in nasıl oluşturulacağını şu seçeneklerle yönetmenize izin verir:

• Tüm query string’leri yoksay (sadece path’e bak)
• Tüm query string’leri dahil et
• Belirli parametreleri (ör. v, ver, id) dahil et
• Belirli parametreleri hariç tut

Eğer version query string ile cache busting yapıyorsanız, cache-key’inize bu parametrelerin mutlaka dahil olduğundan emin olmalısınız. Aksi halde style.css?v=1 ve style.css?v=2 CDN açısından aynı içerik sayılabilir.

Dosya yeniden adlandırma (filename hashing) kullanıyorsanız, CDN tarafında query string’i çoğunlukla yoksayabilirsiniz. Bu da cache-key’inizi sadeleştirir, varyasyon sayısını azaltır ve cache hit oranını yükseltir.

Purge, Invalidate ve TTL İlişkisi

CDN’ler, genellikle şu yollarla önbelleği temizlemenize izin verir:

• URL bazlı purge: Belirli bir dosyanın cache’ini silersiniz.
• Prefix (path) bazlı purge: /assets/css/ altındaki her şeyi temizlersiniz.
• “Purge everything”: Tüm zone’un önbelleğini boşaltırsınız.

Doğru kurulmuş bir cache busting stratejisinde, aslında CDN purge işlemine pek az ihtiyaç duyarsınız. Çünkü:

• Yeni deploy’da yeni dosya isimleri/URL’leri üretilir.
• Eski URL’ler bir süre daha CDN ve tarayıcı önbelleklerinde kalmaya devam eder ama artık kimse o URL’leri HTML içinde referans etmiyordur.
• Dolayısıyla “zombi” cache entry’leri kimsenin canını yakmadan TTL’leri dolunca otomatik temizlenir.

Yine de kritik güvenlik güncellemelerinde (örneğin önemli bir JS güvenlik açığı), varolan URL’leri acil olarak geçersiz kılmak isteyebilirsiniz. Bu durumlar için CDN purging API’lerini deploy pipeline’ınıza entegre etmek mantıklı olabilir; buna birazdan CI/CD tarafında değineceğiz.

Tarayıcı Önbelleği İçin En Sağlıklı Model: Uzun TTL + Güvenilir Cache Busting

Yıllardır gördüğümüz en yaygın “yanlış çözüm” şu: Cache sorunları yaşanıyor, kimse nedenini tam anlamıyor, sonunda CSS/JS dosyalarının başına Cache-Control: no-store, no-cache yazılıyor. Evet, problemler biter; ama siteniz de ciddi şekilde yavaşlar.

Oysa tarayıcı için en sağlıklı strateji genellikle şöyle:

• Statik varlıklar (CSS, JS, font, logo, ikon, versiyonlanmış görseller) için: Cache-Control: max-age=31536000, immutable
• HTML sayfaları için: Daha kısa TTL, stale-while-revalidate gibi direktiflerle dengeli bir önbellekleme

Bu model, “uzun TTL ver ama URL değişirse bunu yeni dosya say” prensibiyle çalışır. Özetle: Cache busting stratejiniz güvenilir ise, TTL’i kısarak değil, TTL’i cesurca yükselterek performans kazanırsınız. Bu mantığın performans etkilerini, web sitenizin hızını doğru ölçme rehberimizle birlikte test ederek net bir şekilde görebilirsiniz.

Deploy Sürecine Entegrasyon: Manuel İşten Otomatik ve Güvenilir Sürece

Cache busting’in gerçekten sorunsuz çalışmasının tek yolu, deploy sürecine sıkı sıkıya entegre etmektir. Elle sürüm numarası güncellemek, FTP ile dosya atmak, random timestamp eklemek uzun vadede mutlaka hata çıkarır. DCHost tarafında gördüğümüz sağlam projelerin ortak noktası, cache busting’in CI/CD pipeline’ının doğal bir parçası olması.

WordPress/PHP Projelerinde Basit Version Query String Entegrasyonu

Klasik bir WordPress sitesinde, başlangıç seviyesi bir çözüm şu olabilir:

• functions.php içinde tema veya child tema için bir THEME_VERSION sabiti tanımlarsınız.
• wp_enqueue_style ve wp_enqueue_script çağrılarında bu versiyonu kullanırsınız.

Örneğin:

define('THEME_VERSION', '1.0.7');
wp_enqueue_style('theme-style', get_stylesheet_uri(), [], THEME_VERSION);

Burada halen manuel güncelleme ihtiyacı var. Bunu otomatiğe bağlamak için:

• Versiyon olarak tema klasörünün son değişiklik zamanını kullanabilirsiniz.
• Ya da Git commit hash’ini environment değişkeni üzerinden WordPress’e aktarabilirsiniz.

Daha ileri aşamada, WordPress sitenizi DCHost üzerindeki bir VPS’e alıp, GitHub Actions ile VPS’e otomatik deploy rehberimizde anlattığımız gibi sürümleme ve deploy’u tek akışta birleştirdiğinizde, cache busting versiyon numaranız da pipeline’dan otomatik beslenecektir.

Modern Frontend (Webpack/Vite) ile Filename Hashing

React, Vue, Angular veya modern bundler kullanan projelerde genellikle şu pattern kullanılır:

1. Build komutunu çalıştırırsınız: npm run build
2. Bundler, hash içeren dosya adları üretir: app.9b8e7f.js, style.3f2a9c1.css
3. Bir manifest.json dosyası oluşur; orijinal isimleri hash’li isimlerle eşler.
4. Back-end (Laravel, Django, Node.js) manifest’i okuyarak doğru URL’yi HTML’ye yazar.

Bu yapıyı DCHost üzerindeki bir Laravel + Vue projesinde oturttuğunuzda, her deploy’da:

• Yeni hash’li dosyalar üretilir.
• Eski dosyalar sunucudan silinmese bile HTML artık onları referans etmez.
• CDN ve tarayıcı, yeni URL’leri yepyeni dosyalar olarak görür.

Bu noktada CDN tarafında yapmanız gereken temel şey, statik varlıklarınızın TTL’ini yükseltmek ve cache-key’in path + file name üzerinden tanımlandığından emin olmak. WordPress tarafında benzer bir modeli nasıl kurabileceğinizi, WordPress için CDN önbellek kuralları yazımızda adım adım anlattık.

CI/CD Pipeline’ında Cache Busting Versiyonlaması

Gerçek rahatlık, versiyon bilgisini CI/CD pipeline’ının ürettiği tekil bir kimliğe bağladığınızda geliyor. Örnek stratejiler:

• Versiyon olarak Git commit hash (veya ilk 7 karakteri) kullanmak.
• Versiyon olarak Git tag ya da build numarası kullanmak.
• “release-2024.01.02-17.30” gibi tarih-saat tabanlı sürümler üretmek.

Bu değerleri:

• Build sırasında ortak bir version.json veya .env dosyasına yazabilirsiniz.
• Uygulamanız bu dosyayı okuyarak, tüm asset URL’lerinde aynı versiyon değerini kullanır.

VPS’e sıfır kesinti CI/CD kurulumu yazımızda anlattığımız sembolik sürüm klasörleri (releases/2024-01-02-1730 gibi) ile birlikte düşünürseniz, asset URL’lerinizi de aynı sürüm string’iyle eşleyebilir, hem kod hem statik dosyalar için tekil bir sürüm mantığı kurabilirsiniz.

Blue-Green ve Canary Dağıtımlarda Cache Busting Stratejisi

Blue-Green veya canary dağıtım yapan projelerde cache busting biraz daha kritik hale gelir. İki farklı sürümün aynı alan adını ve aynı CDN profilini kullandığı durumlarda:

• Blue ortamı v1 hash’lerine sahip dosya isimleriyle yayın yapar.
• Green ortamı v2 hash’lerine sahip dosya isimleri üretir.
• Traffic switch (yönlendirme) yapıldığında, tarayıcı ve CDN zaten yeni URL’leri farklı içerik olarak görecektir.

Yani sağlam bir filename hashing stratejiniz varsa, Blue-Green geçişlerinizde “eski CSS kaldı, yeni JS gelmedi” gibi karışık durumlara çok daha az maruz kalırsınız. Blue-Green mantığını daha geniş perspektifte ele aldığımız blue-green deployment rehberimiz, cache busting tarafındaki kararlarınızı da netleştirmenize yardımcı olacaktır.

DCHost Altyapısında Önerilen Mimari: CDN + Uzun TTL + Hash’li Asset’ler

DCHost tarafında hem paylaşımlı hosting hem de VPS/dedicated müşterilerimize genellikle şu mimariyi öneriyoruz:

• Web uygulaması (WordPress, Laravel, SPA) DCHost üzerinde hızlı diskli (tercihen NVMe) bir hosting veya VPS üzerinde çalışır.
• Statik varlıklarınız (CSS, JS, görseller, fontlar) için CDN entegrasyonu yapılır.
• Build süreciniz mutlaka filename hashing üreten bir toolchain içerir ya da en azından versiyonlu klasörleme (ör. /assets/v1/style.css) uygulanır.
• CDN tarafında uzun TTL + immutable politikasıyla agresif önbellekleme yapılır.
• Deploy pipeline’ı, gerekli durumlarda CDN purge API’lerini kullanacak şekilde kurgulanır (kritik güvenlik yaması vb.).

Böyle bir kurguda, origin üzerindeki yükünüz belirgin şekilde düşer, özellikle yoğun kampanya dönemlerinde CPU/IO baskısı azalır. Bu da doğrudan daha düşük TTFB ve daha iyi Core Web Vitals anlamına gelir. Detaylı bir performans bakışı isterseniz, Core Web Vitals’ı hosting tarafında iyileştirmek başlıklı yazımız da iyi bir tamamlayıcı olur.

Sık Yapılan Hatalar ve Mini Kontrol Listesi

Gerçek projelerde en sık gördüğümüz cache busting hatalarını kısa bir liste halinde toparlayalım.

Yaygın hatalar:

• Sadece CSS/JS için versiyon kullanıp, font ve ikon dosyalarını unutmaktan kaynaklanan kırık ikon sorunları.
• CDN’de “dont cache query string” ayarı açıkken version query string ile cache busting yapmaya çalışmak.
• Hem query string hem de filename hashing’i aynı anda, plansız şekilde kullanıp gereksiz varyasyon yaratmak.
• HTML sayfalarına da çok uzun TTL verip, HTML’deki asset URL’lerinin güncellenmesini geciktirmek.
• Deploy öncesi ve sonrası GTmetrix/PageSpeed raporlarıyla test etmeden konfigürasyon değiştirmek.

Kendinize sorabileceğiniz 7 soruluk kontrol listesi:

1. Statik varlıklarım için tekil bir versiyon stratejim var mı? (query string, hash, versiyonlu klasör vb.)
2. CDN cache-key’inde hangi parametrelerin dikkate alındığını biliyor muyum?
3. CSS/JS dışında, font, icon, SVG sprite gibi dosyalarım da aynı stratejiye dahil mi?
4. HTML sayfalarımın TTL’i, asset TTL’lerinden daha kısa ve kontrollü mü?
5. CI/CD pipeline’ım cache busting versiyonumu otomatik üretiyor mu, yoksa hâlâ elle mi değiştiriyorum?
6. Canlıya çıkmadan önce staging ortamında, tarayıcı önbelleğini temizlemeden gerçek kullanıcı davranışını taklit ederek test yapıyor muyum?
7. Değişiklik sonrası WebPageTest/GTmetrix ile önbellek hit oranını ve TTFB/TTI değerlerini kontrol ediyor muyum?

Sonuç: Cache Busting’i Bir Kez Doğru Kur, Yıllarca Rahat Et

Cache busting, ilk bakışta sadece “CSS dosyasına versiyon parametresi ekleme” işi gibi görünebilir; ama CDN, tarayıcı, CI/CD ve deploy mimarinizle birlikte düşündüğünüzde tüm performans stratejinizin taşıyıcı kolonlarından biri haline geliyor. Doğru kurgulandığında:

• Statik varlıklarınıza gönül rahatlığıyla 1 yıla kadar TTL verebilir, CDN ve tarayıcı önbelleklerinden maksimum fayda alırsınız.
• Yeni bir deploy yaptığınızda, kullanıcılara “ctrl+f5 yap” demek zorunda kalmazsınız.
• Origin (DCHost üzerindeki hosting/VPS/dedicated sunucunuz) üzerindeki yük azalır, aynı kaynakla daha çok trafiği güvenle taşırsınız.

Yeni bir projeye başlıyorsanız, en baştan filename hashing + manifest yaklaşımını kurgulamanızı, mevcut bir projede iseniz de en azından tutarlı bir version query string stratejisiyle başlamanızı öneririz. CDN tarafında da CDN ne zaman gerekir ve nasıl seçilir yazımızı gözden geçirerek doğru yapı taşlarını yerleştirebilirsiniz.

Eğer DCHost üzerinde çalışan sitenizde hala “güncel CSS’yi kimse görmüyor” sorunları yaşıyorsanız, altyapınız, CDN ayarlarınız ve deploy süreciniz birlikte ele alınmalı demektir. İsterseniz projenizin durumunu birlikte analiz edip, hem performans hem de operasyonel basitlik sağlayacak bir cache busting + CDN mimarisini adım adım beraber kurgulayalım.