WordPress'te Sayfa Önbelleği Çalışıyor mu? HIT ve MISS Kontrolü

Sayfanın önbellekten gelip gelmediğini anlamanın güvenilir yolu yanıt başlıklarını okumaktır. Oturumu kapalı bir tarayıcıdan ya da curl ile aynı adrese art arda iki istek gönderin. LiteSpeed sunucuda x-litespeed-cache: hit, Cloudflare'de cf-cache-status: HIT görüyorsanız önbellek çalışıyor demektir. İlk istekte MISS görmek olağandır. Her istekte MISS ya da BYPASS dönüyorsa yanıtı önbellek dışı bırakan bir şey vardır: oturum veya WooCommerce çerezi, sorgu dizesi, sunucunun gönderdiği Set-Cookie ya da no-cache başlığı. Cloudflare'de DYNAMIC görmek ise varsayılan ayarda HTML önbelleğe alınmadığı için hata sayılmaz.

Neden ayar ekranına güvenmiyoruz?

Önbellek eklentisinde "Enable Cache" açık, yeşil tikler yerinde, ama site hâlâ yavaş. Bu durumda ilk sorulacak soru "ziyaretçiye giden yanıt gerçekten önbellekten mi geliyor?" olmalı. Eklenti açık olabilir ve yine de her sayfayı PHP'de üretebilir: başka bir eklenti her yanıta çerez ekliyordur, sunucu LiteSpeed değildir, önünde önbelleği bozan bir CDN vardır. LiteSpeed'in sorun giderme belgesi de aynı noktadan başlar ve yanıt başlıklarında X-LiteSpeed-Cache satırını aramanızı ister.

Sayfanın en altındaki HTML yorumlarına da fazla güvenmeyin. Bazı önbellek eklentileri sayfanın sonuna eklenti adını ve üretim zamanını içeren bir yorum ekler. Ama bu yorum sayfa üretilirken yazılır ve önbelleğe alınan kopyanın içinde aynen durur. Size sayfanın bir zamanlar o eklenti tarafından üretildiğini söyler, bu yanıtın önbellekten gelip gelmediğini değil. HTML küçültme açıksa yorum hiç görünmeyebilir. Başlıklar ise her yanıtta yeniden yazılır, güvenilir olan onlardır.

Başlıkları iki yoldan okuyun

Tarayıcının geliştirici araçları

Gizli bir pencere açın, böylece oturum ve sepet çerezleriniz isteğe karışmaz. Geliştirici araçlarında Network sekmesine geçin, sayfayı normal biçimde yenileyin ve listenin en başındaki belge isteğini seçin. Headers sekmesindeki Response Headers bölümünde önbellek başlıklarını arayın. Disable cache kutusunu ve zorla yenilemeyi (Ctrl+Shift+R) bu test için kullanmayın. İkisi de isteğe önbelleği istemeyen başlıklar ekler ve bazı katmanlar buna uyup ölçümünüzü bozabilir.

curl ile iki ardışık istek

