Cache-Control — nedir, yönergeler ve önbellek yönetimi

Cache-Control Nedir?

Cache-Control, HTTP/1.1'de (RFC 7234) standartlaştırılmış bir HTTP başlığıdır ve sunucunun, istemcilerin, proxy'lerin ve CDN'lerin yanıtı nasıl ve ne kadar süreyle önbelleğe alabileceğini belirtmesine olanak tanır. Expires'ten (HTTP/1.0) farklı olarak, Cache-Control yönergeleri kullanır — virgülle birleştirilmiş metin komutları: Cache-Control: public, max-age=3600, must-revalidate. Başlık, önbellek zincirindeki her halka üzerinde ince ayarlı kontrol sağlar.

Önbellek, web ve mobil uygulama performansının temel mekanizmalarından biridir. Olmadan, her kullanıcı isteği doğrudan sunucuya gider ve aşırı yük ve gecikmeye neden olur. Cache-Control üç önbellek düzeyi tanımlar: tarayıcı/uygulama (özel önbellek), proxy sunucular (paylaşılan önbellek) ve CDN (dağıtık önbellek). Her düzey yönergeleri farklı yorumlar.

Yanlış Cache-Control yapılandırması, performans sorunlarının en yaygın nedenlerinden biridir. Çok agresif önbellek, kullanıcıların eski verileri görmesine neden olur. Çok zayıf önbellek, sunucuya aşırı istek ve yavaş yüklemeye yol açar. Akamai (2025)'e göre, statik içerik için Cache-Control'u optimize etmek, sunucu yükünü %70-90 azaltır ve mobil kullanıcılar için yükleme süresini %40-60 iyileştirir.

Başlığın Tarihçesi

Cache-Control, HTTP/1.1'de (RFC 2616, 1999) Expires'in yerine geçmek üzere ortaya çıktı. Expires'in temel bir sorunu vardı: sunucu ve istemci saat dilimlerine bağlı olan mutlak bir tarih kullanıyordu. Cache-Control, göreceli zamana (yanıtın alındığı andan itibaren saniye cinsinden max-age) geçerek bu sorunu çözdü. Daha sonra, RFC 7234'te (2014) yeni yönergeler eklendi: statik varlıklar için immutable, gecikmeli doğrulama için stale-while-revalidate ve stale-if-error.

Cache-Control Yönergeleri

Cache-Control, üç gruba ayrılmış 10'dan fazla yönerge içerir: istek yönergeleri (istemci → sunucu), yanıt yönergeleri (sunucu → istemci) ve uzantılar. Pratikte, mobil geliştirme, önbellek senaryolarının %95'ini kapsayan 6-7 ana yanıt yönergesi kullanır. Her birini örnekler ve önerilerle inceleyelim.

max-age en önemli yönergedir. İstemcinin belirtilen süre boyunca sunucuya istek göndermesini yasaklar. Statik varlıklar (CSS, JS, görseller) için max-age genellikle 1 gün ila 1 yıl arasında ayarlanır. API yanıtları için — 0 saniye (her zaman güncel veri) ila 5-10 dakika (referans verileri) arasındadır. s-maxage, CDN ve tarayıcı için farklı ömürler ayarlamaya olanak tanır: CDN 1 gün boyunca bir kopya saklar, tarayıcı 1 saat boyunca saklar.

no-cache vs no-store

Bu iki yönerge sıklıkla karıştırılır. no-cache önbelleği yasaklamaz — koşullu bir istek (If-Modified-Since veya If-None-Match) aracılığıyla her kullanımda önbelleğe alınmış kopyayı doğrulamayı gerektirir. Sunucu 304 ile yanıt verirse — istemci önbelleği kullanır. 200 ise — günceller. no-store ise, disk ve bellek dahil olmak üzere herhangi bir önbellekte yanıtı kaydetmeyi tamamen yasaklar. no-store'u yalnızca hassas veriler için kullanın — token'lar, ödeme verileri, kişisel belgeler.

Cache-Control ve Expires

Expires başlığı (HTTP/1.0) da kaynağın ömrünü belirtir ancak mutlak bir tarih kullanır: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age, yanıt anından itibaren göreceli süreyi kullanır. Fark, dağıtık sistemler için kritiktir: sunucu ve istemci farklı saat dilimlerindeyse Expires yanlış yorumlanabilir. Cache-Control'de bu sorun yoktur — 3600 saniye her zaman 3600 saniyedir.

Her iki başlık da mevcut olduğunda, Cache-Control Expires'a göre önceliklidir. Bu, RFC 7234'te tanımlanmıştır: “Bir yanıt, max-age yönergesiyle bir Cache-Control alanı içeriyorsa, alıcı Expires alanını GÖRMEZDEN GELMELİDİR.” Pratikte, modern istemciler için Expires'ın hiç döndürülmemesi önerilir, çünkü Cache-Control tüm Expires senaryolarını kapsar. Ancak, eski proxy'ler ve tarayıcılarla geriye dönük uyumluluk için her iki başlık da döndürülebilir.

