WordPress’te Tam Sayfa Önbellekleme Nasıl Kurulur? Nginx FastCGI Cache, Varnish ve LiteSpeed Cache ile WooCommerce’e Nazikçe Dokunmak

Bir Sabah, Yavaşlayan Bir Sepet ve Akla Düşen Önbellek

Hiç başınıza geldi mi? Trafik beklediğinizden biraz daha iyi gider, kampanya sayfası sosyal medyada minik bir rüzgâr yakalar ve derken WooCommerce sepeti ağırdan almaya başlar. O sabah bir müşterinin sitesi tam da böyle davranmıştı. Ana sayfa pırıl pırıl açılıyor, ama ürün detayına tıklayınca sanki sayfa, kahvesini bitirmeye çalışan birine dönüşüyordu. İşte o anda, tam sayfa önbelleklemenin aslında sadece hız değil, aynı zamanda nefes aldıran bir sessizlik olduğunu hatırladım. Sunucu uğultusu azalır, veritabanı derin bir oh çeker, kullanıcı da o beklediği butonun ışıldadığını görür.

Bu yazıda o sessizliğin üç farklı yolunu, yani Nginx FastCGI Cache, Varnish ve LiteSpeed Cache’i sakin sakin konuşacağız. Mesela şöyle düşünün; üçü de aynı filmi farklı projeksiyonla gösteren sinema salonları gibi. Film aynı, ama ışık ayarı, perdenin parlaklığı ve koltuğun konforu değişiyor. Önemli olan, WooCommerce sepeti ve ödeme gibi hassas anları asla donuk bir kareye çevirmeden, diğer her yerde akıcı bir deneyim sunmak. Ben de hem kendi sahada yaşadıklarımla, hem de sıklıkla kullandığım ayarlarla yola rehberlik etmek istiyorum. Hadi önce, tam sayfa önbelleği hissettirerek başlayalım.

Tam Sayfa Önbellek Nedir, Neden Hissedilir?

Basit bir dille söyleyeyim: Tam sayfa önbellek, dinamik olarak üretilen HTML’i, kısa bir süreliğine hazır bir fotoğraf gibi saklayıp tekrar kullanmak. Kullanıcı aynı sayfayı istediğinde, WordPress ve PHP yeniden yorulmak yerine, daha önce çizdiği tabloyu duvardan indirip gösteriyor. Aradaki fark, saniyelerin altına gizlenmiş o tatlı akış. Veritabanı daha az konuşur, PHP daha az terler, trafik dalgalansın, gündüz gece değişsin, site daha dingin görünür.

Elbette her sahne sabit kalamaz. Kullanıcı giriş yaptıysa, sepetinde bir şeyler varsa, ödeme adımındaysa, önbellek nazik davranmak zorunda. Bazen birkaç saniye, bazen birkaç dakika saklamak yeterli olur; kimi sayfalar daha uzun süre dayanır. Tam sayfa önbelleğin en güzel yanı, bu ince ayarı hem teknolojiye hem de alışveriş davranışına göre şekillendirebilmeniz. WooCommerce söz konusu olduğunda, sepet ve ödeme gibi yerleri daima canlı tutup, liste ve blog içeriklerinde cömert davranmak genelde yüz güldürür.

Nginx FastCGI Cache ile “Tereyağı gibi” Akış

Nginx ile çalışan bir sitede, FastCGI Cache çoğu zaman en sade ve pürüzsüz yol. Bir sabah geçiş yaptığım bir projede, sadece doğru bypass kurallarıyla, ürün listelemeleri ve blog içerikleri nefes aldı. Mesela şöyle düşünün: Nginx, PHP-FPM ile konuşurken üretilen cevabı bir kenara not ediyor. Aynı istek tekrar gelirse, not defterini açıp cevabı anında veriyor. Bu defterin sayfalarını ne kadar süre saklayacağınız ve hangi sayfaları asla yazmayacağınız, işin püf noktası.

WooCommerce için doğru bypass ve TTL

