HTTP Cache Başlıkları ve Sunucu Tarafı Önbellekleme Stratejileri
HTTP Cache Başlıkları ve Sunucu Tarafı Önbellekleme Stratejileri
Son Güncelleme: Mart 2026
HTTP önbellekleme web performansının ve sunucu maliyetlerinin düşürülmesinde kritik bir rol oynar. Bu makalede Cache-Control, ETag, Expires gibi HTTP cache başlıkları ve sunucu tarafı (reverse proxy, microcache) önbellekleme stratejileri anlatılacaktır.
İçindekiler
- Genel Bakış
- HTTP Cache Başlıkları
- Sunucu Tarafı Önbellekleme
- Önbellekleme Stratejileri ve Senaryolar
- Cache-Control Direktifleri Karşılaştırma
- Cache Invalidasyon ve Versiyonlama
- Sıkça Sorulan Sorular
- Sonuç
Genel Bakış
Önbellekleme, istemci ve ara katmanlardaki tekrar eden isteklerin yanıt süresini azaltır ve sunucu yükünü düşürür. Uygun biçimde yapılandırılmış HTTP başlıkları ile hem tarayıcı (client-side) hem de proxy/CDN (edge-side) önbelleklemesi kontrol edilebilir. Bu sayede sayfa yüklenme süreleri kısalır, bant genişliği harcaması azalır ve kullanıcı deneyimi iyileşir.
HTTP Cache Başlıkları
Cache-Control
Cache-Control başlığı, istemci ve ara önbellekler için en önemli yönlendiricidir. Aşağıdaki tablo yaygın direktifleri ve anlamlarını özetler.
| Direktif | Açıklama |
|---|---|
| public | Kaynağın her tür önbellek (CDN, proxy, tarayıcı) tarafından saklanabileceğini belirtir. |
| private | Kaynak yalnızca tarayıcı gibi tek kullanıcıya ait önbellekte saklanabilir; paylaşılan ara önbelleklere gönderilmez. |
| max-age=seconds | Kaynağın geçerli sayılacağı saniye cinsinden süre. |
| no-cache | Önbellek, sunucuya koşullu (conditional) istek yapmadan önce kaynağı doğrudan kullanmamalıdır; ETag/Last-Modified ile doğrulama yapılır. |
| no-store | Hiçbir şekilde diske/ara belleğe kaydedilmemeli (gizli veriler için). |
| must-revalidate | Süre dolduğunda mutlaka sunucuya gidilip doğrulanmalı. |
ETag ve Last-Modified
ETag (entity tag) ve Last-Modified conditional (koşullu) istekler için kullanılır. Sunucu, içerik değiştiğinde farklı bir ETag döndürmeli veya Last-Modified tarihini güncellemelidir. Böylece istemci sadece değişiklik varsa tam içerik indirecek, aksi halde 304 Not Modified ile kısa yanıt alacaktır.
Expires
Expires başlığı, kullanım dışı kaldıktan sonra max-age ile birlikte hâlâ bazı senaryolarda desteklenir; fakat modern uygulamalarda öncelik Cache-Controldadır.
Sunucu Tarafı Önbellekleme
Sunucu tarafı önbellekleme, kaynakları istemciye varmadan önce sunucu tarafında (reverse proxy, application cache) saklayarak yanıt sürelerini kısaltır. Yaygın çözümler Varnish, Nginx microcache, Redis tabanlı cache ve CDN entegrasyonudur.
Reverse Proxy (Varnish / Nginx)
- Avantaj: Dinamik içerikler için çok yüksek performans; yük azaltma.
- Dezavantaj: Cache invalidasyon karmaşık olabilir; oturum (session) yönetimi dikkat gerektirir.
Uygulama Katmanı Önbellekleme (Redis, Memcached)
Redis veya Memcached, veritabanı sorguları, hesaplanmış HTML parçaları ve API yanıtları için hızlı anahtar-değer önbellekleme sağlar. Genellikle TTL (time-to-live) konularak canlı veri ile tutarlılık sağlanır.
Önbellekleme Stratejileri ve Senaryolar
Aşağıda pratik senaryolar ve her biri için önerilen stratejiler bulunmaktadır.
- Statik Varlıklar (CSS, JS, Görseller):
- Strateji: Uzun max-age (ör. 1 yıl) + isim tabanlı versiyonlama (filename hashing).
- Neden: Dosya isimleri değiştiğinde CDN/tarayıcı yeni dosyayı hemen alır; eskisi önbellekten kullanılırken içerik bozulmaz.
- HTML Sayfalar (Kısmen Dinamik):
- Strateji: Microcaching (ör. Nginx ile 1–10s) veya varyant cache (Vary header kullanımı) + conditional validation.
- Neden: Yoğun trafik dönemlerinde bile sayfa yanıtı hızlı kalır; çok sık değişmeyen bölümler kısa süreli önbellekte tutularak kaynak tasarrufu sağlar.
- API Yanıtları:
- Strateji: Endpoint bazlı TTL belirleme, kullanıcı bazlı (auth) yanıtlar için private cache kullanımı veya cache key'e kullanıcı id eklenmesi.
- Neden: Her kullanıcıya özel veriyi paylaşmak güvenlik riski taşır; dolayısıyla paylaşılan cache yalnızca genel veriler için uygundur.
- Gerçek Zamanlı Veriler:
- Strateji: Cache kullanmaktan kaçının; gerekiyorsa çok kısa TTL ve push tabanlı invalidasyon (webhook) kullanın.
Cache-Control Direktifleri Karşılaştırma
| Direktif | Kullanım Alanı | Örnek |
|---|---|---|
| public, max-age=31536000 | Statik varlıklar (resimler, build edilmiş js/css). | Cache-Control: public, max-age=31536000 |
| private, max-age=0, no-cache | Kullanıcıya özel sayfalar (profil, sepet). | Cache-Control: private, max-age=0, no-cache |
| no-store | Gizli/veri güvenliği gereken çıktılar (bankacılık). | Cache-Control: no-store |
Cache Invalidasyon ve Versiyonlama
Invalidasyon (geçersiz kılma) ve versiyonlama önbelleklemede en kritik konulardır. Aşağıda pratik yöntemler bulunmaktadır:
- Dosya adında hash kullanma: Build sürecinde (webpack, gulp) dosya adlarına içerik hash'i ekleyin; böylece içerik değiştiğinde URL değişir ve eski önbellek atılır.
- CDN purge: Kritik değişikliklerde CDN üzerinde purge (silme) API'si çağrısı ile yaygın önbellekler temizlenir.
- Cache key stratejisi: Cache anahtarlarında query string, host, vary header gibi değişkenleri doğru dahil edin. Oturum bazlı veri için anahtara kullanıcı id eklemeyin (güvenlik ve verimsizlik olur).
- Webhook tabanlı invalidasyon: İçerik yönetim sisteminden (CMS) veya deploy sürecinden tetiklenen webhook ile ters proxy’ye invalidasyon bildirimi gönderin.
Pratik Kullanım Senaryoları
1. Statik Varlıklar için Nginx Konfigürasyonu
Statik dosyalar için uzun süreli önbellekleme ve filename hashing önerilir. Deploy sürecinde eski dosyalar yeni isimle yayımlandığında eski önbellekler doğal olarak geçersizleşir.
2. Dinamik Sayfalar için Microcache
Haber, listeleme gibi sık talep gören ancak kısa süreli güncellenen sayfalar için microcache (örn. Nginx tarafında 5–10 saniye) ile hem hız hem de sunucu verimliliği sağlanır.
3. API için Versiyonlanmış Cache Key
API yanıtlarına Vary ve sürüm bilgisi ekleyin: örn. Cache-Control: public, max-age=60 ve cache anahtarında api version (v1, v2) kullanın. Böylece geriye dönük uyumluluk sağlanır.
Corelux Hizmetlerine Yönlendirme
Önbellekleme ve sunucu yapılandırmaları için uygun altyapı gereklidir. Corelux'un aşağıdaki hizmetleri bu ihtiyaçları karşılamak için uygundur:
- Sunucu Kiralama: Kiralık Sunucu ve bölgesel seçenekler (ör. Türkiye Kiralık Sunucu).
- Sanal Sunucu: Sanal Sunucu ile hızlı ölçeklenebilir VPS/VDS çözümleri (örn. Türkiye VPS Sunucu).
- Hosting: Küçük ve orta ölçekli projeler için Hosting ve Linux Hosting seçenekleri.
- Hizmetler: SSL yönetimi ve yedekleme gibi ek hizmetler için SSL Sertifikası ve Yedekleme Hizmeti.
Sıkça Sorulan Sorular
1. Cache-Control ile ETag aynı anda kullanılabilir mi?
Evet. Cache-Control yönlendirmeleri kısa/uzun süreli saklama politikasını belirlerken, ETag içerik değişimini doğrulamak için kullanılır. Birlikte daha esnek ve verimli cache davranışı elde edilir.
2. CDN kullanıyorsam sunucu tarafı cache gerekli mi?
Evet. CDN edge önbellekleri ile sunucu tarafı cache (reverse proxy) birlikte kullanıldığında hem küresel dağıtım hem de origin sunucu yükünde azalma sağlanır. Ayrıca CDN cache miss durumlarında origin üzerindeki yükü azaltmak için reverse proxy faydalıdır.
3. Hangi içerikler için no-store kullanmalıyım?
Hassas kişisel veriler, ödeme bilgileri ve kısa ömürlü token içeren yanıtlar için no-store kullanılması güvenlik açısından doğrudur. Bu başlık verinin hiçbir önbellekte saklanmasını engeller.
4. Cache invalidasyonunu nasıl otomatikleştiririm?
Deploy pipeline'ınıza CDN/Reverse Proxy purge çağrıları ve içerik yönetim sistemi (CMS) webhook'ları ekleyerek otomatik invalidasyon kurabilirsiniz. Ayrıca dosya isimlendirmede hash kullanmak çoğu durumda manuel invalidasyona gerek bırakmaz.
5. API yanıtlarını cache'lerken güvenlik nelere dikkat etmeliyim?
Öncelikle private cache politikalarını kullanın; kullanıcıya özel verileri genel cache'te saklamayın. Authentication header'larını cache anahtarlarına dahil etmeyin ve token bazlı erişimlerde kısa TTL tercih edin.
6. Microcache ile SEO'ya zarar gelir mi?
Genellikle hayır. Microcache, kısa süreli (ör. 5–10 sn) saklama sağlar ve arama motorları için içerik genellikle düzgün sunulur. Ancak çok sık güncellenen içeriklerde crawler davranışını gözlemleyin ve gerektiğinde crawlerlara özel önbellek kuralları uygulayın.
Sonuç
Doğru yapılandırılmış HTTP cache başlıkları ve sunucu tarafı önbellekleme stratejileri ile performans, maliyet ve kullanıcı deneyiminde belirgin iyileşme sağlanır. Uygulama tipinize göre statik varlıklar için uzun TTL + versiyonlama, dinamik sayfalar için microcache ve API'ler için endpoint bazlı TTL politikaları önerilir. Cache invalidasyon, versiyonlama ve güvenlik konuları planlanmadan uygulanan önbellekleme sistemleri beklenmedik hatalara sebep olabilir; bu nedenle test edilen deploy süreçleri ve otomatik invalidasyon mekanizmaları oluşturulmalıdır.
Corelux altyapı ve yönetilen hizmetleri ile önbellekleme stratejinizi güvenli ve ölçeklenebilir bir şekilde hayata geçirebilirsiniz. Detaylı teklif ve altyapı danışmanlığı için Hizmetler sayfamızı ziyaret edebilir veya ihtiyaçlarınıza uygun Sanal Sunucu ve Kiralık Sunucu çözümlerimizi inceleyebilirsiniz.
Yazar
Boran BAR
