Edge cache ile origin cache arasındaki fark nasıl anlaşılır?

Edge cache ve origin cache farkını HTTP başlıkları, CDN durumu ve sunucu yanıtları üzerinden ayırt etmeyi; yanlış cache temizliğini önlemeyi öğrenin.

Reklam Alanı

Bir sayfanın hızlı açılması her zaman aynı önbellek katmanından servis edildiği anlamına gelmez. Özellikle CDN kullanılan yapılarda içerik bazen kullanıcıya en yakın edge noktasından, bazen de asıl hosting altyapısındaki origin sunucudan gelir. Bu ayrımı doğru yapmak; performans sorunlarını teşhis etmek, yanlış cache temizliği yapmamak ve güncel olmayan içerik problemlerini hızlı çözmek için önemlidir.

Edge cache ve origin cache nedir?

Edge cache, içeriğin kullanıcının coğrafi konumuna yakın CDN uç noktalarında tutulmasıdır. Örneğin İstanbul’daki bir ziyaretçi, sayfayı Avrupa’daki bir CDN noktasından alabilir. Bu sayede gecikme azalır, origin sunucuya giden istek sayısı düşer ve yoğun trafikte daha kararlı bir deneyim sağlanır.

Origin cache ise web sitesinin asıl çalıştığı sunucu tarafında tutulan önbellektir. WordPress cache eklentileri, web sunucusu seviyesindeki cache mekanizmaları veya uygulama katmanındaki geçici veriler buna örnektir. Origin cache devredeyken CDN olmasa bile sayfalar daha hızlı üretilebilir.

Farkı anlamanın en pratik yolu: HTTP başlıklarını kontrol etmek

Edge cache ile origin cache arasındaki farkı anlamak için ilk bakılacak yer HTTP response header bilgileridir. Tarayıcı geliştirici araçlarında Network sekmesinden sayfa isteğini açarak bu başlıkları görebilirsiniz. Komut satırında ise curl -I alanadiniz.com benzeri bir sorgu yeterlidir.

Edge cache işaretleri

CDN servisleri genellikle yanıt başlıklarında cache durumunu belirtir. Şu tür ifadeler edge katmanından servis edildiğini gösterebilir:

  • cf-cache-status: HIT gibi CDN’e özgü cache durumu
  • x-cache: HIT veya Age başlığında yüksek saniye değeri
  • Sunucu IP’sinin doğrudan origin yerine CDN ağına ait görünmesi
  • Aynı içeriğin farklı bölgelerden benzer hızlarla açılması

Burada dikkat edilmesi gereken nokta, her CDN’in aynı başlıkları kullanmamasıdır. Bir serviste “HIT” görülen alan başka bir serviste farklı adlandırılabilir. Bu nedenle kullanılan CDN panelindeki dokümantasyon veya response header isimleri birlikte değerlendirilmelidir.

Origin cache işaretleri

Origin cache tarafında ise genellikle WordPress, web sunucusu veya uygulama katmanı izleri görülür. Örneğin x-litespeed-cache: hit, x-cache-handler veya eklentiye özel başlıklar origin seviyesinde cache olduğunu gösterebilir. Bazı sistemlerde bu başlıklar güvenlik nedeniyle gizlenmiş olabilir; bu durumda davranış analizi yapmak gerekir.

Yanlış cache katmanını temizlemek neden soruna yol açar?

Bir sayfada eski fiyat, eski görsel veya güncellenmemiş metin görünüyorsa çoğu kullanıcı doğrudan tüm cache’i temizler. Bu yaklaşım kısa vadede işe yarayabilir, ancak yoğun trafikli sitelerde gereksiz kaynak tüketimine neden olur. Sorun edge cache’teyse yalnızca CDN cache temizliği yeterli olabilir. Sorun origin cache’teyse CDN’i temizlemek içeriği yenilemez; CDN tekrar eski origin çıktısını alabilir.