WooCommerce’de önbelleğe nazik davranmanız gereken yerler hep benzer olur. Sepet, ödeme, hesap ve giriş adımları kesinlikle canlı kalmalı. Bunun için cookie’lere kulak verirsiniz: woocommerce_items_in_cart, wp_woocommerce_session_ ve kullanıcı girişini anlatan wordpress_logged_in_ gibi işaretler, Nginx’e “Bu isteği kopyalama” demenin pratik yolu. TTL tarafında, ana sayfa ve kategori sayfaları için dakikalarla, hatta bazen daha uzun sürelerle rahat davranabilirsiniz. Ürün sayfalarında stok ve fiyat güncellemelerinin sıklığına bakıp karar verin; hızlı değişiyorsa kısa, sabitse daha uzun.

Benim sık kullandığım yaklaşım, “stale” dediğimiz bayat ama işe yarar kopyaları da devreye almak. Böylece PHP kısa süreli bir yorgunluk yaşarsa, Nginx elindeki eski ama kullanışlı kopyayı anında döner, arka planda tazelenmek için de mutfağa haber verir. Kullanıcı gecikmeyi hissetmez. Bu küçük jest, yoğun saatlerde harikalar yaratır.

Temizlik ve geçersiz kılma alışkanlıkları

Önbelleğe alınan sayfaların gerektiğinde hızla temizlenmesi kritik. WooCommerce’de bir ürünün fiyatını güncellediğinizde, ilgili ürün sayfasının ve belki kategorisinin tazelenmesi gerekir. Nginx’in kendisinde dahili bir “purge” API yok ama cache_purge modülü ya da uygulama tarafında dosya temelli temizlik yöntemleri iş görür. Ben çoğu zaman yayınlama, güncelleme ve silme gibi olaylar tetiklendiğinde basit bir temizleme iş akışı kuruyorum. Tek bir ürün değiştiğinde tüm mağazayı uçurmak yerine, ilgili URL’leri hedef almak işleri çok daha tutarlı hale getiriyor.

Tecrübeyle sabit bir detay daha var: UTM gibi izleme parametreleri cache anahtarını şişirip gereksiz varyantlar üretmesin. utm_source, utm_medium, gclid gibi parametreleri 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.

Teknik referanslara göz atmak isterseniz, Nginx FastCGI Cache dokümantasyonu temel kavramları kısa ve anlaşılır bir dille toparlıyor. Oradaki direktif isimleri gözünüzü korkutmasın; pratikte az ama öz bir setle çoğu ihtiyacı karşılayabilirsiniz.

Varnish ile Araya Giren Hız

Varnish’i ilk koyduğum projede hissettiğim şey şuydu: Sanki kapının girişine deneyimli bir görevli gelmiş, “Şu grup direkt içeri, şu grup beklemesin, şurada kısa yol var” demiş gibi. Varnish, web sunucusunun önünde bir katman gibi duruyor ve HTTP düzeyinde akışı düzenliyor. WordPress ve WooCommerce ile güzel geçiniyor; yeter ki ona, “sepete dokunma, ödeme akışına karışma, giriş yapmış kullanıcıya saygı” diye fısıldayın.

WordPress ve WooCommerce’i incitmeden VCL kurgusu

Varnish’te işin kalbi VCL dediğimiz küçük kurallar. İlk dokunuş her zaman cookie ve URL üzerinden gelir. wp-admin ve wp-login.php gibi yollar zaten güvenli bölge; asla cache’lenmez. WooCommerce için ise cart, checkout ve my-account gibi sayfaları canlı tutarsınız. woocommerce_items_in_cart ya da wp_woocommerce_session_ gibi cookie’leri görünce, “Bu istek anlık olmalı” dersiniz. Geri kalan sayfalarda ise TTL’i, sitenin güncellenme ritmine göre ayarlarsınız. Blog ve kategori sayfaları uzun nefesli olur, ürün sayfaları tutumlu davranır. Araya giren varyantlar için, gereksiz query parametrelerini temizlemek yine hayat kurtarır.

Bir detay daha: Varnish SSL konuşmaz, genellikle ya ters proxy arkasında durur ya da TLS’i terminatör bir katmandan alır. Nginx veya bir CDN önde TLS açar, Varnish arkasında şimşek hızında çalışır. Bu kurulumda X-Forwarded-Proto gibi başlıkların doğru aktarıldığından emin olun ki, WordPress HTTP/HTTPS konusunda kararsız kalmasın.

