W3 Total Cache Ayarlari ile WordPress Hizlandirma

WordPress her sayfa isteğinde arka planda küçük bir yazılım çalıştırır: PHP kodu yürütülür, veritabanına onlarca sorgu gönderilir ve sonuç HTML olarak birleştirilip ziyaretçiye iletilir. Bu döngü tek bir ziyaretçi için milisaniyelerle ölçülür, ama aynı anda yüzlerce kişi geldiğinde sunucu aynı işi tekrar tekrar yaparak boğulmaya başlar. Önbellekleme (caching) tam da bu israfı ortadan kaldırır: bir kez üretilen çıktıyı saklar, sonraki ziyaretçilere hazır dosyadan servis eder. W3 Total Cache, bunu WordPress tarafında yapan en köklü ve en kapsamlı ücretsiz eklentilerden biridir.

Bu rehberde eklentinin dört ana modülünü — Page Cache, Minify, Object Cache ve Browser Cache — tek tek ele alıp hangi ayarın ne işe yaradığını, nerede risk taşıdığını ve gerçek bir sitede nasıl yapılandırılması gerektiğini anlatacağız. W3TC güçlü olduğu kadar geniş bir eklentidir; yanlış işaretlenen tek bir kutu sayfanızın bozuk görünmesine ya da tümüyle beyaz kalmasına yol açabilir. O yüzden her adımı "neden" sorusuyla birlikte işleyeceğiz ki kendi sitenizde hangi seçeneği açıp hangisini kapalı tutacağınıza bilinçli karar verebilesiniz.

W3 Total Cache Nedir ve Ne İşe Yarar?#

W3 Total Cache (kısaca W3TC), WordPress'in ürettiği çıktının farklı katmanlarını önbelleğe alan bir performans eklentisidir. Tek bir işi değil, birbirini tamamlayan birkaç işi aynı çatı altında yapar: hazır HTML sayfaları saklar, CSS ve JavaScript dosyalarını küçültüp birleştirir, veritabanı sorgularının sonuçlarını bellekte tutar ve tarayıcıya "bu dosyaları tekrar indirme, sende zaten var" talimatını verir.

Bu modülleri bir katman yığını gibi düşünebilirsiniz. En üstte ziyaretçinin tarayıcısı, en altta veritabanı vardır; W3TC her katmanda gereksiz tekrarı keser:

Buradaki en önemli nokta şudur: modüllerin hepsini aynı anda açmak zorunda değilsiniz ve açmamalısınız da. Etkisi en yüksek, riski en düşük olan Page Cache ile başlanır; diğerleri site test edilerek kademeli devreye alınır. WordPress'i genel olarak hızlandırma stratejisini de ayrıca WordPress hız optimizasyonu rehberimizde 12 başlık altında ele almıştık; bu yazı ise özellikle W3TC yapılandırmasına odaklanıyor.

Kuruluma Başlamadan Önce: Yedek ve Test Ortamı#

Önbellekleme eklentileri, siteyi hızlandırdıkları kadar bozma potansiyeli de taşır. Sebebi basit: bir ziyaretçinin gördüğü sayfa artık "canlı" değil, saklanmış bir kopyadır. Yanlış yapılandırırsanız kullanıcılar eski fiyatları, boş sepetleri ya da CSS'i yüklenmemiş kırık bir tasarımı görebilir. Bu yüzden ilk kural, ayar denemelerini asla canlı sitede körlemesine yapmamaktır.

En güvenli yol bir hazırlık (staging) ortamında çalışmaktır. Çoğu kaliteli hosting paneli tek tıkla staging klonu oluşturmanıza izin verir; kopyada tüm ayarları deneyip sonucu doğruladıktan sonra canlıya taşırsınız. Konuya yabancıysanız WordPress staging ortamı mantığı, canlı siteyi riske atmadan test yapmanın standart yöntemidir. Bir staging ortamınız yoksa en azından tam bir yedek almadan hiçbir kutuyu değiştirmeyin.