Pratik kontrol için önce CDN’i geçici olarak bypass ederek origin yanıtını test edin. Ardından aynı URL’yi normal CDN üzerinden çağırın. Origin güncel, CDN eskiyse problem edge tarafındadır. Origin de eski yanıt veriyorsa kaynak hosting sunucusu, WordPress cache eklentisi veya uygulama seviyesindeki önbellektir.

Test yaparken dikkat edilmesi gereken noktalar

Cache testlerinde en sık yapılan hata, yalnızca tek tarayıcı sonucuna bakmaktır. Tarayıcı cache’i de devrede olabileceği için gizli pencere, farklı tarayıcı ve mümkünse komut satırı testi birlikte kullanılmalıdır. Ayrıca oturum açmış kullanıcı ile anonim ziyaretçi aynı cache davranışını görmeyebilir.

URL varyasyonlarını karıştırmayın

https://site.com, https://www.site.com, sorgu parametreli URL’ler ve mobil varyasyonlar farklı cache anahtarları oluşturabilir. Bir URL’de güncel içerik görünürken diğerinde eski içerik kalabilir. Test ederken tam URL’yi sabit tutmak ve yönlendirmeleri izlemek daha doğru sonuç verir.

Dinamik sayfalarda cache kuralını kontrol edin

Sepet, ödeme, kullanıcı paneli, arama sonuçları ve kişiselleştirilmiş sayfalar edge cache’e alınmamalıdır. Bu alanlarda hatalı kural uygulanırsa kullanıcıya yanlış veri gösterilebilir. Kurumsal sitelerde statik sayfalar, blog içerikleri, görseller ve CSS/JS dosyaları cache için daha güvenli adaylardır.

Karar verirken hangi katmanı önceliklendirmelisiniz?

Global ziyaretçi kitlesi olan sitelerde edge cache, gecikmeyi azaltmak için kritik avantaj sağlar. Ziyaretçilerin çoğu aynı ülke içindeyse bile CDN, yoğun trafik anlarında origin üzerindeki baskıyı düşürür. Buna karşılık origin cache, sayfanın üretilme maliyetini azaltır ve CDN olmasa da performansa katkı sunar.

En sağlıklı yapı, iki katmanın birbirini tamamlamasıdır. Origin tarafı hızlı ve doğru çıktı üretmeli; edge tarafı bu çıktıyı doğru sürelerle dağıtmalıdır. TTL değerleri çok uzun seçilirse güncellemeler gecikir, çok kısa seçilirse cache verimi düşer. Haber, kampanya ve fiyat bilgisi içeren sayfalarda daha kısa TTL; sabit kurumsal içeriklerde daha uzun TTL tercih edilebilir.

Hızlı teşhis kontrol listesi

  • HTTP başlıklarında CDN’e ait HIT/MISS bilgisini kontrol edin.
  • Age başlığı varsa içeriğin edge üzerinde ne kadar süredir tutulduğunu inceleyin.
  • CDN bypass ile origin yanıtını karşılaştırın.
  • WordPress cache eklentisi veya sunucu cache başlıklarını ayırt edin.
  • Testleri anonim kullanıcı, gizli pencere ve farklı ağ üzerinden tekrarlayın.
  • Dinamik sayfaların cache dışında kaldığından emin olun.

Bu yöntemlerle edge cache ile origin cache arasındaki fark çoğu senaryoda net biçimde ayrıştırılabilir. Özellikle güncel içerik görünmeme, bölgesel hız farkı veya beklenmedik yönlendirme gibi durumlarda önce hangi katmanın yanıt verdiğini belirlemek, gereksiz müdahaleleri azaltır ve sunucu kaynaklarını daha kontrollü kullanmayı sağlar.

Kategori: Domain
Yazar: Meka
İçerik: 706 kelime
Okuma Süresi: 5 dakika
Zaman: 2 gün önce
Yayım: 13-07-2026
Güncelleme: 13-07-2026