Purge mi BAN mı? Gerçekte hangisini kullanırsın

Gerçek hayatta, tek tek URL temizlemek için purge, daha geniş desenler için BAN pratik oluyor. Bir ürün güncellendiğinde o ürünün URL’sini anında temizlemek hızlı sonuç verir. Kategori ve benzeri geniş kapsamlı alanlar içinse, desen bazlı bir BAN kuralı akıllıca. Üretim ortamında güvenlik sebebiyle purge/BAN’ı yalnızca yetkili IP’lere açmak ve uygulamadan imzalı bir çağrı yapmak sağduyulu bir tercih. Varnish dokümantasyonunda bu akış net biçimde anlatılıyor. Bir iki kez kurcaladıktan sonra eliniz alışıyor ve sanki trafik dalgalarını bir sörf tahtasıyla yönetiyormuş gibi rahatlıyorsunuz.

LiteSpeed Cache: Eklentiyle Gelen Akıllı Kısayollar

LiteSpeed dünyasında işler biraz daha kullanıcı dostu bir pencereden bakıyor. Web sunucusu LSWS ya da OpenLiteSpeed olduğunda, WordPress eklentisiyle gelen LiteSpeed Cache gerçekten pratik bir kumanda gibi. Giriş ekranından itibaren bir sürü iyi varsayılanla geliyor; tabii WooCommerce’e saygı göstermek yine sizin elinizde. LiteSpeed’in hoş sürprizi ise ESI denilen parçalanmış cache yaklaşımı. Sayfanın büyük kısmını cache’leyip, sepet ve “Merhaba, Ahmet!” gibi kişisel alanları canlı tutarak iki dünyanın en iyisini bir araya getiriyor.

ESI ile sepet ve kullanıcı alanlarını ayrı tutmak

ESI’yi ilk kez açtığımda hissettiğim şey, Lego ile oynarken minik parçaları istediğim gibi söküp takmak gibiydi. Ana gövde aynı kalıyor, küçük kişisel blokları ise anlık üretiyorsunuz. WooCommerce sepet, mini sepet, hesap alanları bu modele çok yakışıyor. Bu sayede ana sayfa ve kategori akışları ışık hızında olurken, kullanıcıya özel kısımlar her zaman taze kalıyor. LiteSpeed panelinde bu alanlar için ESI’yi aktif edip, TTL ve varyant tercihlerini ince ayarlamak yeterli.

Uyumlu WooCommerce ayarları

LiteSpeed Cache eklentisi WooCommerce’i tanıyor; sepet, ödeme ve hesap sayfalarını otomatik olarak canlı bırakma eğiliminde. Yine de kontrol iyidir. Giriş yapmış kullanıcılarda tam sayfa cache’i dikkatli kullanmak, dinamik fiyatlandırma ve özel kampanyalar varsa varyasyonları sınırlandırmak iyi sonuç verir. Mobil ve masaüstü aynı HTML’i üretiyorsa tek varyantla yürümek sadeleştirir. AMP, çok dilli altyapılar ve para birimi değişimi kullanıyorsanız, her birinin sayfayı nasıl etkilediğini test ederek karar vermek gerekir. Eklentinin ayarlarını karıştırırken dokümanlara göz atmak isterseniz, LiteSpeed Cache for WordPress belgeleri pek çok örneği hafif bir dille anlatıyor.

CDN, Nesne Önbelleği ve Diğer Dostlarla Uyum

Tam sayfa önbellek tek başına kahramanlık yapabilir ama yanına doğru arkadaşları alırsa hikâye büyür. CDN, statik dosyaları edge noktalara götürür; bazen HTML’i de sınırda saklamak istersiniz. Orada da önbelleğin mantığı aynı: Sepet ve ödeme canlı kalır, geri kalan sahneler rahatça saklanır. Yüzünüzü bir CDN’e dönecekseniz, WordPress için CDN önbellek kuralları ve WooCommerce’de HTML cache bypass üzerine hazırladığımız rehber, uçtan uca akışı netleştirmenize yardımcı olur.