Komut satırına erişiminiz varsa dosya ve veritabanının hızlı bir yedeğini şöyle alabilirsiniz:

# Site dosyalarını sıkıştır
tar -czf site-yedek-$(date +%F).tar.gz /home/kullanici/public_html

# Veritabanını dışa aktar
mysqldump -u db_kullanici -p wp_veritabani > wp-yedek-$(date +%F).sql

Otomatik ve düzenli yedekleme kurmak isterseniz yedekleme hizmetimiz bu işi sizin adınıza planlar. Bir şeyler ters giderse eklentiyi devre dışı bırakmak çoğunlukla yeterli olur; en kötü senaryoda wp-content/cache klasörünü ve wp-config.php içine W3TC'nin eklediği satırları temizleyerek temiz sayfaya dönersiniz.

Page Cache (Sayfa Önbelleği) Ayarları#

Page Cache, W3TC'nin kalbidir ve tek başına en büyük hızlanmayı sağlayan modüldür. Açtığınızda WordPress bir sayfayı ilk ziyaretçi için normal şekilde üretir, ardından çıktının tamamını hazır bir dosya olarak saklar. Sonraki her ziyaretçi PHP hiç çalıştırılmadan, veritabanına hiç dokunulmadan bu hazır dosyayı alır. Sunucu yükü ve yanıt süresi çoğu zaman kat kat düşer.

Yapılandırma sayfasında karşınıza çıkacak ilk seçim önbellekleme yöntemidir. Paylaşımlı hosting'de en uyumlu ve en garantili seçenek Disk: Enhanced modudur. Bu mod, önbelleklenen HTML'i doğrudan diskteki .html dosyalarına yazar ve sunucunun web katmanı (Apache .htaccess ya da Nginx kuralı) bu dosyayı PHP'yi hiç başlatmadan servis eder. Kendi sunucunuz veya VDS'iniz varsa ve Redis/Memcached kuruluysa bellek tabanlı seçenekler daha da hızlıdır; buna bir sonraki bölümde döneceğiz.

Page Cache'te dikkat etmeniz gereken pratik ayarlar şunlardır:

• Cache front page / feeds / SSL requests: Ana sayfa ve HTTPS istekleri işaretli kalmalı; bugün neredeyse tüm siteler SSL kullandığı için SSL önbelleği kapalıysa hiçbir şey önbelleğe girmez.
• Don't cache pages for logged in users: İşaretli bırakın. Giriş yapmış kullanıcılara kişisel içerik (yönetici çubuğu, hesap bilgileri) gösterildiği için onlara önbellek servis etmek karışıklık yaratır.
• Cache 404 pages: Kapalı tutmak genelde daha güvenlidir.
• Never cache the following pages: Burası kritiktir. Dinamik sayfaları mutlaka istisna listesine ekleyin.

E-ticaret veya üyelik sitesi işletiyorsanız sepet, ödeme ve hesap sayfalarını önbelleğin dışında tutmak zorunludur; aksi halde bir müşteri başka birinin sepetini görebilir. İstisna kutusuna şu kalıpları eklemek iyi bir başlangıçtır:

