WordPress için CDN Önbellek Kuralları Nasıl Kurulur? WooCommerce’de HTML Cache, Bypass ve Edge Ayarlarıyla Uçtan Uca Hız

Geçen hafta bir müşterinin mağazasında enteresan bir gün yaşadım. Öğleden sonra trafik bir anda patladı, ürün sayfaları uçuyor ama kasaya gelince herkes bekliyor. Siparişler sepetten kaçıyor. Hani o “tam alacaktım ama sayfa dönüp durdu” anları… İşte bu küçük kriz bana şunu hatırlattı: WooCommerce’de CDN üzerinde HTML cache ciddi hız kazandırıyor, fakat bypass ve edge ayarları doğru değilse sepet davranışları çatallaşıyor. Kısacası, hız ve doğruluk arasında narin bir denge var.

Hiç başınıza geldi mi? Anasayfa ve blog yazıları jet hızında, ama ödeme adımında nefesler tutuluyor. O gün, CDN kural setini elden geçirdik: HTML cache’i doğru rotalara açtık, sepet ve ödeme adımlarını bypass ettik, edge tarafında akıllı bir TTL stratejisi kurduk. Sonuç mu? Hem hız geri geldi hem de sipariş adımları taş gibi oldu. Bu yazıda, WordPress ve WooCommerce için CDN önbellek kurallarını sohbet eder gibi, adım adım ve gerçek hayattan örneklerle anlatacağım. Mesela “hangi sayfa cache edilir, hangisi bypass edilir, cookie’lerle nasıl güvenli şerit çizilir, edge TTL nasıl ayarlanır” gibi sorulara sıcak bir yol tarifi çıkaracağız.

WooCommerce’de HTML Cache’i Neden Konuşuyoruz? Çünkü Sepetiniz Canlı Bir Organizma

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.

Benim denediğim güvenli yöntem şöyle akıyor: HTML cache’i cesur ama kontrollü açıyoruz. Katalog, ürün, kategori, blog, anasayfa gibi ziyaretçinin çoğunlukla okuduğu ve kişisel olmayan sayfalar CDN’de tutuluyor. Buna karşılık sepet, ödeme, hesap gibi kişisel ve canlı adımlar bypass ediliyor. Arada ise küçük ama etkili kurallar var; mesela “giriş yapmış kullanıcıları bypass et” veya “sepette ürün varsa cache’i kır”. Böylece motor gücü yükseliyor ama direksiyon hâlâ sizin elinizde kalıyor.

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. Hata payını düşürmek için de kural setini küçük adımlarla kurup gözlemlemeyi seviyorum; önce anasayfa, sonra kategori, ardından ürün sayfaları diye ilerlemek içime su serpiyor.

Ne Cache’lenir, Ne Bypass Edilir? WordPress Akışıyla Barışmak

Mesela şöyle düşünün: Sitenizin omurgasında üç tür trafik var. Birincisi herkesin görebileceği, pek kişiselleşmeyen alanlar. Anasayfa, blog yazıları, statik sayfalar ve çoğu kategori gibi. Bunları CDN üzerinde HTML cache ile rahatça tutabilirsiniz. İkincisi, yarı dinamik diyebileceğimiz ürün sayfaları. Stok ve fiyat değişebilir ama anlık kişisel bilgi göstermez; genelde kısa bir edge TTL ile güvenle hızlandırılır. Üçüncüsü ise sepet ve ödeme gibi birebir kişisel alanlar; burada bypass kırmızı çizgidir.

WordPress’in kendi akışında bypass etmeniz gereken rotalar aşağı yukarı benzerdir. /wp-admin/ ve /wp-login.php tartışmasız bypass olmalı. Önbellek burada sadece sorun çıkarır. WooCommerce tarafında ise /cart/, /checkout/, /my-account/ gibi rotaları önbelleğe atmayın; hatta “add-to-cart” gibi parametreli çağrıları da dinamik bırakın. Arama sonuçları, yorum gönderimleri ve önizleme URL’lerini de bypass etmek, yanlış içerik sunmayı engeller. Bu rotaları gruplandırıp tek seferde kural yazdığınızda yönetmesi daha kolay olur.