Nesne önbelleği ise ayrı bir tatlılık. Redis veya Memcached ile veritabanına yapılan tekrar eden sorgular anı defterine yazılır. Tam sayfa cache’in olmadığı anlarda bile performans hissedilir. Bir projede tam sayfa cache’i kısa TTL’lerle tutarken, Redis’in sağladığı sorgu hızını arka planda sabit kılmıştık; trafik dalgalanınca bile sayfalar eprimiş hissettirmedi. Bu iki yaklaşım çatışmaz, aksine uyumla yürür. Tam sayfa önbellek büyük resmi saklarken, nesne önbelleği ayrıntıları düzenler.

CDN kullanırken dikkat ettiğim bir başka detay, sitenin HTTP başlıklarını temiz tutmak. Cache-Control, Expires ve varyantla ilgili başlıklar açık konuşursa, katmanlar arası yanlış anlaşılmalar az olur. Varnish, Nginx ve LiteSpeed tarafında attığınız etiketlerin CDN’de nasıl yorumlandığını küçük bir testle görmek büyük fark yaratır.

WooCommerce-Uyumlu Ayar Rehberi: Birlikte Not Alalım

Şimdi gelin, pratik bir çizelge gibi ama cümlelerin akışında notlarımızı toplayalım. Sepet, ödeme, hesap ve giriş sayfaları canlı kalsın; bu sayfalarda önbelleğe hiç bulaşmayın. Kullanıcı girişini, sepet durumunu ve oturum bilgisini anlatan cookie’ler görüldüğünde önbelleği bypass edin. Ürün ve kategori sayfalarında TTL’i, stok ve fiyat güncelleme ritminize göre ayarlayın; sık değişenlerde kısa, durağanlarda uzun süreler rahatlatır. Blog ve statik sayfalar çoğu projede cömert TTL’i kaldırır.

UTM ve izleme amaçlı parametreleri yok sayın ki gereksiz varyantlar oluşmasın. Arama sonuçları ve filtreli URL’lerin politikasını netleştirin; bazı mağazalarda çok farklı HTML üretilmediği sürece, kısa TTL ve akıllı parametre temizliği iyi sonuç verir. Admin çubuğu ve yönetim alanı zaten canlı kalmalı; giriş yapmış editörler için gerekiyorsa cache’i dikkatle sınırlayın. Web kancalarıyla yayınlama ve ürün güncellemede nokta atışı purge yapın; tüm mağazayı temizlemek yerine ilgili URL’leri hedefleyin. Mobil ve masaüstü aynı HTML’i üretiyorsa tek bir cache anahtarıyla sade kalın; gerçekten farklı bir tema çıkarıyorsanız o zaman çoğaltmayı düşünün.

Güvenlik tarafında, purge veya temizlik uç noktalarını sadece yetkili IP’lere ve imzalı çağrılara açın. wp-cron ve webhook süreçlerinde kısa süreli canlı davranmak beklenmedik gecikmeleri azaltır. CDN kullanıyorsanız, HTML’i de edge’te saklayacaksanız yine sepet ve ödeme alanlarını bypass ettiğinizden emin olun. Ölçümü unutmayın; her değişikliğin ardından ön ve arka uç gecikmesini, first byte süresini ve hata oranlarını birkaç gün izlemek, sessiz hataları konuşur hale getirir.

Hangi Yol, Hangi Gün? Günlük Hayattan Senaryolar

Bir dostumun tek sunuculu, PHP-FPM’li bir WooCommerce mağazası vardı. Trafik orta karar, gün içi dinamikleri tahmin edilebilir. O projede Nginx FastCGI Cache adeta bir Swiss çakısı gibi iş gördü. Basit bypass kuralları, kısa bir temizlik iş akışı ve bayat içeriği kibarca sunma yaklaşımıyla, geceleri bakım yaparken bile site derin bir oh çekti. Bir başka müşteride ise katmanlı bir yapı vardı; önde bir TLS sonlandırıcı, arkasında Varnish, sonra uygulama. Burada Varnish’in BAN/purge mekanizması çok yakıştı; trafik piklerinde adeta bir hava kontrol kulesi gibi akışı düzenledi.