; Asla önbelleğe alınmayacak sayfalar (her satır bir kural)
/cart/
/checkout/
/my-account/
/wp-admin/
/*\?add-to-cart=*

WooCommerce ile başlıyorsanız bu istisnaları en baştan tanımlamak, sonradan "sepet çalışmıyor" hatasıyla uğraşmaktan çok daha kolaydır; mağaza kurulumunun genel adımlarını WordPress eklenti önerileri yazımızdaki performans bölümünde de bulabilirsiniz.

Minify (Küçültme) Modülü ve Riskleri#

Minify modülü, CSS ve JavaScript dosyalarındaki gereksiz boşlukları, satır sonlarını ve yorumları atarak dosya boyutunu düşürür; ayrıca birçok küçük dosyayı tek bir büyük dosyada birleştirerek tarayıcının açması gereken bağlantı sayısını azaltır. Kâğıt üzerinde harika görünür, ama pratikte W3TC'nin en çok site bozan modülü budur.

Sorun şudur: tema ve eklentilerin ürettiği JavaScript dosyaları belirli bir yüklenme sırasına ve birbirine bağımlıdır. Minify bu dosyaları yanlış sırada birleştirirse kayan menüler, slider'lar, form doğrulamaları ya da tüm sayfa aniden çalışmayı durdurabilir. Bu yüzden minify'ı en son ve teker teker açın.

Uygulamada işe yarayan yaklaşım şudur:

• Minify modunu önce Auto yerine Manual yapıp sadece CSS küçültmeyi açın. CSS birleştirme, JS'e göre çok daha az sorun çıkarır.
• Siteyi masaüstünde ve mobilde, mümkünse birden fazla tarayıcıda dolaşarak görsel olarak test edin: menüler açılıyor mu, formlar gönderiliyor mu, slider dönüyor mu?
• Her şey yolundaysa JS küçültmeyi ekleyin, ama JS "combine" (birleştirme) seçeneğini temkinli açın. Sorun çıkaran belirli dosyaları birleştirme dışında bırakabilirsiniz.
• Tarayıcının geliştirici konsolunu (F12) açık tutun; kırmızı JavaScript hataları minify kaynaklı bir çakışmanın en net işaretidir.

Uyarı: Sitenizin önünde Cloudflare gibi bir CDN veya bir optimizasyon eklentisi (ör. otomatik minify yapan başka bir araç) varsa aynı işi iki kez yaptırmayın. Çift minify, dosyaların bozulmasının en sık nedenlerindendir. Ya CDN tarafında ya W3TC tarafında minify yapın, ikisinde birden değil.

Minify'ın verdiği kazanç genellikle Page Cache kadar büyük değildir. Eğer siteniz minify açıkken en ufak bir gariplik gösteriyorsa, birkaç kilobayt uğruna görsel bir bozulmayı göze almaktansa modülü kapalı bırakmak çoğu zaman daha akıllıca bir karardır.

Object Cache: Disk mi Redis/Memcached mi?#

Object Cache, WordPress'in aynı sayfa üretimi sırasında tekrar tekrar sorduğu veritabanı sonuçlarını (ayarlar, menüler, kullanıcı bilgileri, terim ilişkileri) geçici olarak saklar. Page Cache tam sayfayı önbelleğe alırken, Object Cache özellikle giriş yapmış kullanıcılar ve önbelleğe alınamayan dinamik sayfalar için MySQL yükünü azaltır. Bu yüzden WooCommerce ve üyelik siteleri için değeri yüksektir.

Buradaki en önemli karar, önbelleğin nerede tutulacağıdır. İki yol vardır:

Genel kural nettir: Object Cache için Disk'i tercih etmeyin. Paylaşımlı hosting'in disk katmanı bu iş için genellikle yavaştır ve on binlerce küçük önbellek dosyası inode limitinizi tüketebilir. Object Cache gerçek faydayı ancak Redis veya Memcached gibi bir bellek deposuyla verir; RAM'den okuma, diskten okumaya göre kat kat hızlıdır.

Kendi sunucunuz varsa Redis kurulumu birkaç komuttur:

# Ubuntu/Debian üzerinde Redis kurulumu
sudo apt update && sudo apt install redis-server -y
sudo systemctl enable --now redis-server

# PHP'nin Redis ile konuşması için eklenti
sudo apt install php-redis -y
sudo systemctl restart php8.2-fpm

Kurulumdan sonra W3TC'de Object Cache yöntemini Redis olarak seçip bağlantı testini yaparsınız. Bellek tabanlı önbellek, yoğun WordPress kurulumlarında en somut hızlanmayı sağlayan adımlardan biridir. Paylaşımlı pakette Redis yoksa, size ayrılmış kaynaklara sahip bir VDS sunucu ya da yönetimiyle uğraşmak istemiyorsanız sunucu yönetimi hizmetimiz bu kurulumu sizin için yapar.

Database Cache modülü de benzer mantıkla çalışır ama ham SQL sorgularını önbelleğe alır. Object Cache'i Redis ile açtıysanız Database Cache'i genellikle kapalı bırakmak daha temizdir; ikisi çakışıp beklenmedik davranışlara yol açabilir. Emin değilseniz Database Cache'e dokunmayın.

Browser Cache (Tarayıcı Önbelleği) Ayarları#

Browser Cache modülü sunucuya değil, ziyaretçinin tarayıcısına konuşur. Statik dosyalar (resimler, fontlar, CSS ve JS) sayfadan sayfaya değişmez; bir kez indirildikten sonra tekrar indirilmelerine gerek yoktur. Bu modül, tarayıcıya "bu dosyayı bir süre saklayabilirsin" diyen HTTP başlıklarını (Expires, Cache-Control, ETag) ekler. Böylece geri dönen ziyaretçi için sayfa neredeyse anında açılır.

Bu modül dört modül içinde riski en düşük olanıdır; çoğu sitede güvenle tam açılabilir. İşaretlenmesi önerilen ana seçenekler:

• Set expires header: Statik dosyalara uzun bir geçerlilik süresi verir (genelde bir yıl).
• Set cache control header: public, max-age başlığıyla ara katman/CDN önbelleklerinin de dosyayı saklamasına izin verir.
• Enable HTTP (gzip) compression: Metin tabanlı dosyaları sıkıştırarak boyutlarını ciddi ölçüde küçültür.

Uzun süreli önbellekle ilgili klasik endişe şudur: "Dosyayı güncellersem ziyaretçi hâlâ eskisini görmez mi?" W3TC bunu cache busting ile çözer; dosya adına bir sürüm damgası ekleyerek (style.css?x=...) her güncellemede tarayıcının yeni dosyayı indirmesini sağlar. Bu davranış varsayılan olarak devrededir, o yüzden uzun süreleri gönül rahatlığıyla kullanabilirsiniz.

Sunucunuza doğrudan erişiminiz varsa aynı başlıkları eklenti olmadan da tanımlayabilirsiniz. Nginx için tipik bir kural şöyledir:

location ~* \.(jpg|jpeg|png|gif|webp|svg|css|js|woff2|ttf)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

CDN Entegrasyonu#

CDN (İçerik Dağıtım Ağı), sitenizin statik dosyalarını dünyanın farklı noktalarındaki sunuculara kopyalar; ziyaretçi dosyayı fiziksel olarak kendisine en yakın noktadan alır. W3TC'nin CDN sekmesi, statik dosya bağlantılarını otomatik olarak CDN adresinizle değiştirir.

Burada iki farklı senaryoyu ayırmak gerekir. Cloudflare gibi reverse proxy tarzı bir CDN kullanıyorsanız, aslında W3TC'nin CDN modülünü ayrı yapılandırmanıza gerek yoktur; trafik zaten Cloudflare üzerinden geçtiği için dosyalar oradan önbelleklenir. Bu durumda W3TC'de CDN türünü "Generic Mirror" seçip yalnızca önbellek temizleme entegrasyonunu kurmak yeterlidir. Buna karşılık pull/push zone mantığıyla çalışan (dosyaların ayrı bir alt alan adından servis edildiği) bir CDN kullanıyorsanız, CNAME adresini W3TC'nin CDN alanına girersiniz.

Tipik bir pull-zone kurulumunda DNS tarafında bir CNAME kaydı oluşturursunuz:

cdn.siteadi.com.   IN   CNAME   siteadi.b-cdn.example.net.

CDN entegrasyonunun en sık takıldığı nokta font ve CORS sorunlarıdır: fontlar farklı bir alan adından (CDN) yüklendiğinde tarayıcı güvenlik gereği bunları engelleyebilir. Bu durumda CDN panelinizde Access-Control-Allow-Origin başlığını açmanız gerekir. Ayrıca minify'ı hem W3TC'de hem CDN'de açmayın; bu bölümün başında değindiğimiz çift işlem sorunu burada da geçerlidir.

Önerilen Başlangıç Yapılandırması#

Onlarca kutu arasında kaybolmamak için, çoğu tipik WordPress sitesinde güvenli sonuç veren bir başlangıç şablonu şu şekildedir. Buradan başlayıp siteyi test ettikçe modülleri kademeli açabilirsiniz:

Şu sırayı izleyin: önce Page Cache ve Browser Cache'i açın, siteyi baştan sona gezip her şeyin çalıştığını doğrulayın. Ardından bellek deposu varsa Object Cache'i devreye alın. Minify'ı en sona bırakın ve yalnızca gerçekten ihtiyacınız varsa, adım adım açın. Her değişiklikten sonra önbelleği boşaltın (Performance menüsünde "empty all caches") ve gizli sekmede test edin; yoksa eski önbellek yüzünden değişikliği göremez, boşa vakit harcarsınız.

Sık Yapılan Hatalar ve Uyarılar#

W3TC'yle ilgili gelen destek taleplerinin büyük çoğunluğu birkaç tekrar eden hatadan kaynaklanır. En sık karşılaşılanlar ve çözümleri şunlardır:

• Değişiklik yaptım ama sitede görünmüyor: Neredeyse her zaman önbellek nedenidir. Önce W3TC önbelleğini, sonra varsa CDN önbelleğini, en son tarayıcı önbelleğini temizleyin.
• Sepet/ödeme sayfası bozuk çalışıyor: Dinamik sayfalar önbelleğe alınmış demektir. Page Cache'in "never cache" listesine sepet, ödeme ve hesap yollarını ekleyin.
• Tasarım kırıldı, menüler çalışmıyor: Büyük ihtimalle minify. Minify'ı kapatıp önbelleği temizleyin; site düzeldiyse sorun oradadır.
• Site tümüyle beyaz ekran (WSOD): Genellikle Disk: Enhanced modunun .htaccess/wp-config.php değişiklikleriyle uyumsuzluğu ya da Redis'e bağlanamama. FTP ile wp-content/cache klasörünü silin, gerekirse wp-content/object-cache.php drop-in dosyasını kaldırın.
• Yavaş disk, dolan inode: Object Cache'i disk üzerinde çalıştırmanın klasik sonucudur. Redis'e geçin ya da modülü kapatın.

Bir noktayı özellikle vurgulamak gerekir: W3TC bir performans eklentisidir, güvenlik ya da barındırma kalitesinin yerini tutmaz. Zayıf bir sunucuda çalışan yavaş bir siteyi önbellek bir yere kadar taşır; belirli bir trafiğin üstünde asıl fark, NVMe diskli ve yeterli kaynağa sahip bir altyapıdan gelir. Site altyapınızı taşımayı düşünüyorsanız site taşıma hizmetimizle geçişi kesintisiz yapabilir, WordPress'e özel optimize edilmiş WordPress hosting paketlerimizle de bu rehberdeki kazanımların üstüne sağlam bir zemin koyabilirsiniz.

Sıkça Sorulan Sorular#

W3 Total Cache gerçekten ücretsiz mi?#

Evet, eklentinin temel sürümü tamamen ücretsizdir ve bu rehberde anlatılan Page Cache, Minify, Object Cache ve Browser Cache modüllerinin hepsini içerir. Ücretli Pro sürümü ise gelişmiş fragment önbellekleme, REST API önbelleği ve öncelikli destek gibi çoğu site için zorunlu olmayan ekstralar sunar. Küçük ve orta ölçekli siteler ücretsiz sürümle fazlasıyla yeterli sonuç alır.

Aynı anda başka bir önbellek eklentisi kullanabilir miyim?#

Hayır, kesinlikle önerilmez. İki önbellek eklentisi aynı dosyaları ve wp-config.php satırlarını yönetmeye çalıştığında çakışır ve öngörülemez bozulmalara yol açar. Yalnızca bir önbellek eklentisi kurun; W3TC'den başka bir çözüme geçiyorsanız önce eskisini tamamen kaldırıp önbellek klasörlerini temizleyin, sonra yenisini kurun.

LiteSpeed sunucuda W3 Total Cache mi kullanmalıyım?#

Sunucunuz LiteSpeed tabanlıysa genellikle W3TC yerine LiteSpeed Cache eklentisini kullanmak daha mantıklıdır. LiteSpeed Cache, sunucu düzeyinde çalışan yerleşik önbelleği doğrudan kullandığı için aynı sunucuda W3TC'nin disk tabanlı yaklaşımından daha verimli olur. Hangi web sunucusunda olduğunuzu bilmiyorsanız hosting sağlayıcınıza sorabilir ya da panelden kontrol edebilirsiniz.

Object Cache için mutlaka Redis gerekli mi?#

Zorunlu değil ama önerilir. Object Cache'i disk üzerinde çalıştırmak paylaşımlı ortamlarda çoğu zaman fayda yerine yavaşlık ve dolan inode sorunu getirir. Gerçek kazanç Redis ya da Memcached gibi bellek tabanlı bir depoyla gelir. Bellek deposu yoksa Object Cache'i açmak yerine kapalı bırakıp Page Cache ile Browser Cache'e odaklanmak daha sağlıklıdır.

Minify modülü sitemi bozdu, ne yapmalıyım?#

Öncelikle panikleyip her şeyi silmeyin; sorun büyük olasılıkla yalnızca minify kaynaklıdır. Performance menüsünden Minify modülünü kapatın ve ardından tüm önbelleği boşaltın. Site düzeldiyse teşhis doğru demektir. Minify'a tekrar ihtiyacınız varsa bu kez yalnızca CSS küçültmeyle başlayıp JS birleştirmeyi devre dışı bırakarak kademeli ilerleyin.

Ayarları değiştirdim ama hiçbir hız farkı göremiyorum, neden?#

En yaygın sebep, ölçümü önbellek "ısınmadan" yapmaktır. Önbellek, bir sayfa ilk kez ziyaret edildikten sonra oluşur; ilk isteğiniz her zaman yavaştır. Aynı sayfayı ikinci kez, gizli sekmede test edin. İkinci nokta, tarayıcı önbelleğinin sizi yanıltmasıdır; ölçümü PageSpeed Insights veya GTmetrix gibi bağımsız bir araçla yapın. Yine fark yoksa, sorun büyük olasılıkla önbellekle değil sunucu kaynaklarınız ya da ağır bir tema/eklenti yüküyle ilgilidir.

Kapanış#

W3 Total Cache, doğru yapılandırıldığında WordPress sitenizi neredeyse hiç maliyet olmadan belirgin biçimde hızlandıran güçlü bir araçtır. Anahtar, hepsini birden açmak değil, doğru sırayı izlemektir: en yüksek kazancı veren Page Cache ile başlayın, riski düşük Browser Cache'i ekleyin, bellek deposu varsa Object Cache'i Redis üzerinde çalıştırın ve en riskli modül olan Minify'ı en sona, adım adım bırakın. Her değişiklikten sonra önbelleği temizleyip test etmek, sizi saatlerce sürecek "neden çalışmıyor" aramalarından kurtarır.

Unutmayın ki önbellek, sağlam bir altyapının üstüne konduğunda gerçek değerini gösterir. Sitenizin temelini NVMe diskli, WordPress'e özel optimize edilmiş bir plana taşımak isterseniz WordPress hosting paketlerimize göz atın; büyüyen trafiğe kaynaklarınızı ayrılmış bir çözümle karşılamak için VDS sunucu seçeneklerimizi de değerlendirebilirsiniz. Hızlı, kararlı ve güvenli bir WordPress deneyimi bir yapılandırma kadar bir altyapı meselesidir; Clou.TR ekibi olarak her iki tarafta da yanınızdayız.