WordPress ve WooCommerce’de Tam Sayfa Önbelleği
Kampanya sırasında bir WooCommerce mağazasının genel ürün sayfaları ve sepet işlemleri aynı sunucu kapasitesini paylaşabilir. Güvenle yeniden kullanılabilen HTML yanıtlarını önbellekten sunmak, PHP ve veri tabanı işini azaltabilir. Ancak bu kazanç hit oranına ve gerçek darboğaza bağlıdır; sepetin, ödemenin veya kişisel hesabın ortak önbelleğe alınmasını haklı çıkarmaz.
Bu rehber Nginx FastCGI Cache, Varnish Cache ve LiteSpeed Cache’in nerede kullanıldığını; bypass, TTL, geçersizleştirme ve test gereksinimlerini karşılaştırır. Önce herkese aynı içeriği döndüren sayfaları belirleyin. Fiyat, vergi, para birimi, dil veya oturum nedeniyle değişen yanıtlar için güvenli varyant ayrımı kanıtlanamıyorsa isteği ortak önbellekten hariç tutun.
Tam Sayfa Önbelleği Hangi İşi Azaltır?
Tam sayfa önbelleği, dinamik olarak üretilmiş HTML yanıtını belirli koşullarda yeniden kullanır. Sunucu katmanındaki bir hit, WordPress PHP işlemlerini ve bunların veri tabanı sorgularını atlayabilir. Miss durumunda uygulama yine çalışır; süre dolması, farklı cache anahtarı veya bypass nedeniyle her ziyaret hit olmaz. Bu nedenle yalnız ana sayfayı hızlı görmek yerine istek türüne göre hit oranını, gecikmeyi ve hata oranını ölçün.
Ortak cache yalnız aynı yanıtı almaya yetkili ziyaretçiler arasında kullanılmalıdır. Giriş yapanlar, sepet/ödeme/hesap yolları ve durum değiştiren istekler cache’i hem okumayı hem doldurmayı atlamalıdır. İlk kurulumda bütün çerezli, yetkilendirme başlıklı ve sorgu parametreli istekleri dışarıda bırakmak daha kolay doğrulanan bir başlangıçtır. TTL, kabul edilen içerik eskiliğini belirler; kişisel veriyi ayırmanın yerine geçmez.
Nginx FastCGI Cache: Bypass ve Geçersizleştirme
Nginx FastCGI Cache, Nginx’in PHP-FPM gibi bir FastCGI uygulamasından aldığı yanıtları saklar. Mevcut Nginx mimarisinde ayrı bir HTTP cache servisi gerektirmez. Cache anahtarına doğru site/host, şema, URI ve gerekiyorsa doğrulanmış varyantlar girmelidir. Önce birkaç bilinen genel sayfayı izin listesine alın; hariç tutulan bir yolun yanlışlıkla ortak yanıtı okumasını da test edin.
WooCommerce için doğru bypass ve TTL
WooCommerce’in woocommerce_items_in_cart, wp_woocommerce_session_ ve wordpress_logged_in_ gibi çerezleri kişiselleştirmeyi gösterebilir; yalnız adlarını listelemek bypass kurmaz. fastcgi_cache_bypass okumayı, fastcgi_no_cache yazmayı engeller; iki koşul kümesi uyumlu olmalıdır. Gerçek, varsa yerelleştirilmiş sepet/ödeme/hesap yollarını, yönetim/giriş/REST ve özel hassas uçları dışlayın. GET/HEAD dışını ve add-to-cart dahil durum değiştiren sorguları cache’lemeyin; daha dar başlangıç politikası yalnız çerezsiz GET isteklerine izin verebilir.
TTL’yi ürünün fiyat/stok ve yayın güncelliği gereksinimine göre belirleyin. Nginx’in stale-on-error veya updating seçenekleri taze TTL bittikten sonra da eski yanıt sunabilir; on dakikalık TTL tek başına on dakikalık azami içerik yaşı değildir. İlk kurulumda stale ve arka plan yenilemeyi kapalı tutun. Sonradan gerekliyse yanıt başlıkları, uygulama ve CDN dahil izin verilen eskilik süresini tanımlayıp hata/yenileme durumlarında ölçün.
Temizlik ve geçersiz kılma alışkanlıkları
Ürün değişince yalnız detay URL’si değil, ürünü gösteren kategori, etiket, ana sayfa ve dil/para birimi gibi önbellek varyantları da etkilenebilir. Nginx’in resmi fastcgi_cache_purge özelliği ticari abonelik kapsamındadır; açık kaynak kurulumlarda uyumlu üçüncü taraf cache_purge modülü veya incelenmiş uygulama entegrasyonu gerekir. Dosya adlarını tahmin ederek silmeyin. Temizleme olaylarının bütün cache katmanlarına ulaştığını ve yetkisiz istemcinin purge tetikleyemediğini doğrulayın.
Bir detay daha var: UTM gibi izleme parametreleri cache anahtarını şişirip gereksiz varyantlar üretmesin. utm_source, utm_medium, gclid gibi parametreleri yalnızca yanıtı ve uygulama davranışını değiştirmedikleri doğrulandığında yok saymak, aynı sayfa için onlarca kopyayı önler. Üstüne bir de mobil ve masaüstü arasında gerçekten farklı HTML üretmiyorsanız, kullanıcı aracısı temelli varyasyonlardan kaçınmak sadeleştirir.
Nginx FastCGI Cache dokümantasyonu bypass/no-cache, anahtar, kilit, TTL ve purge direktiflerinin bağlamını açıklar. Map ve cache_path tanımları http bağlamında olmalıdır. PHP kökü/soketi, mevcut dosya kontrolü, HTTPS ve güvenlik kuralları dağıtıma özgüdür; başka bir siteden alınan örneği bu ayrıntıları uyarlamadan etkinleştirmeyin.
Varnish: HTTP Katmanında Önbellek Politikası
Varnish Cache web sunucusunun önünde HTTP yanıtlarını önbelleğe alır; PHP-FPM’in FastCGI soketine doğrudan HTTP göndermez. VCL ile yöntem, URL, çerez, yetkilendirme ve yanıt başlıklarına göre politika tanımlanır. Ek katmanın yönetim, izleme ve geçersizleştirme sorumluluğu vardır; yalnız trafik yüksek diye otomatik olarak gerekli veya daha hızlı değildir.
WordPress ve WooCommerce İçin VCL Kuralları
Varnish, wp-admin ve wp-login.php yollarını WordPress bilgisiyle kendiliğinden ayırmaz. cart, checkout, my-account örneklerinin yerine mağazanın gerçek yollarını da ekleyerek açık pass kuralları tanımlayın. woocommerce_items_in_cart ve wp_woocommerce_session_ tek olası kişiselleştirme işaretleri değildir. Başlangıçta bütün çerezleri ve Authorization taşıyan istekleri pass edin; sorguları silmek yerine bypass edin. Yalnız doğrulanmış genel sayfaları cache’e uygun sayın; Set-Cookie, private/no-store ve diğer yerleşik yanıt kontrollerini atlamayın.
Buradaki açık kaynak Varnish Cache düzeninde HTTPS ayrı bir TLS proxy’sinde sonlandırılır; bunu bütün Varnish ürünleri hakkında genelleştirmeyin. Güvenilen proxy istemciden gelen X-Forwarded-Proto değerini gerçek bağlantıya göre yeniden yazmalı, backend de yalnız bu güvenilen kaynaktan kabul etmelidir. Varnish/backend erişimini sınırlandırın; aksi halde bir istemci şema bilgisini taklit edebilir. WordPress URL ve yönlendirme davranışını gerçek proxy zinciriyle test edin.
Purge ve BAN ile Geçersizleştirme
Purge genellikle bir cache anahtarının, BAN ise tanımlı koşulları sağlayan nesnelerin geçersizleştirilmesinde kullanılır. BAN adlı bir HTTP isteği göndermek tek başına işlem yapmaz: yöntem, yetkilendirme ve nesne metaverisi VCL/entegrasyonda uygulanmalıdır. Yalnız güvenilen yönetim kaynağına erişim verin; imzalı çağrı kullanılıyorsa doğrulama ve tekrar oynatma sınırı da gerekir. Varnish belgeleri seçilen sürümün davranışını açıklar. Ürün, arşiv ve varyant kapsamını kontrollü bir güncellemeyle doğrulayın.
LiteSpeed Cache ve WordPress Entegrasyonu
LiteSpeed Cache for WordPress, uyumlu sunucu cache motoruyla sayfa önbelleği ve WooCommerce entegrasyonu sağlar. Eklentiyi kurmak tek başına her sunucuda bu motoru açmaz. ESI, LiteSpeed Web Server Enterprise, Web ADC veya QUIC.cloud CDN gibi destekleyen katmanları gerektirir; OpenLiteSpeed ESI desteklemez. Kullanılabilir özellik ve kaynak sınırlarını seçilen hizmette doğrulayın.
ESI Parçalarını Tam Sayfalardan Ayırmak
ESI bir sayfayı ayrı yönetilen parçalara ayırır. Örneğin desteklenen bir mini sepet parçası özel cache’te, kendine ait TTL ile veya her istekte yeniden üretilecek biçimde ele alınabilir. Bu, tüm sepet/ödeme/hesap sayfalarını ortak cache’e açmak değildir; bu sayfalar hariç kalmalıdır. Özel cache her zaman anlık veri anlamına gelmez. Sunucu ve eklenti desteği, tema/eklenti entegrasyonu, kullanıcı ayrımı, parça TTL’si ve geçersizleştirme birlikte test edilmelidir.
Uyumlu WooCommerce ayarları
LSCWP, WooCommerce’in ilişkilendirdiği Cart, Checkout ve My Account sayfalarını varsayılan olarak hariç tutar; yanlış sayfa ataması veya özel uçlar ayrıca kontrol gerektirir. İlk aşamada oturum açmış kullanıcı cache’ini kapalı tutun. Rol bazlı bir genel varyant, aynı roldeki iki kişinin hesap verisini ayırmaz. Mobil varyantı yalnız tema veya kullanılan optimizasyon özelliği gerektiriyorsa açın. Dil, para birimi, kampanya ve vergi değişimlerini ayrı oturumlarla sınayın. LiteSpeed Cache for WordPress belgeleri ayarların gerçek etkisini açıklar.
CDN ve Nesne Önbelleğiyle Birlikte Çalışma
CDN’ye genel statik dosyaları vermek ile HTML’i edge üzerinde saklamak ayrı kararlardır. HTML cache kullanılıyorsa origin’deki okuma/yazma dışlamaları, varyant ayrımı ve geçersizleştirme edge’de de uygulanmalıdır. Bir katmanda bypass olması diğerinde de bypass olduğu anlamına gelmez. WordPress CDN ve WooCommerce HTML bypass rehberi bu katmanları birlikte değerlendirir. ESI kullanan bir düzende uyumsuz ikinci HTML cache’i etkinleştirmeden ürün belgelerini kontrol edin.
Redis veya Memcached nesne önbelleği, tam HTML yerine uygulamanın yeniden kullanabildiği veri nesnelerini saklar. Tam sayfa cache’ten geçmeyen isteklerde de bazı uygulama/veri tabanı işlerini azaltabilir; otomatik sorgu hızlanması garantisi değildir. Doğru entegrasyon, siteye özel ad alanı, veri geçersizleştirme ve arıza davranışı gerekir. İki katmanın hit oranını ve bellek/işlem maliyetini ayrı izleyin.
Cache-Control, Expires ve Vary davranışını origin, CDN ve tarayıcı düzeyinde inceleyin. Kişisel yanıtların no-store politikasını bir cache kuralıyla zorla geçersiz kılmayın; Set-Cookie başlığını yalnız hit oranı yükselsin diye silmeyin. Genel HTML’in tarayıcıda uzun süre kalması sunucudan purge ile geri alınamaz. Bu nedenle ortak cache TTL’sini tarayıcı tazelik süresinden ayrı düşünün.
WooCommerce İçin Uygulama Kontrol Listesi
Uygulamadan önce gerçek URL, yöntem, çerez ve yetkilendirme envanteri çıkarın. Sepet, ödeme, hesap, giriş/yönetim, API, preview ve özel kişisel yolları hem cache okuma hem yazma dışında bırakın. Başlangıçta yalnız açıkça seçilmiş genel sayfalardaki çerezsiz GET isteklerini cache’leyin; HEAD ve diğer yöntemler dinamik kalabilir. Ürün/arşiv TTL’sini iş gereksinimine göre seçin ve fiyat/stok değişiminin hangi sayfalarda göründüğünü kaydedin.
İzleme parametrelerini ancak yanıtı, yönlendirmeyi ve uygulama davranışını değiştirmedikleri kanıtlandığında normalize edin; başlangıç politikasında bütün sorgulu URL’ler bypass edilebilir. Arama, filtre, dil ve para birimi için gerekçesiz ortak anahtar kullanmayın. Yayın/ürün güncellemelerinde etkilenen detay, arşiv, ana sayfa ve varyantları temizleyin. Geniş purge gerekiyorsa origin’de oluşacak miss yükünü ve kontrollü ısıtmayı planlayın.
Purge yönetimini yetkili kaynaklarla sınırlayın. wp-cron, ödeme/webhook çağrıları ve uygulama işlemlerini genel HTML cache’ine sokmayın. Proxy/CDN arkasında yönetim istemcisi kimliğini güvenilen ağ/başlık zinciri üzerinden doğrulayın. Değişiklikten önce gecikme, hit/miss, hata ve kaynak tüketimi başlangıcını alın; sonra aynı istek türleri ve benzer yükte karşılaştırın. Sepet işlemlerinin doğruluğu performans ölçümünden ayrı geçmelidir.
Mimariye Göre Önbellek Seçimi
Örnek olarak, mevcut Nginx ve PHP-FPM kullanan tek sunuculu bir mağazada FastCGI Cache, ek bir HTTP proxy işletmeden genel yanıtları saklayabilir. Birden fazla backend veya ayrıntılı HTTP politikası gereken yapıda Varnish değerlendirilebilir. Bu senaryolar ölçülmüş müşteri sonuçları değildir: seçim, ek servis sorumluluğu, purge entegrasyonu, hata davranışı ve ekibin yönetim becerisiyle birlikte yapılmalıdır.
Mevcut LiteSpeed altyapısı ve uyumlu eklentiler, panelden yönetilen bir cache düzenini kolaylaştırabilir. ESI gerekiyorsa ürün desteği ve gerçek parçalar önceden doğrulanmalıdır. Çok kişiselleştirilmiş bir mağazada düşük genel hit oranı normal olabilir; bunu kişisel sayfaları ortak cache’e açarak yükseltmeyin. Nginx, Varnish ve LiteSpeed’in hiçbiri yanlış uygulama yanıtını veya eksik geçersizleştirme politikasını kendiliğinden düzeltmez.
Ölçüm ve İşlev Testleri
curl -I yalnız HEAD isteği gönderir; GET cache politikasını tek başına kanıtlamaz. GET ile başlıkları ve gövdeyi alın, aynı URL’yi aynı koşullarda tekrarlayın. İlk istek önceden ısıtılmışsa zaten hit olabilir; Set-Cookie veya no-store yanıtında ise ikinci istek de hit olmamalıdır. Cache durum başlığının hangi katmana ait olduğunu doğrulayın; CDN’nin sakladığı eski origin başlığını güncel origin durumu sanmayın.
İzole staging’de iki ayrı ziyaretçi ve iki ayrı hesapla sepet, kupon, kargo, vergi, para birimi, ödeme dönüşü ve hesap sayfalarını sınayın. Çerezli istek hem mevcut ortak kopyayı okumamalı hem sonraki anonim isteğin gövdesini değiştirmemelidir. Özel API, mobil tema, JavaScript açık/kapalı ve nonce süresi senaryolarını ekleyin; ödeme/e-posta yan etkilerini test modunda engelleyin. Sözdizimi kontrolü bu işlev testlerinin yerine geçmez.
Ürün güncellemesi sonrası tüm ilgili sayfa ve varyantların tazelendiğini; backend hatasında eski veri sunulup sunulmadığını kontrol edin. Nginx FastCGI Cache, Varnish belgeleri ve LiteSpeed Cache belgeleri seçilen sürümün davranışını doğrulamak için kullanılabilir. Kural değişikliğinde geri dönüş yapılandırmasını saklayın; yalnız başarılı bir cache başlığına dayanarak uygulamayı tamamlanmış saymayın.
Sonuç: Ölçülen Kazanç ve Doğru İçerik
Tam sayfa önbelleği, uygun genel HTML yanıtlarında uygulama işini azaltabilir. Nginx bunu FastCGI katmanında, Varnish ayrı HTTP katmanında, LiteSpeed ise desteklenen sunucu/eklenti entegrasyonuyla yapar. Ortak gereksinim; açık cache uygunluğu, kişisel ve durum değiştiren isteklerde iki yönlü bypass, doğru varyantlar ve güncelleme olaylarıyla uyumlu geçersizleştirmedir.
Önce küçük bir genel sayfa kümesiyle başlayın. Başlangıç ölçümlerini alın, sözdizimini ve gerçek kullanıcı akışlarını staging’de doğrulayın; ardından katmanları tek tek etkinleştirin. Kaynak kazancını, hata oranını ve veri doğruluğunu birlikte izleyin. Beklenen davranış sağlanmıyorsa ilgili cache kuralını geri alın ve istek/yanıt zincirini inceleyin; daha uzun TTL veya daha geniş cache kapsamı her sorunun çözümü değildir.