LiteSpeed ile tanıştığım bir içerik ağı da oldu. WooCommerce daha küçük bir alan kaplıyordu, ama kişiselleştirme boldu. ESI ile sepet ve kullanıcı alanlarını canlı tutup, geri kalan her yeri uzun TTL’lerle saklayınca, sayfalar göz açıp kapayıncaya kadar açılmaya başladı. Ekip, panelden ayarları yönetmenin konforuna bayıldı. Bu üç yaklaşımın ortak noktası şu: Mağazanın kalbini, yani sepet ve ödemeyi her zaman canlı tutuyor, geri kalan sahnelerde ise cömertçe saklama yapıyorsunuz. Farklılıkları ise alışkanlıklara ve mimarinize daha çok hitap ediyor.

Ölçüm, Gözlem ve Küçük İpuçları

Önbellek konuşurken ölçmeden adım atmayın. Sade bir curl -I ile gelen başlıkları izleyin; hit mi miss mi, kaç saniyedir saklı, hangi katman cevap verdi, bunlar netleşsin. Sunucu tarafında kısa bir günlüğe hit/miss oranlarını yazdırmak, değişikliklerden sonra doğru yolda olup olmadığınızı açıkça gösterir. Bir projede, sadece UTM parametrelerini temizleyerek miss oranını dramatik biçimde düşürdüğümü hatırlıyorum; site nefes aldı, veritabanı CPU’su düşüp stabil hale geldi.

Staging ortamı, canlı hayatın küçük bir provası gibi. Yeni kural, yeni TTL, yeni CDN davranışı… Ne varsa önce orada denerim. Özellikle mobil deneyimi atlamam; bazı temalar mobilde beklenmedik AJAX çağrıları yapar ve bu çağrılar sepeti etkiler. Gözle takip, ufak loglar, birkaç kullanıcı akışı testi derken, üretime geçtiğinizde sürpriz sayısı azalır.

Bu arada belgeler bazen can kurtarır. Varnish ve Nginx’te ufak bir ayrıntının neyi tetiklediğini anlamak için resmi sayfaları kısa bir tur ziyaret ederim. LiteSpeed tarafında da eklentinin sürüm notları ve best practice önerileri, gizli hazineler barındırır. İlgilenenler için tekrar bırakayım: Nginx FastCGI Cache, Varnish Belgeleri ve LiteSpeed Cache eklenti dökümantasyonu ellerinizin altında dursun.

Kapanış: Hızlı ama Nazik Bir WordPress

Toparlayalım. Tam sayfa önbellek, WordPress ve WooCommerce dünyasında hem sakinlik hem de çeviklik demek. Nginx FastCGI Cache pratik ve hafif bir dokunuş sunuyor; Varnish isteği karşılamadan önce akışı düzenliyor; LiteSpeed Cache ise eklenti konforuyla güç veriyor. Üçünde de değişmeyen kural, sepet ve ödeme gibi hassas alanlarda canlılığı korumak, geri kalan her yerde saklama cömertliğini dozunda artırmak. TTL’leri, cookie bypass’larını ve temizleme alışkanlıklarını kendi mağazanızın ritmine göre ayarladığınızda, site bir anda üzerindeki ağırlığı atıyor.

Pratik bir tavsiye seti bırakayım: Küçükten başlayın, her adımı ölçün, işe yarayan ayarları kalıcılaştırın. UTM parametrelerini temizleyin, giriş yapmış kullanıcıya hassas davranın, ürün güncellemelerinde yalnızca ilgili sayfaları tazeleyin. CDN kullanıyorsanız, HTML cache kurallarını WooCommerce’e saygılı biçimde kurgulayın; sepet ve ödemeyi her zaman baypas edin. Umarım bu yazı, önbelleği bir tuş gibi değil de, birlikte çalan bir orkestranın şefi gibi görmenize yardım etmiştir. Takıldığınız yerde bir kahve molası kadar yakın olduğumu bilin; bir dahaki yazıda görüşmek üzere.