Bir not daha: Blog ve sayfa şablonları HTML cache ile muazzam hızlanır. Ancak yorum gönderildikten sonraki yönlendirme gibi anlık etkileşimlerde, kısa bir süre için kenarda bekleyen eski sayfa sunulabilir. Bu noktada ya kısa bir edge TTL tercih edin ya da yorum sonrası yönlendirmeyi dinamikte bırakın. Tercih site kültürüne ve içerik üretim hızınıza göre şekillenir. Yani tek bir doğru yok, ritminize uygun küçük ince ayarlar var.

WordPress’in sabit dosyalarıyla motoru rahatlatmak

Görseller, CSS, JS gibi statik dosyalar zaten CDN’in sevdiği lokmalar. Onlar için uzun bir TTL düşünebilirsiniz. Burada ince iş, HTML’i de katmak, yani “Cache Everything” tadında davranmaktır. Ama bu cümleyi her yerde uygulamaya kalkarsanız sepete çarparsınız; o yüzden hemen bir sonraki durak: kurallarla şerit çizmek.

WooCommerce’in hassas sayfalarında dikkat

Sepet, ödeme ve hesap. Bu üçlüde önbellek, sanki kırmızı ışık gibi. Kerpetenle bile açmıyorum. Çünkü kullanıcıya kişisel ve taze bilgi sunmak zorundayız. Burada temkinli davranarak hız kazancını katalog tarafında telafi etmek çok daha akıllıca. Bu sırada tarayıcı önbelleğini de abartmadan ayarlamak iyi geliyor; çünkü bazı butonlar ve doğrulama adımları tarayıcı tarafında hassas davranı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. Ö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 bazlı kuralları yazmak zor değil. Çoğu CDN ara yüzünde “bypass cache on cookie” gibi bir alan var. Oraya kısmi eşleşme ile cookie anahtarını yazıyorsunuz. Kimi zaman birden fazla koşulu “veya” ile bağlamak gerekiyor. Bunu kademeli kurmak iyi bir alışkanlık. Önce en yaygın olanları, sonra istisnaları eklemek, sorunları daha kolay izlemeyi sağlıyor. WooCommerce’in cookie mantığına dair resmi açıklamaları da aklınızın bir köşesinde dursun; ihtiyaç anında dönüp bakması kolay: WooCommerce cookie’lerinin açıklaması.

WooCommerce cookie’leriyle güvenli şerit çizmek

Mesela şöyle düşünün: Ziyaretçi anasayfaya geldi, hiç cookie yok veya sadece izleme parametreleri var. CDN kenarında sıcak bir kopya hazırsa, anında sunulur. Ardından ürün sayfasına girer, yine cache’den alır. Ürünü sepete eklediği anda cookie işaretleri ortaya çıkar. CDN, “tamam, artık bu kullanıcıya canlı akış göstermem gerek” der ve bypass’a düşer. Böylece hız ve doğruluk aynı anda korunur. Bu geçişlerin pürüzsüz olması, alışveriş deneyimini bambaşka bir seviyeye taşır.

Giriş yapan kullanıcılara saygı

Giriş yapmış herkesin deneyimi biriciktir. Favoriler, indirimler, dijital içerikler, profil bilgileri… O yüzden wordpress_logged_in_ tespit ettiğiniz anda HTML cache’tan uzak durmak, başınızı ağrıtmayan, temiz bir yoldur. Kimi projede üyelik alanı yoğun değilse, belirli sayfalar yine de cache edilebilir. Ama genel prensip, giriş cookie’si gördüğünüzde dinamik davranmaktır.

Edge Ayarları: Key, TTL, Query ve Mobil Ayrımı

Edge tarafı, küçük kelimelerle büyük farklar yarattığınız yer. Üç kavramı sade tutarsanız, çoğu senaryo pürüzsüz akar: cache key, TTL ve query ayarları. Cache key, kenardaki kopyayı tanımlayan imza gibidir. Alan adını, yolu ve gerekli gördüğünüz değişkenleri içerir. Ne kadar şişirirseniz, o kadar fazla varyant tutarsınız; gereksiz varyantlar cache’i parçalar. Bu yüzden çoğu sitede, utm gibi pazarlama parametrelerini cache key’den çıkarmak akıllıca olur. Böylece aynı sayfa, bin bir farklı “utm_campaign” ile gelmiş olsa da tek kopyada saklanır.

