Bir WooCommerce mağazasında ürün sayfaları hızlı açılırken sepet ve ödeme yavaş kalabilir. CDN’de herkese açık HTML’i önbelleğe almak kaynak sunucunun yükünü azaltabilir; ancak kişisel sayfaları yanlışlıkla paylaşmak sepet ve oturum verilerini başka ziyaretçilere gösterebilir. Bu nedenle cache kuralları hız ölçümü kadar veri ayrımı ve alışveriş doğruluğu açısından da değerlendirilmelidir.
Bu rehber, WordPress ve WooCommerce için hangi HTML yanıtlarının önbelleğe alınabileceğini, hangi isteklerin bypass edilmesi gerektiğini ve cache key, TTL, purge ile test akışının nasıl kurulacağını açıklar. CDN kuralı kadar kaynak sunucu ve eklenti önbellekleri de aynı istisnalara uymalıdır. Kısa TTL kişisel yanıtı paylaşmayı güvenli hale getirmez.
WooCommerce’de HTML Cache’i Neden Konuşuyoruz?
WordPress’in statik sayfaları ve blog yazıları CDN’de HTML olarak önbelleğe alındığında, ilk byte süresi yumuşar ve ziyaretçi o tatlı akışı hisseder. WooCommerce’de ise işin içine sepet, kupon, hesap, stok, kişiye özel durumlar girer. Yani dümdüz “her şeyi cache et” yaklaşımı bazen boomerang gibi döner. Bir sayfada hız kazanırken diğerinde sepet tutarsızlığı, stok göstergesinde gecikme ya da kullanıcı girişinin görünmemesi gibi minik ama kritik pürüzler çıkabilir.
Önce yalnız incelenmiş, kişisel veri içermeyen herkese açık sayfaları HTML cache kapsamına alın. Sepet, ödeme, hesap, giriş, önizleme ve oturumla değişen yanıtları kapsam dışında tutun. Aynı URL, boş oturumda herkese açıkken başka bir kullanıcıda kişisel olabilir; bu nedenle yol kontrolüne cookie, yetkilendirme ve yanıt başlığı kontrolleri eklenmelidir.
Bu dengeyi tutturduğunuzda, özellikle yoğun kampanya saatlerinde nefes alıyorsunuz. Sunucu daha az yoruluyor, veritabanına daha az yük biniyor, CDN kenarında sayfalar sıcacık bekliyor. Kapsamı anasayfa, kategori ve incelenmiş ürün sayfaları şeklinde kademeli genişletin; her adımda kişiselleştirme ve bypass kontrollerini tekrarlayın.
Ne Cache’lenir, Ne Bypass Edilir? WordPress Akışıyla Barışmak
Trafiği üç grupta değerlendirin: herkese aynı yanıtı veren sayfalar, fiyat/stok gibi sık güncellenen herkese açık sayfalar ve oturuma göre değişen alanlar. Ürün sayfası üyelik fiyatı, vergi bölgesi, para birimi veya kişisel widget içeriyorsa otomatik olarak ortak cache’e uygun değildir. İzin verilen varyantları doğru ayırın veya bypass edin; kısa TTL yalnız tazelik aralığını sınırlar.
Gerçek WordPress ve WooCommerce rotalarınızı çıkarın: wp-admin, wp-login.php, sepet, ödeme, hesap ve bunların uç noktaları bypass edilmelidir. /cart/, /checkout/ ve /my-account/ yalnız örnektir; Türkçe veya özel kalıcı bağlantıları da kapsayın. add-to-cart, wc-ajax, wc-api, preview ve ilgili eylem parametrelerini sıralarından bağımsız tanıyın. Yorum/form gönderimleri, ödeme dönüşleri ve WooCommerce Store API sepet/ödeme çağrılarını önbelleğe almayın. İncelenmemiş REST uç noktalarını kapsam dışında bırakın.
Yorum gönderimi sonrasında yalnız TTL’yi kısaltmak yeterli değildir. Yorum sahibinin cookie’leriyle doldurulan ad/e-posta alanları veya onay bekleyen içerik ortak HTML’e girmemelidir. Böyle bir yanıtı bypass edin; yayımlanan yorumlar herkese açık sayfayı değiştiriyorsa ilgili sayfa ve arşivlerin purge işlemini tetikleyin.
WordPress’in sabit dosyalarıyla motoru rahatlatmak
Sürüm veya içerik karması taşıyan görsel, CSS ve JS adreslerinde uzun TTL kullanılabilir; aynı URL altında değişen dosyalarda güncelleme/purge planı gerekir. HTML cache’i ayrı bir politika olarak açın. Her yolu kapsayan Cache Everything kuralı, eylem URL’lerini ve kişisel yanıtları da yakalayabileceğinden incelenmiş kapsam ve etkili istisnalar olmadan uygulanmamalıdır.
WooCommerce’in hassas sayfalarında dikkat
Sepet, ödeme ve hesap yanıtları ortak CDN HTML önbelleğine girmemelidir. Kaynaktan uygun private/no-store politikası gönderin ve CDN’nin bunu zorla geçersiz kılmadığını doğrulayın. İlk istekte kullanıcı cookie taşımıyor olsa bile yanıt Set-Cookie ile oturum oluşturabilir; böyle yanıtları bu genel politika altında depolamayın. Bypass ayrıca sunucu tarafındaki sayfa önbelleğinde de uygulanmalıdır.
Cookie Tabanlı Bypass: Sepeti, Girişi ve Önizlemeyi Üzmeyen Kurallar
WooCommerce bir haberleşme dili gibi cookie’ler üzerinden konuşur. En kritik olanlar, sepette ürün olduğunu ve sepetin değiştiğini anlatan cookie’ler. woocommerce_items_in_cart ve woocommerce_cart_hash bu işin belkemiği. Bunların varlığı, sayfanın kişisel olduğunu fısıldar. CDN’e şu cümleyi kuruyoruz: “Bu cookie’lerden biri görünürse, HTML cache’i bypass et.” Ziyaretçi sepete ürün atınca ya da sepet değişince, kenardaki kopya devre dışı kalır ve canlı içerik sunulur.
Uzun süreli oturum bilgisini taşıyan wp_woocommerce_session_ da pratik bir sinyal. Varsa büyük olasılıkla kişisel durum konuşuluyordur. Aynı şekilde WordPress giriş cookie’si olan wordpress_logged_in_, “Bu kullanıcı giriş yapmış” der. Bu iki aileyi gördüğünüzde, HTML cache’i devreden almak dertleri hafifletir. Yorum şablonu kişiye göre dolduruluyorsa comment_author_ ailesini de bypass edin. Önizleme ve şifreli içerik durumlarında ise wp-postpass_ ve URL’deki preview gibi izler, yine bypass için kullanışlıdır.
Cookie adlarını veya değişken sonekli ailelerini doğru eşleştirin; yalnız bir örnek oturumun tam cookie adına bağlanmayın. Bilinen WordPress/WooCommerce cookie’leri başlangıçtır; üyelik, para birimi, konum ve kişisel widget eklentilerini ayrıca inceleyin. Kimliği Authorization başlığıyla taşınan istekleri de bypass edin. Tüm CDN, Worker ve kaynak cache kurallarında bu istisnaların etkili olduğunu sınayın. Resmi WooCommerce cookie açıklamaları hangi cookie’nin hangi özelliğe bağlı olduğunu gösterir.
Örnek akışta, anonim ve kişiselleştirilmemiş bir katalog isteği ortak cache’den gelebilir. Ürünü sepete ekleyen istek, cookie henüz oluşmadan da eylem parametresi veya uç noktası nedeniyle bypass edilmelidir. Sonraki isteklerde sepet/oturum cookie’leri bypass sağlar. Yalnız yeni ziyaretçide cache isabeti görmek yeterli değildir; boş oturumdan sepete geçişi ve iki bağımsız müşterinin verilerinin ayrıldığını test edin.
Giriş yapan kullanıcılara saygı
wordpress_logged_in_ cookie ailesi bulunan HTML isteklerinde ortak sayfa cache’ini kapatın. Üyelik sitelerinde daha ileri optimizasyon için kişisel veriden tamamen arındırılmış ortak bir şablon ve ayrı yetkilendirilmiş dinamik parçalar tasarlanabilir. Kişisel parçaların yanıtı ve birleştirilmiş sonuç tekrar ortak cache’e yazılmamalıdır; bu, genel bir cookie istisnasını kaldırarak yapılacak küçük ayar değildir.
Edge Ayarları: Key, TTL, Query ve Mobil Ayrımı
Cache key, hangi isteklerin aynı kayıtlı yanıtı paylaşacağını belirler. Host, yol ve içeriği değiştiren dil, para birimi, sayfalama veya filtreler doğru ayrılmalıdır. Yalnız HTML’i, yönlendirmeyi veya başlıkları değiştirmediği doğrulanan izleme parametrelerini key’den çıkarın. Bilinmeyen parametreleri genel bir ignore kuralıyla birleştirmek yerine kapsam dışında bırakın veya etkilerini inceleyin.
HTML için TTL’yi kabul edilebilir fiyat, stok ve kampanya gecikmesine göre seçin. Düşük TTL ile başlayıp purge işlemlerini doğrulayın; örneğin 5–30 dakika yalnız tazeliği bu aralıkta kabul edilen genel içerikler için bir başlangıç olabilir. Kişisel yanıtlar süre ne kadar kısa olursa olsun kapsam dışıdır. Tarayıcı TTL’si ayrı yönetilir; CDN purge işlemi tarayıcıda saklanan yanıtı temizlemez.
add-to-cart ve diğer eylem parametrelerini key sadeleştirmesinden önce bypass edin. Sayfalama, arama, filtre, sıralama, dil ve para birimini yok saymak farklı içerikleri karıştırabilir. utm_source veya fbclid bile bir eklentide kampanya içeriği değiştiriyorsa etkisiz kabul edilemez. CDN’nin seçili parametreleri hariç tutma desteğini kontrol edin; bütün query string’i yok saymak aynı işlem değildir.
Cache key’i sadeleştirmek
Dil ve para birimi URL yoluyla ayrılıyorsa key bu yolları korumalıdır. Cookie, başlık veya konumla belirleniyorsa aynı belirleyiciler key’e doğru ve sınırlı varyantlar olarak yansıtılmalı ya da istek bypass edilmelidir. Vary başlığının her CDN’de bütün alanları otomatik ayıracağını varsaymayın. Mobil ve masaüstü aynı HTML’i alıyorsa yalnız responsive tasarım nedeniyle ayrı cache gerekmez.
UTM ve arkadaşlarına nazik bir selam
Bir izleme parametresini cache key’den çıkarmak, ziyaretçinin URL’sinden silmekle aynı değildir. Tarayıcı URL’si korunursa istemci tarafı analytics parametreyi okuyabilir; sunucu tarafı raporlama veya yönlendirme farklı davranabilir. Key sadeleştirmesinden sonra kampanya ölçümünü, canonical adresi ve yönlendirmeleri ayrıca test edin.
HTML Cache’i Isıtmak, Bozmak ve Onarmak: Günlük Hayattan Taktikler
Kampanya öncesi yalnız güvenli anonim sayfaları kontrollü hızla dolaşarak cache’i ısıtabilirsiniz. Sitemap’ten alınan her URL’nin otomatik olarak cache’e uygun olduğunu varsaymayın. Tek bir konumdan gelen istek bütün edge noktalarını ve dil/para birimi varyantlarını ısıtmaz; gereksiz paralellik kaynak sunucuyu yükleyebilir. Isıtmayı uygun URL listesi, hız sınırı ve ölçümle yapın.
Fiyat veya stok değişiminde ürünün yanı sıra onu gösteren kategori, anasayfa, ilgili ürün blokları ve dil/para birimi varyantları da etkilenebilir. Kaynak sayfa cache’i ile CDN purge akışını koordine edin; aksi halde CDN eski kaynaktan yeniden dolar. Menü/tema gibi geniş kapsamlı değişikliklerde daha geniş purge gerekebilir. Temizliğin tamamlandığını ve yeni yanıtı doğrulayın; purge anlık bir dünya çapı garantisi değildir.
Onarma anında ölçüm kıymetlidir. CDN yanıt başlıkları genellikle net ipuçları verir. Kenardan mı geldi, yoksa kaynaktan mı? Cache isabeti mi, ıskası mı? MISS yanıtı cache’e yazılabilir; tek bir MISS, bypass kanıtı değildir. HIT, BYPASS/DYNAMIC, Age ve kaynak cache başlıklarını tekrar eden isteklerde birlikte inceleyin. Ağ trafiğini izlemek ve yavaşlayan noktaları tespit etmek için tarayıcı geliştirici araçlarına beş dakikanızı ayırmak, çoğu zaman gününüzü kurtarır. Cloudflare’ın Cache Rules belgeleri burada pratik örneklerle eli güçlendiriyor; mantık başka CDN’lere de kolayca çevriliyor.
Staging ile güvenli prova
Staging’de iki bağımsız müşteri oturumu, temiz ziyaretçi ve giriş yapmış editörle test edin. Sepete ekleme/çıkarma, kupon, hesap, çıkış, önizleme, dil/para birimi ve ödeme dönüşlerini test ödeme yöntemiyle deneyin. Aynı URL’yi önce kişisel, sonra anonim oturumla ve ters sırayla açın. Gövdedeki veriyi, Set-Cookie ve cache başlıklarını karşılaştırın. Yanlış kişisel veri paylaşımı varsa ilgili HTML cache kuralını devre dışı bırakıp etkilenen kayıtları tüm katmanlarda temizleyin.
CDN’lerde Aynı Fikir: Kuralları Nasıl Çevirirsiniz?
Temel politika CDN’den bağımsızdır: yalnız incelenmiş kişisiz GET yanıtlarına HTML cache izni verin; diğer yöntemleri, kimlikli/oturumlu istekleri ve hassas yolları bypass edin. Kaynak yanıtında private, no-store veya Set-Cookie bulunması da depolamayı engellemelidir. Cloudflare Cache Rules’da aynı ayarı değiştiren son eşleşen kural kazanır; istisnaları sonraki geniş bir kuralın yeniden cache’e açmadığını kontrol edin. Worker veya başka cache katmanları ayrıca değerlendirilmelidir.
CDN ayar adları bire bir aynı davranış anlamına gelmez. Cloudflare’da key seçenekleri plana bağlıdır; CloudFront’ta pozitif Minimum TTL, kaynak private/no-store gönderse bile cache’i zorlayabilir. Kritik yollar için cache’i kapatan davranışlar kullanın; ortak yollardaki oturum istekleri için de açık bir bypass tasarımı gerekir. Cookie’yi key’e katmak tek başına bypass değildir. Fastly entegrasyon belgeleri ve Cloudflare cache belgeleri sağlayıcıya özgü ayarları değerlendirmek için başlangıçtır.
PHP-FPM, OPcache ve veritabanı iyileştirmeleri bypass edilen sayfalarda da önemlidir; WordPress sunucu optimizasyonu bu katmanı ele alır. Redis burada genellikle kaynak taraftaki kalıcı nesne önbelleğidir; kendiliğinden CDN edge katmanı değildir. Oturum ve geçersizleştirme davranışını kullanılan eklentiyle doğrulayın. Redis önbelleği rehberi sayfa önbelleğiyle farkını değerlendirmeye yardımcı olur.
Güvenlik, SEO ve Ölçüm: İnce Ayarların İnce Gülümsemesi
HSTS ve CSP gibi güvenlik başlıkları cache’den sunulan yanıtlarda da doğru olmalıdır. Özellikle CSP nonce’u kullanan şablonda başlık ve HTML’in aynı değeri taşıması gerekir; herkese ortak nonce dağıtan tasarım ayrıca incelenmelidir. HSTS kapsamındaki adlarda HTTPS hazır olmalıdır. Bu başlıkların varlığı tek başına SEO sıralama artışı veya güvenlik garantisi vermez.
Dil, para birimi ve cihaz varyantlarında yanlış HTML, canonical veya hreflang sunulmamasını kontrol edin. Cache key’de UTM bulundurmak depolama varyantı oluşturur; tek başına arama motorunda ayrı sayfa indekslendiği anlamına gelmez. Canonical ve tarama politikası ayrı konulardır. HTTP/3 ve CDN erişimi bazı bağlantılarda gecikmeyi azaltabilir; gerçek kullanıcı performansını ölçün ve sıralama garantisi çıkarmayın.
Ölçüm için basit bir çerçeve kurun. Trafiğin yoğun olduğu saatleri not alın, kenar isabet oranını gözlemleyin, sepet terk grafiğine hızlıca bakın. Kural değişimlerini küçük gruplar hâlinde yapıp birkaç saat izlemek, sorun anında geriye dönmeyi kolaylaştırır. Bazen çok küçük bir kural, büyük bir fark yaratır. Kayıtlarda artan time-to-first-byte değerini gördüğünüzde, hemen kenarı değil, arka plandaki sorguları da düşünün; her şeyin suçu cache değildir, bazen veritabanı ya da üçüncü taraf entegrasyonları temposunu kaybetmiştir.
Kapanış: Küçük Kurallar, Büyük Sükûnet
WooCommerce’de ortak HTML cache yalnız incelenmiş kişisiz yanıtlar içindir. Gerçek hassas yolları, eylem/API isteklerini, oturum cookie’lerini ve kimlikli istekleri bypass edin; kaynak gizlilik ve Set-Cookie başlıklarını zorla geçersiz kılmayın. Doğru key, kabul edilebilir TTL ve bağlantılı purge işlemleri tazeliği yönetir. İki bağımsız oturumla gövde ve başlık denetimi, yalnız cache isabet oranından daha önemlidir.
Pratik birkaç tavsiye bırakayım. Kuralları kademeli kurun, staging’de prova edin, canlıda ilk saatleri dikkatle izleyin. Purge işlemlerini cerrah gibi yapın; ne lazımsa onu temizleyin. Büyük değişiklikten sonra güvenli anonim sayfaları kontrollü biçimde ısıtın; bunun tüm edge noktalarını kapsamadığını hesaba katın. Sunucu tarafında OPcache, PHP-FPM ve veritabanına ufak dokunuşlar katın; CDN tek başına kahraman değildir. Güvenlik başlıklarını ihmal etmeyin; hızla güven bir arada ne güzeldir. İsterseniz arada şuna da göz atın: Cloudflare’ın cache yaklaşımı. Bu yazı umarım düğümleri yumuşatmıştır. Sorularınız olursa yazın; bir sonraki yazıda belki “kupon ve kampanya dönemlerinde CDN davranışı”nı konuşuruz. O zamana kadar, bol cache’li, az sürprizli günler.