Expires, esas olarak Nginx ve Apache'deki statik içerik için varlığını sürdürmektedir — bu sunucular otomatik olarak her iki başlığı da ekler. Projeniz Cache-Control olmadan Expires ile karşılaşırsa, onu max-age ile Cache-Control ile değiştirin: önbellek kontrolü doğruluğu artar ve saat dilimine bağımlılık ortadan kalkar. Geçiş için, sunucuyu Expires yerine Cache-Control ekleyecek şekilde yapılandırmak yeterlidir.

# Nginx: Statik dosyalar için Cache-Control
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# Farklı içerik türleri için farklı politikalar
location /api/config {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

location /api/static-data {
    expires 5m;
    add_header Cache-Control "public, max-age=300";
}

Nginx yapılandırmasında, statik dosyalar (CSS, JS, görseller) immutable özelliğiyle 30 gün boyunca Cache-Control olarak ayarlanır — bu özellik, tarayıcıya kaynağın bu URL'de asla değişmeyeceğini bildirir (dosya adındaki hash aracılığıyla sürümleme). API uç noktaları, dinamik veriler için no-cache ve referans verileri için kısa max-age ile public kullanır — sıkça talep edilen ve nadiren değişen listeler.

Mobil Uygulamalarda Önbellek

Mobil uygulamalarda Cache-Control, mobil ağların sınırlamaları nedeniyle özel bir rol oynar: yüksek gecikme, dengesiz bağlantı, trafik limitleri. Doğru önbellek, kullanıcıya verileri anında göstermeye, hatta çevrimdışıyken bile göstermeye ve arka planda güncellemeye olanak tanır. Android'de OkHttp ve iOS'ta URLSession, Cache-Control'a saygı duyan yerleşik önbellek sistemlerine sahiptir.

OkHttp, yanıttan Cache-Control'u okuyan ve önbelleği otomatik olarak yöneten CacheInterceptor'u kullanır. Sunucu Cache-Control: max-age=3600 döndürdüyse, OkHttp bir saat boyunca sunucuya istek göndermez. max-age süresi dolduktan sonra OkHttp, If-Modified-Since ve If-None-Match ile koşullu bir istek gönderir. OkHttp'de önbellek yapılandırması: OkHttpClient.Builder().cache(Cache(directory, maxSize)).

fun createCachedClient(cacheDir: File): OkHttpClient {
    return OkHttpClient.Builder()
        .cache(Cache(cacheDir, 10L * 1024 * 1024))
        .addNetworkInterceptor { chain ->
            val response = chain.proceed(chain.request())
            response.newBuilder()
                .header("Cache-Control",
                    "public, max-age=300")
                .removeHeader("Pragma")
                .build()
        }
        .build()
}

Kod, 10 MB önbelleğe sahip bir OkHttpClient oluşturur ve NetworkInterceptor aracılığıyla Cache-Control'u geçersiz kılar. Sunucu Cache-Control döndürmez veya Expires kullanırsa, interceptor public, max-age=300 (5 dakika) ekler. Interceptor, uyumluluk için kullanımdan kaldırılan Pragma başlığını (HTTP/1.0) kaldırır. iOS'ta önbellek, memoryCapacity ve diskCapacity ayarlarıyla URLCache.shared aracılığıyla benzer şekilde çalışır.

Çevrimdışı Mod ve stale-while-revalidate

stale-while-revalidate yönergesi, uygulama arka planda yeni verileri alırken kullanıcıya eski önbelleği göstermeye olanak tanır. Bu, anında yanıt efekti sağlar: kullanıcı içeriği hemen görür ve bir saniye sonra güncel sürüme güncellenir. OkHttp sürüm 3.10'dan itibaren ve iOS 14+'ta URLCache tarafından desteklenir. Örnek: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 saat güncel önbellek, ardından arka planda güncellemeyle 5 dakika eski veri gösterimi.

Cache-Control Yapılandırma Örnekleri

Farklı kaynak türleri farklı önbellek stratejileri gerektirir. Mobil geliştirmedeki tipik senaryolar için en uygun yapılandırmaları inceleyelim. Dosya adında hash olan statik içerik (bundle.abc123.js) için, immutable ile max-age'i 1 yıla kadar ayarlayabilirsiniz. Nadiren güncellenen API listeleri (dizinler, kategoriler) için — stale-while-revalidate ile 5 dakikadan 1 saate kadar max-age.

Güvenliği hatırlamak önemlidir: kullanıcının kişisel verilerini içeren yanıtlar için her zaman private ayarlayın. Bu yönerge olmadan, genel bir proxy (örneğin, kurumsal) yanıtı önbelleğe alabilir ve başka bir kullanıcıya iletebilir. Kimlik doğrulama token'ları ve ödeme bilgileri için no-store kullanın — özel bir önbellek bile bu verileri diskte saklamamalıdır.

Önbellek Hata Ayıklama

Cache-Control'un doğruluğunu doğrulamak için Age başlığını (önbelleğin kaç saniye saklandığı) ve X-Cache'i (CDN'de hit/miss) kullanın. Tarayıcıda — Network sekmesi, Size sütunu “from disk cache” veya “304 Not Modified” gösterir. Bir kaynağın önbelleğe alınması gerekirken her seferinde yükleniyorsa, sunucunun yönergelerinizle birlikte Cache-Control: no-cache veya Pragma: no-cache ekleyip eklemediğini kontrol edin.