TTL’yi katmanlı düşünmek hoşuma gidiyor. Kenardaki HTML kopyası için kısa bir süre yeterli olurken, görseller ve stil dosyaları daha uzun süre saklanabilir. Ürün sayfalarında stok ve fiyatın nabzını tutabilmek için “çok uzun” olmayan bir edge TTL seçmek, tazeliği korur. Tarayıcı tarafındaki TTL ise ayrı bir lezzet; kullanıcı “geri” dediğinde sayfa anında gelsin isteyebilirsiniz ama bazı aksiyonlarda tarayıcı önbelleğini kıstığınızda daha az sürpriz yaşanır. Ritmi siz belirlersiniz.

Query dünyasında küçük temizlikler büyük rahatlama sağlar. utm_source, utm_medium, utm_campaign, fbclid gibi izleme parametrelerini cache key’den çıkarırsanız, kopyalar çoğalmaz. Buna karşılık add-to-cart gibi eylem taşıyan query’leri bypass’a gönderirseniz, yanlış bir şeyi cache’e hapsetmemiş olursunuz. Çoğu CDN, “query’leri yok say” ya da “sadece bazılarını dikkate al” gibi seçenekler sunuyor. Bu ayarları sade ve niyet odaklı tutmak, bakım maliyetinizi düşürür.

Cache key’i sadeleştirmek

Eğer dil veya para birimi değişkeni kullanıyorsanız, bu bilgiyi cache key’e dahil etmek gerekir. Aksi halde İngilizce içerik Türkçe sayfada görünür, fiyat birim karışır. Yani dil ve para birimi özelinde ayrı varyantlar yaratmak doğrudur. Ama pazarlama etiketlerini katarsanız, key bin parçaya bölünür. İnce denge burada, işlevsel değişkenleri seçip geri kalan detayları görmezden gelmektir.

UTM ve arkadaşlarına nazik bir selam

Performans tarafında minik bir kıvrım daha var: UTM’leri key’den çıkarırken, raporlama tarafında veriyi kaybetmiş olmazsınız. Zaten analytics yazılımı bu parametreleri okur. CDN sadece cache’i sadeleştirir. Bu da hoş bir kazan-kazan anıdır: Pazarlama mutlu, performans mutlu. Eğer teknik arayüzde “normalize query parameters” benzeri bir seçenek görürseniz, doğru yoldasınız.

HTML Cache’i Isıtmak, Bozmak ve Onarmak: Günlük Hayattan Taktikler

Canlıda en sevdiğim küçük ritüel “ısındırma”. Büyük kampanya öncesi, sitemap üzerinden anasayfa, kategori ve popüler ürünleri tek tek dolaştırıp kenardaki kopyaları tazeleyebilirsiniz. Böylece ilk dalgada herkes “soğuk başlangıç” beklemez. Önceden ısıtılmış bir cache, özellikle pik saatlerde adeta süspansiyon gibi sarsıntıyı alır. Eğer cron veya ufak bir script ile ısıtmayı otomatiğe bağlarsanız, günlük hayatınızda da iş yükünüz hafifler.

Bozma tarafında ise dikkat: Büyük tema güncellemesi, menü değişikliği veya fiyat güncellemesi sonrası purge sırasını planlı yapmak iyi gelir. “Her şeyi sil” bazen gereklidir ama çoğu zaman, ilgili yolları veya belirli kalıpları temizlemek yeter. Ürün detay tasarımlarını değiştirdiğinizde ürün yollarını, blog şablonlarını yenilediğinizde blog yollarını temizlemek; hem kenarı ferahlatır hem de gereksiz trafik üretmez.

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ı? Bu başlıklara göz ucuyla bakmayı öğrenmek, sorun çözme hızınızı ikiye katlar. 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

Kuralları canlıya taşımadan önce staging üzerinde prova yapmak, o küçük kalp çarpıntılarını söndürür. Staging alanında giriş yapmış kullanıcıyı taklit edin, sepete ürün atın, kupon deneyin, ödeme akışına kadar gidip geri dönün. Sonra CDN yanıtlarını izleyin: Nerede cache, nerede bypass devreye giriyor? İşte gerçek hayata en yakın prova budur. Bu provaları yaptıktan sonra canlıya geçerken, ilk saatlerde gözünüz yine de akışta olsun; her sitenin trafiği kendine özgüdür ve birkaç küçük düzeltme doğaldır.