Terminaliniz varsa (macOS, Linux ya da Windows'ta WSL) daha temiz bir test yapabilirsiniz. Aşağıdaki döngü aynı adrese iki GET isteği gönderir ve yalnız önbellekle ilgili başlıkları süzer:

for i in 1 2; do
  curl -s -o /dev/null -D - --compressed https://ornek.com.tr/ \
    | grep -iE '^(x-litespeed-cache|cf-cache-status|age|cache-control|vary|set-cookie):'
  echo ---
done

Burada iki ayrıntı önemli. curl -I yerine -D - kullanıyoruz, çünkü -I bir HEAD isteği gönderir ve önbellek katmanları HEAD'i GET'ten farklı ele alabilir. Ziyaretçi GET yapar, test de GET yapmalı. --compressed ise tarayıcı gibi sıkıştırılmış yanıt istediğimizi söyler. Sıkıştırma isteğe göre ayrı kopya tutan bir önbellekte, bu seçenek olmadan tarayıcıların kullandığı kopya yerine başka bir kopyaya bakmış olursunuz.

Beklenen sonuç, birinci blokta MISS ya da HIT, ikincisinde HIT'tir. Cloudflare arkasındaysanız ikinci yanıtta age değerinin sıfırdan büyük olduğunu da görürsünüz.

Başlıkların anlamı

LiteSpeed tarafı sade. x-litespeed-cache: hit sayfanın sunucudaki LSCache'ten geldiğini, miss bu isteğin önbellekten karşılanmadığını ama kopyanın oluşturulmaya başlandığını gösterir. LiteSpeed belgesine göre bir sonraki istek hit dönmelidir, sürekli miss görüyorsanız bir sorun vardır. hit,private ise yanıtın o kullanıcıya özel (private) önbellekten geldiğini anlatır, oturum açmış kullanıcılar için önbellek açıksa görülür. Başlığın hiç olmaması, yanıtın LiteSpeed önbelleğinden gelmediği anlamına gelir. Sunucu LiteSpeed olmayabilir ya da sayfa önbellek dışında tutulmuştur.

Cloudflare'in değerleri daha ayrıntılı. Tanımlar Cloudflare'in Eylül 2026'da güncellenen önbellek yanıtları sayfasından:

Cloudflare'in varsayılan davranış sayfası açık: CDN, HTML ve JSON'u varsayılan olarak önbelleğe almaz. Sitenizin önünde Cloudflare varsa ve HTML için ayrıca bir önbellek kuralı yazmadıysanız sayfalarda DYNAMIC görmeniz beklenen sonuçtur, CSS, JS ve görseller ise HIT döner. Bu durumda HTML önbelleği sunucudaki katmanda, örneğin LSCache'te çalışır.

İki katman birlikteyken

Cloudflare arkasında LiteSpeed çalışan bir sitede iki başlığı birlikte okumak gerekir. cf-cache-status: DYNAMIC ile x-litespeed-cache: hit yan yana geliyorsa HTML'i sunucudaki önbellek veriyor, Cloudflare yalnız aracılık ediyordur. Bu çoğu site için sağlıklı bir düzen. Cloudflare'de HTML'i de önbelleğe alan bir kural açtıysanız dikkat: cf-cache-status: HIT olan bir yanıttaki x-litespeed-cache değeri, Cloudflare'in kopyayı aldığı andaki başlıktır, şimdiki durumu göstermez. Üstelik eklentiden yaptığınız temizleme Cloudflare'deki kopyaya ulaşmayabilir. İki katmanı birlikte kullanacaksanız temizlemenin ikisine birden gittiğinden emin olun.

LiteSpeed'in sorun giderme belgesi ters yöndeki bir tabloyu da anlatıyor: bazı CDN önbellek ayarları LSCache'i bozar ve her yanıtta miss görülür, sunucuya doğrudan gidildiğinde ise hit gelir. Cloudflare'i atlayarak sunucunuzu doğrudan test etmek için curl komutuna sunucu IP'siyle --resolve ornek.com.tr:443:203.0.113.10 eklemeniz yeterli.

Neden hep MISS ya da BYPASS görüyorum?

İki ardışık istekte de MISS alıyorsanız önbellek kopyayı tutamıyordur ya da her istek farklı bir kopyaya denk geliyordur. En sık rastlanan nedenler ve kontrolleri:

Çerez meselesine biraz daha yakından bakalım, çünkü en çok zaman burada kaybediliyor. Cloudflare'in varsayılan davranış sayfası, yanıtta Set-Cookie başlığı varsa önbelleğe almadığını açıkça yazıyor. Diğer katmanlar da çoğu zaman benzer davranır. Bir eklentinin her sayfada PHP oturumu başlatması özellikle sinsidir. PHP'nin varsayılan session.cache_limiter değeri nocache olduğu için oturum açılan her yanıta önbelleği reddeden başlıklar eklenir, bir de PHPSESSID çerezi yazılır. LiteSpeed belgesi de PHP oturumuna bağlı sayfaların önbelleğe uygun olmadığını belirtir. Çerezin adı çoğu zaman sahibini ele verir.

Sorgu dizelerinde ise sorun çoğu zaman görünmezdir. Ana sayfa testinizde HIT görürsünüz ama reklamdan gelen ziyaretçilerin her biri ?gclid= ile farklı bir adrese gelir ve hepsi MISS olur. LSCache'te izleme parametrelerini Drop Query String ayarına ekleyerek bu adreslerin ortak kopyayı kullanmasını sağlayabilirsiniz. Belgeye göre bu yöntem LiteSpeed Enterprise 5.2.3 ve üzerinde çalışır. LSCache'in diğer ayarlarını LiteSpeed Cache kurulum ve önbellek ayarları rehberinde anlattık.

Mobil testi şöyle yaparsınız:

curl -s -o /dev/null -D - --compressed \
  -A "Mozilla/5.0 (Linux; Android 14; Mobile)" \
  https://ornek.com.tr/ | grep -iE '^(x-litespeed-cache|cf-cache-status):'

Sepet, ödeme ve hesabım sayfalarında BYPASS doğru sonuçtur

Bu sayfalarda MISS ya da BYPASS gördüğünüzde düzeltmeye kalkmayın. WooCommerce'in önbellek eklentisi rehberi Cart, My Account ve Checkout sayfalarının dinamik kalması gerektiğini, çünkü o anki müşteriye ve sepetine özel bilgi gösterdiklerini yazıyor. Aynı rehber önbellek dışında tutulacak çerezleri de sayıyor: woocommerce_cart_hash, woocommerce_items_in_cart ve wp_woocommerce_session_ ile başlayan oturum çerezi. LSCache'in belgesine göre bu üç sayfa eklentide varsayılan olarak önbellek dışındadır. Bu sayfaların neden önbelleğe alınamadığını WooCommerce'in hosting gereksinimlerini anlattığımız yazıda ele aldık.

Tersini görmek asıl alarm işaretidir. Sepet sayfasında HIT görüyorsanız bir ziyaretçinin sepeti başkasına görünebilir. Bu sayfaların hızı sunucu ve eklenti tarafında çözülür. Bu sayfalar yavaşsa yapılacak iş, sepet ve ödeme adımındaki istekleri tek tek ölçmektir. Yönetim paneli için de durum aynı: panel hiçbir zaman sayfa önbelleğinden gelmez, wp-admin yavaşlığının kendine özgü nedenleri vardır.

Site sağlığı "sayfa önbelleği algılandı" diyorsa

WordPress 6.1'den bu yana Site sağlığı ekranında sayfa önbelleği ve sunucu yanıt süresi testi var. Test ana sayfayı üç kez ister, ortanca süreyi 600 milisaniyelik eşikle karşılaştırır ve yanıt başlıklarında önbellek izi arar. Çekirdek kaynak koduna bakınca bu izlerin geniş tutulduğu görülüyor. x-litespeed-cache ve cf-cache-status için değerde HIT aranır, ama etag, last-modified ve via başlıklarının yalnız var olması da önbellek sayılır. Yani yeşil bir sonuç, HTML'in gerçekten önbellekten geldiğini kanıtlamaz. Kesin cevap yine yukarıdaki iki ardışık istekte.

Nesne önbelleği bu testin neresinde?

Redis ya da Memcached gibi kalıcı bir nesne önbelleği yanıt başlıklarında görünmez, çünkü HTML'i değil veritabanı sorgu sonuçlarını saklar. Sayfa önbelleği MISS verdiğinde ya da hiç devreye giremediğinde (sepet, ödeme, panel) PHP'nin işini hafifletir. İki katmanın farkını ve hangisinin nerede işe yaradığını WordPress'te Redis nesne önbelleğinin sayfa önbelleğinden farkı üzerinden okuyabilirsiniz. Burada aklınızda kalması gereken tek şey şu: HIT/MISS testi yalnız sayfa önbelleğini ölçer.

Düzeldiğini nasıl doğrularsınız?

Bir değişiklik yaptıktan sonra (çerez yazan eklentiyi değiştirmek, sorgu parametresi kuralı eklemek) önbelleği temizleyin ve sitenizin farklı sayfa türlerinden birer örnek seçin: ana sayfa, bir kategori ya da arşiv sayfası, bir ürün ya da yazı, iletişim sayfası. Her biri için iki ardışık curl isteğinin ikincisinde HIT görmelisiniz. Sepet, ödeme ve hesap sayfalarında ise BYPASS, MISS ya da önbellek başlığının hiç olmaması doğru sonuçtur.

Sonra içeriği güncelleyerek temizlemenin çalıştığını sınayın. Bir yazıda küçük bir değişiklik yapın, sayfayı oturum kapalıyken açın. Değişiklik görünüyor ve ilk istek MISS, ikincisi HIT dönüyorsa temizleme ve yeniden doldurma düzgün işliyordur. Değişiklik görünmüyorsa iki katmandan biri (çoğu zaman CDN) eski kopyayı tutuyordur.

Son adım ölçüm. Önbellekten gelen yanıtın sunucu süresi, PHP'de üretilen yanıta göre genellikle belirgin biçimde kısadır. Bunu TTFB'yi farklı saatlerde ölçerek takip edebilirsiniz. Önbellek oranı arttıkça sunucudaki eşzamanlı PHP işlemi de azalır, 508 Resource Limit Reached gibi kaynak limiti hatalarının en etkili ilacı da budur.

Netx'in cPanel web hosting ve WordPress hosting sunucularında LiteSpeed web sunucusu ve LSCache kullanılır, bu yüzden bu paketlerde x-litespeed-cache başlığını görmeyi beklersiniz. Görmüyorsanız ya da Plesk tabanlı bir pakette önbelleğin hangi katmanda çalıştığından emin değilseniz, test çıktınızı müşteri panelinden açacağınız destek talebine ekleyin.

Sık sorulan sorular

Cloudflare'de HTML'i de önbelleğe almalı mıyım?

Ziyaretçileriniz sunucunuza coğrafi olarak yakınsa ve sunucuda iyi çalışan bir sayfa önbelleği varsa çoğu zaman gerekmez. Alacaksanız Cache Rules ile kural yazmanız gerekir ve bu kural oturum açmış kullanıcıları, sepet çerezi olan ziyaretçileri ve sepet, ödeme, hesap adreslerini mutlaka dışarıda bırakmalıdır. Aksi hâlde kişiye özel sayfalar başkalarına gösterilebilir. İçerik güncellemelerinde Cloudflare'deki kopyanın da temizlendiğinden emin olmadan bu adımı atmayın.

Önbellek HIT ama sayfa yine yavaş, neden?

HIT yalnız HTML'in hızlı geldiğini gösterir. Sayfanın tamamlanması görsellere, betiklere, yazı tiplerine ve üçüncü taraf servislere de bağlıdır. Ağ sekmesinde belge isteğinin süresi kısa ama sayfa geç tamamlanıyorsa sıradaki durak ön yüz optimizasyonudur.