CDN’lerde Aynı Fikir: Kuralları Nasıl Çevirirsiniz?

Farklı CDN’lerin arayüzü ve terimleri değişse de fikir değişmez. “HTML cache’i açık et ama hassas sayfaları ve hassas anları bypass et” cümlesi evrensel bir mottodur. Mesela bir CDN’de buna “Cache Everything + Bypass on Cookie” denir, bir diğerinde “Rule: Edge-Cache HTML; Condition: Cookie contains…”. Önemli olan, niyeti doğru anlatmaktır. Cookie tabanlı bypass, giriş ve sepet gibi kişisel durumlar için vazgeçilmezdir; URL tabanlı bypass ise wp-admin, login, checkout gibi rotalarda temel güvenceyi sağlar.

Edge TTL ve cache key ayarları da benzer biçimde çevirilebilir. Bir CDN’de “Ignore Query String” derseniz, diğerinde “Cache Key: host + path” seçersiniz. Yine birinde “Origin Cache Control” kabul edilirken, diğerinde “Override TTL” daha pratik olur. Kılavuzlara göz atmak iyi fikir. Örneğin Fastly’nin WordPress için önerileri ve Cloudflare’ın cache yaklaşımı sezgiyi hızla büyütür. Mantığı kaptığınızda, marka isimleri önemini yitirir, prensipler öne çıkar.

Sunucu tarafını da unutmayın. PHP-FPM, OPcache, veritabanı ayarları gibi parçalarla CDN’i aynı orkestrada çaldırınca, ses netleşir. Bu konuda adım adım bir yol arkadaşına ihtiyacınız olursa, WordPress için sunucu tarafı optimizasyon notlarını şöyle bir turlamak güzel olur. Kenarda Redis gibi bir katman daha kurup transient ve oturum verilerini sakinleştirmek de işe yarar; Redis ile sayfa dışı önbelleği tanıştırmak genelde tatlı sonuçlar doğurur.

Güvenlik, SEO ve Ölçüm: İnce Ayarların İnce Gülümsemesi

Güvenlik başlıkları HTML cache ile kavga etmez, hatta güzel anlaşır. Kenarda hızlanırken, tarayıcıya sağlam direktifler vermek iyi bir reflekstir. Örneğin HSTS ve CSP gibi HTTP güvenlik başlıklarını yerinde kullanmak, hem kullanıcının güvenini hem de arama motorlarının saygısını artırır. Bu başlıklar doğru ayarlanırsa, CDN üzerinden sunulan içerikte de sorun çıkarmaz. Sadece karma içerik ve varyantlar konusunda dikkatli olmak gerekir; HTTPS tutarlılığı esastır.

SEO tarafında en sık gördüğüm iki pürüz var: Dil/para birimi varyantları ve query parametreleri. Cache key’e dil ve para birimini katmadığınızda yanlış içerik sunabilirsiniz; öte yandan UTM’leri tutarsanız kopya çöplüğü oluşur. Bu iki ayarı yerli yerine koyduğunuzda, hem botlar hem insanlar mutlu olur. Bir de hızın sıralamaya dolaylı etkisi var; ağ katmanında HTTP/3’ün getirdiği daha akıcı aktarım ile CDN’in kenar dağıtımı birlikte çalıştığında, özellikle mobilde hissedilir bir akış elde edersiniz.

Ö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

Konuyu toparlayalım. WooCommerce’de HTML cache büyük bir hediye ama doğru paketlenmesi şart. Anasayfa, blog, kategori ve çoğu ürün sayfası kenarda huzurla tutulabilir. Buna karşılık sepet, ödeme ve hesap adımlarını cookie ve yol bazlı kurallarla bypass ettiğinizde, alışverişin kalbi doğru atar. Edge ayarlarında sade bir cache key, mantıklı bir TTL ve izleme query’lerini göz ardı etmek; performansla tazeliğin tatlı uzlaşmasıdır. Bu ufak prensipleri uyguladığınızda, kampanya saatlerinde bile panik butonuna uzanmazsınız.

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 önce cache’i ısıtın, sitemap’le popüler sayfaları tazeleyin. 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.