WordPress Onbellek (Cache) Turleri ve Mantigi

WordPress'te "sitem yavaş" şikayetinin arkasında neredeyse her zaman aynı temel gerçek yatar: her ziyaretçi sayfayı istediğinde sunucu, o sayfayı sıfırdan yeniden inşa eder. PHP yorumlayıcısı tema ve eklenti dosyalarını okur, MySQL'e onlarca sorgu gönderir, gelen satırları HTML'e dönüştürür ve ancak ondan sonra tarayıcıya bir yanıt yollar. Bu döngü, statik bir HTML dosyasını sunmaya kıyasla katbekat pahalıdır. Trafik arttıkça bu maliyet çarpan etkisiyle büyür ve bir noktada sunucu artık yetişemez hâle gelir.

Önbellek (cache), tam olarak bu tekrarı ortadan kaldırmak için vardır: bir kez üretilen sonucu saklayıp bir sonraki isteğe hazır olarak sunmak. Ancak WordPress'te tek bir "önbellek" yoktur; birbirinden bağımsız çalışan, farklı sorunları çözen dört ayrı katman vardır. Bu rehberde sayfa önbelleği, tarayıcı önbelleği, nesne önbelleği (Redis/Memcached) ve PHP OPcache katmanlarını tek tek ele alacak, hangisinin hangi darboğazı çözdüğünü ve bunları bir arada nasıl kurgulayacağınızı sistem yöneticisi gözüyle açıklayacağız.

Önbellek Neden Gerekli: Dinamik İçeriğin Gizli Maliyeti#

Bir WordPress sayfasının üretilmesini bir restoran mutfağına benzetebiliriz. Statik HTML sunmak, önceden hazırlanıp vitrinde bekleyen bir tabağı uzatmak gibidir; saniyeler sürer. Dinamik üretim ise siparişi alıp malzemeleri toplamak, pişirmek ve tabağı sıfırdan hazırlamaktır. Her ziyaretçi için bu süreci baştan çalıştırmak, mutfağı yoğun saatte kilitler.

Somut olarak, önbelleksiz bir sayfa isteğinde şunlar gerçekleşir: web sunucusu isteği PHP-FPM'e iletir, PHP wp-load.php üzerinden tüm çekirdeği ve aktif eklentileri belleğe yükler, veritabanına bağlanır ve wp_options, wp_posts, wp_postmeta gibi tablolara sorgular atar. Orta ölçekli bir sitede tek bir sayfa görüntülemesi 30 ila 100 arası SQL sorgusu ve 200-800 milisaniye PHP çalışma süresi anlamına gelebilir. Bu süreyi ölçmek isterseniz sunucuda basit bir HTTP zamanlaması yeterlidir:

# Sayfanin sunucu tarafindaki uretim suresini olc
curl -s -o /dev/null -w "Baglanti: %{time_connect}s  Ilk bayt: %{time_starttransfer}s  Toplam: %{time_total}s\n" https://ornek.com/

time_starttransfer (ilk bayta kadar geçen süre, TTFB) değeri yüksekse darboğaz büyük ihtimalle PHP ve veritabanı tarafındadır. Önbelleğin amacı bu ilk bayt süresini düşürmektir. Her katman bu zincirin farklı bir halkasını hedefler: kimi PHP'yi hiç çalıştırmamayı, kimi veritabanı sorgularını azaltmayı, kimi de PHP kodunun her seferinde yeniden derlenmesini engellemeyi amaçlar. Katmanları anlamanın en pratik yolu, "hangi tekrarı engelliyor?" sorusunu her biri için ayrı ayrı sormaktır.

Sayfa Önbelleği (Page Cache): En Büyük Kazanç#

Sayfa önbelleği, üretilmiş HTML çıktısının tamamını saklar ve aynı sayfa tekrar istendiğinde PHP'yi ve veritabanını hiç çalıştırmadan bu hazır çıktıyı sunar. WordPress performansında en büyük tek kazanç neredeyse her zaman buradan gelir; çünkü zincirin en pahalı kısmını (PHP + MySQL) tamamen atlar. İyi yapılandırılmış bir sayfa önbelleği, TTFB'yi 600 milisaniyeden 30-50 milisaniyeye indirebilir.

Sayfa önbelleği iki yerde tutulabilir. Birincisi uygulama seviyesidir: WP Rocket, W3 Total Cache veya LiteSpeed Cache gibi eklentiler, üretilen HTML'i disk üzerinde .html dosyaları olarak saklar. İkincisi ise sunucu seviyesidir: Nginx fastcgi_cache, Varnish veya LiteSpeed'in dahili önbelleği, isteği PHP'ye hiç iletmeden karşılar. Sunucu seviyesi genellikle daha hızlıdır çünkü PHP-FPM'e soket bağlantısı bile kurulmaz. Nginx tarafında tipik bir yapılandırma şöyle görünür:

# HTML ciktisini disk uzerinde onbellege al
fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WPCACHE:100m inactive=60m;

server {
    set $skip_cache 0;
    # Giris yapmis kullanicilar, yorum yapanlar ve POST istekleri onbelleklenmez
    if ($request_method = POST) { set $skip_cache 1; }
    if ($http_cookie ~* "wordpress_logged_in|woocommerce_cart_hash") { set $skip_cache 1; }
    if ($request_uri ~* "/wp-admin/|/cart/|/checkout/") { set $skip_cache 1; }

    location ~ \.php$ {
        fastcgi_cache WPCACHE;
        fastcgi_cache_valid 200 60m;      # 200 yanitlarini 60 dakika sakla
        fastcgi_cache_bypass $skip_cache;  # kosul saglaninca onbellegi atla
        fastcgi_no_cache $skip_cache;      # ve yaniti onbellege yazma
        add_header X-Cache $upstream_cache_status;  # HIT/MISS ayikla
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Buradaki en kritik nokta, neyin önbelleklenmeyeceğini doğru tanımlamaktır. Giriş yapmış kullanıcılar, sepetinde ürün olan WooCommerce müşterileri veya kişiselleştirilmiş içerik gören ziyaretçiler asla ortak bir önbellekten beslenmemelidir; aksi halde bir kullanıcı diğerinin sepetini veya yönetici çubuğunu görebilir. Bu yüzden oturum çerezleri (wordpress_logged_in), sepet çerezleri ve /wp-admin/, /cart/, /checkout/ gibi yollar mutlaka bypass kapsamına alınır. Sayfa önbelleğinin mantığını ve diğer hızlandırma yöntemleriyle birlikte nasıl kullanılacağını WordPress hız optimizasyonu rehberimizde daha geniş ele alıyoruz.

Önbelleği yönetmek de en az kurmak kadar önemlidir. Bir yazıyı güncellediğinizde ilgili sayfanın önbelleği temizlenmezse ziyaretçiler eski içeriği görmeye devam eder. Çoğu eklenti bunu otomatik yapar; komut satırından ise WP-CLI ile toptan temizlik mümkündür:

# Tum sayfa onbellegini temizle (eklentiye gore komut degisebilir)
wp cache flush
wp rocket clean --confirm    # WP Rocket icin
# Nginx fastcgi_cache disk klasorunu bosaltmak
rm -rf /var/cache/nginx/wp/*

Tarayıcı Önbelleği (Browser Cache): İkinci Ziyareti Hızlandırmak#

Şimdiye kadar anlattığımız katmanlar sunucu tarafındaydı. Tarayıcı önbelleği ise tamamen istemci tarafında çalışır: ziyaretçinin tarayıcısına "bu CSS dosyasını, bu logoyu, bu fontu bir daha benden isteme, kendi diskinde sakla" demektir. Böylece ilk ziyarette indirilen statik varlıklar (görseller, stil dosyaları, JavaScript, yazı tipleri) ikinci ziyarette hiç ağdan indirilmez ve sayfa çok daha hızlı açılır.

Bu davranış tamamen HTTP başlıklarıyla kontrol edilir. Sunucu, statik bir dosyayı gönderirken yanıtına Cache-Control ve Expires başlıkları ekleyerek dosyanın ne kadar süre saklanabileceğini bildirir. Apache kullanıyorsanız bu ayarlar genellikle .htaccess dosyasına yazılır:

# Statik varliklara uzun sureli tarayici onbellegi ver (Nginx)
location ~* \.(jpg|jpeg|png|gif|webp|svg|css|js|woff2|ico)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

immutable ifadesi tarayıcıya "bu dosya adı değişmediği sürece içeriği asla değişmez, sayfa yenilense bile tekrar kontrol etme" der. Peki bir CSS dosyasını güncellerseniz ne olur? İşte burada cache busting (önbellek kırma) devreye girer: WordPress, dosya adına bir sürüm parametresi ekler (style.css?ver=6.5.2). Sürüm numarası değiştiğinde tarayıcı bunu yeni bir dosya sanıp yeniden indirir. Bu yüzden statik varlıklara güvenle uzun süreli önbellek verebilirsiniz; içerik değiştiğinde adres de değişir.

Tarayıcı önbelleğinin sunucu yükünü nasıl azalttığını görmek için başlıkları doğrudan inceleyebilirsiniz:

# Bir varligin onbellek basliklarini kontrol et
curl -sI https://ornek.com/wp-content/themes/tema/style.css | grep -iE "cache-control|expires|etag"

Bu katman, sayfa önbelleğinin aksine sunucunuzun ilk bayt süresini düşürmez; onun yerine tekrar eden ziyaretlerde toplam indirilen bayt miktarını ve istek sayısını düşürür. Özellikle çok sayıda görsel ve font içeren temalarda, iyi yapılandırılmış tarayıcı önbelleği "geri dönen ziyaretçi" deneyimini dramatik biçimde iyileştirir.

Nesne Önbelleği (Object Cache): Redis ve Memcached#

Sayfa önbelleği harika çalışır, ama bir sınırı vardır: yalnızca anonim ziyaretçiler için işe yarar. WooCommerce mağazaları, üyelik siteleri, forumlar veya yoğun bir yönetim paneli gibi çok sayıda giriş yapmış kullanıcının bulunduğu sitelerde sayfalar kişiselleştirildiği için tam sayfa önbelleklenemez. İşte nesne önbelleği tam bu boşluğu doldurur.

Nesne önbelleği, sayfanın tamamını değil, sayfayı üretirken tekrar tekrar yapılan pahalı veritabanı sorgularının sonuçlarını saklar. WordPress zaten dahili bir nesne önbelleğine sahiptir, ancak varsayılan hâli yalnızca tek bir istek boyunca geçerlidir; istek bitince bellek boşalır. Redis veya Memcached gibi bir kalıcı depoya bağlandığında ise bu sonuçlar istekler arasında hayatta kalır. wp_options tablosundaki autoload verileri, kullanıcı yetkileri, sık çağrılan taksonomi ve meta sorguları bir kez hesaplanıp bellekte tutulur; sonraki isteklerde MySQL'e gitmek yerine mikrosaniyeler içinde bellekten okunur.

WordPress'e kalıcı nesne önbelleği eklemek için bir arka uç (Redis önerilir) ve bir "drop-in" eklentisi (wp-content/object-cache.php) gerekir. Redis'i bir kapsayıcı olarak ayağa kaldırmak isterseniz:

# docker-compose.yml — WordPress icin Redis nesne onbellegi
services:
  redis:
    image: redis:7-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    restart: unless-stopped
    ports:
      - "127.0.0.1:6379:6379"

allkeys-lru politikası, bellek dolunca en az kullanılan anahtarları otomatik atarak Redis'in şişmesini engeller; nesne önbelleği için ideal davranıştır. Ardından WordPress tarafında bağlantıyı wp-config.php içinde tanımlayıp Redis Object Cache eklentisini etkinleştirmeniz yeterlidir. Çalışıp çalışmadığını doğrulamak kolaydır:

# WP-CLI ile nesne onbellegi durumunu dogrula
wp redis status
# Redis tarafinda anahtar sayisini ve isabet oranini gor
redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

keyspace_hits değerinin keyspace_misses'a oranı yüksekse (ideali %90 üzeri) önbellek işini yapıyor demektir. Redis'in çalışma mantığını, bir mesaj kuyruğu ve önbellek deposu olarak nasıl kullanıldığını Redis nedir yazımızda ayrıntılandırdık. Memcached de benzer bir iş yapar; aralarındaki temel fark Redis'in veri yapılarını desteklemesi ve isteğe bağlı kalıcılık sunmasıdır. WordPress nesne önbelleği için ikisi de gayet uygundur, ancak Redis daha zengin özellik seti ve daha iyi izleme araçlarıyla günümüzde varsayılan tercihtir.

PHP OPcache: Kod Derlemesini Atlamak#

Dördüncü ve çoğu zaman gözden kaçan katman OPcache'tir. Diğer üç katman verileri (HTML, statik dosyalar, sorgu sonuçları) önbelleklerken OPcache kodu önbellekler. PHP yorumlanan bir dildir: her istekte .php dosyaları okunur, insan tarafından yazılmış kaynak kod önce "opcode" adı verilen ara bir makine koduna derlenir, sonra çalıştırılır. WordPress ve eklentileri binlerce PHP dosyasından oluştuğu için bu derleme adımı her istekte ciddi bir CPU maliyeti yaratır.

OPcache, bu derlenmiş opcode'ları paylaşımlı bellekte saklar. Bir dosya bir kez derlendikten sonra, dosya değişmediği sürece PHP onu tekrar derlemez; doğrudan bellekten çalıştırır. Sonuç, PHP çalışma süresinde tipik olarak %30-50 arası bir iyileşmedir ve bu kazanç giriş yapmış kullanıcılar dahil her istekte geçerlidir; çünkü OPcache oturumdan ve içerikten bağımsız çalışır. WordPress çalıştıran her sunucuda OPcache mutlaka açık olmalıdır. Yapılandırması php.ini (veya opcache.ini) içinde yapılır:

; PHP OPcache — WordPress icin onerilen ayarlar
opcache.enable=1
opcache.memory_consumption=256        ; MB cinsinden opcode bellegi
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000   ; onbelleklenecek dosya sayisi
opcache.revalidate_freq=60            ; dosya degisikligini kac saniyede bir kontrol et
opcache.validate_timestamps=1         ; uretimde 0 yapip elle temizlemek daha hizlidir
opcache.save_comments=1               ; WordPress bazi eklentiler icin yorumlara ihtiyac duyar

Buradaki max_accelerated_files değeri önemlidir: WordPress + eklentiler kolayca on binlerce dosyaya ulaşır ve bu limit aşılırsa OPcache en eski girdileri atmaya başlar, isabet oranı düşer. validate_timestamps=0 ayarı ise en yüksek performansı verir ama bir uyarı taşır: kod dosyalarını her değiştirdiğinizde (eklenti güncellemesi, tema düzenlemesi) OPcache'i elle temizlemeniz gerekir, aksi halde eski kod çalışmaya devam eder. Bunu bir deploy adımı olarak otomatikleştirmek en güvenlisidir:

# Kod dagitiminin sonunda OPcache'i temizle
php -r 'opcache_reset(); echo "OPcache temizlendi\n";'
# ya da PHP-FPM'i nazikce yeniden yukleyerek
systemctl reload php8.2-fpm

Clou.TR paylaşımlı ve WordPress hosting paketlerinde OPcache öntanımlı olarak etkindir; ama kendi VDS veya sanal sunucunuzu yönetiyorsanız bu ayarları elle doğrulamanızda fayda var. OPcache'in yalnızca kodu önbelleklediğini, veriyle ilgisi olmadığını unutmayın; içerik güncellemeleriniz OPcache'ten etkilenmez, yalnızca kaynak kod dosyaları etkilenir.

Katmanları Bir Arada Kurgulamak#

Dört katmanı ayrı ayrı anladıktan sonra asıl mesele bunların birlikte nasıl çalıştığıdır. İyi haber şu: birbirlerinin rakibi değil, tamamlayıcısıdırlar. Her biri zincirin farklı bir halkasını kısaltır ve doğru kurgulandıklarında etkileri çarpan biçiminde birikir. Aşağıdaki tablo, her katmanın neyi sakladığını ve hangi ziyaretçi tipine fayda sağladığını özetliyor:

Pratikte bir isteğin ideal akışı şöyle işler: İstek geldiğinde önce sayfa önbelleği devreye girer; ziyaretçi anonimse ve sayfa önbellekteyse HTML anında sunulur, zincir burada biter. Ziyaretçi giriş yapmışsa sayfa önbelleği atlanır ve PHP çalışır; bu sırada OPcache derleme adımını hızlandırır, nesne önbelleği ise tekrarlayan veritabanı sorgularını Redis'ten karşılar. Sayfa üretilip tarayıcıya gönderilirken statik varlıklar tarayıcı önbelleği başlıklarıyla işaretlenir, böylece bir sonraki ziyarette indirilmezler.

Bu katmanları hangi barındırma tipinde ne kadar kontrol edebileceğiniz de önemlidir. Paylaşımlı hosting ortamlarında sayfa önbelleği (eklenti üzerinden), tarayıcı önbelleği ve OPcache genellikle hazır gelir veya kolayca açılır; ancak kendi Redis örneğinizi çalıştırmak çoğunlukla mümkün değildir. Yoğun trafikli bir WooCommerce mağazası veya üyelik sitesi işletiyorsanız ve nesne önbelleğine gerçekten ihtiyaç duyuyorsanız, kök erişimi veren bir sunucu çözümüne geçmek dört katmanı da özgürce yönetmenizi sağlar. Kurulum ve ayar tarafında desteğe ihtiyaç duyarsanız sunucu yönetimi ve WordPress bakım hizmetlerimiz devreye girer.

Sık Yapılan Hatalar ve Önbellek Temizleme#

Önbellek çift taraflı bir kılıçtır: doğru kurulunca siteyi uçurur, yanlış kurulunca "neden değişikliğim görünmüyor?" veya "neden yanlış kullanıcının sepeti görünüyor?" gibi baş ağrılarına yol açar. En sık karşılaşılan hata, dinamik içeriğin yanlışlıkla önbelleklenmesidir. Bir iletişim formunun CSRF jetonu, kişiselleştirilmiş bir "hoş geldin" mesajı veya sepet toplamı sayfa önbelleğine takılırsa tüm ziyaretçilere aynı bayat veri gider. Çözüm, bu tür parçaları önbellekten muaf tutmak (fragment caching / ESI) veya ilgili sayfaları tamamen bypass listesine almaktır.

İkinci klasik tuzak, katmanların birbirini gölgelemesidir. Bir yazıyı güncellediniz ama değişiklik görünmüyor. Sorun nerede? Önce sayfa önbelleğini, sonra varsa CDN önbelleğini, en son tarayıcı önbelleğini düşünün. Doğru sıra kritiktir: en dıştaki katmandan içe doğru temizlemezseniz eski bir kopya tekrar aşağıdaki katmanları "kirletebilir". Katmanları hızlıca teşhis etmek için önce yanıt başlıklarına bakın; X-Cache: HIT görüyorsanız yanıt sayfa önbelleğinden geliyordur:

# Yanitin hangi katmandan geldigini teshis et
curl -sI https://ornek.com/ | grep -iE "x-cache|cf-cache-status|age|x-litespeed-cache"

Bir içerik değişikliğinden sonra güvenli temizlik sırası genellikle şöyledir: önce eklenti/sunucu sayfa önbelleğini temizleyin, CDN kullanıyorsanız kenar önbelleğini boşaltın (purge), gerekiyorsa nesne önbelleğinden ilgili anahtarları atın. WooCommerce gibi durumlarda wp_options üzerinden gelen bayat transient kayıtları da soruna yol açabilir; bunları veritabanından temizlemek işe yarar:

-- Suresi dolmus veya sikismis WordPress transient kayitlarini temizle
DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site\_transient\_%';

Üçüncü sık hata OPcache'i unutmaktır. validate_timestamps=0 ile çalışan bir sunucuda eklenti güncellediniz ama OPcache'i temizlemediniz; yeni kod diske yazıldı ama sunucu hâlâ eski derlenmiş opcode'u çalıştırıyor. Sonuç, açıklaması zor "bazen çalışıyor bazen çalışmıyor" tipi hatalardır. Bu yüzden her kod dağıtımının sonuna bir OPcache reset adımı koymak altın kuraldır. Son olarak, önbelleğin bir performans aracı olduğunu ama güvenlik veya doğruluk garantisi olmadığını hatırlayın: doğru "neyi önbelleklemeyeceğim?" kararı, "neyi önbellekleyeceğim?" kararından her zaman daha önemlidir.

Sıkça Sorulan Sorular#

WordPress için hangi önbellek katmanıyla başlamalıyım?#

OPcache ve sayfa önbelleğiyle başlayın. OPcache sunucu seviyesinde tek seferlik bir ayardır ve her isteği hızlandırır; sayfa önbelleği ise anonim ziyaretçiler için en büyük tek kazancı sağlar. Bu ikisi çoğu blog, kurumsal site ve tanıtım sitesi için zaten yeterlidir. Nesne önbelleğine (Redis) ancak çok sayıda giriş yapmış kullanıcınız veya yoğun bir WooCommerce mağazanız varsa ihtiyaç duyarsınız; erken eklemek gereksiz karmaşıklık yaratır.

Sayfa önbelleği ile nesne önbelleği aynı şey mi?#

Hayır, farklı katmanlardır ve farklı sorunları çözerler. Sayfa önbelleği üretilmiş HTML'in tamamını saklar ve PHP ile MySQL'i tamamen atlar; ancak yalnızca kişiselleştirilmemiş, anonim sayfalarda çalışır. Nesne önbelleği ise sayfa üretilirken yapılan tekil veritabanı sorgu sonuçlarını saklar ve giriş yapmış kullanıcılar dahil PHP her çalıştığında MySQL yükünü azaltır. İkisi birbirinin alternatifi değil, tamamlayıcısıdır; ideal kurulumda her ikisi de açıktır.

Değişikliğim sitede görünmüyor, ne yapmalıyım?#

Büyük olasılıkla bir önbellek katmanı eski kopyayı sunuyordur. Önce eklenti veya sunucu sayfa önbelleğini temizleyin, CDN kullanıyorsanız kenar önbelleğini boşaltın (purge), en son tarayıcınızda sert yenileme (Ctrl+F5) yapın. Değişiklik bir eklenti veya tema kodundaysa ve sunucuda OPcache açıksa, OPcache'i de sıfırlamanız gerekebilir. Yanıt başlıklarında X-Cache: HIT görüyorsanız içerik hâlâ sayfa önbelleğinden geliyordur ve o katmanı temizlemeniz gerekir.

Redis mi Memcached mi seçmeliyim?#

WordPress nesne önbelleği için ikisi de gayet iyi çalışır, ancak günümüzde Redis daha yaygın tercih edilir. Redis; veri yapıları desteği, isteğe bağlı kalıcılık, daha iyi bellek yönetimi ve olgun izleme araçları sunar. Memcached daha basit ve saf bir anahtar-değer önbelleğidir; çok basit senaryolarda birkaç mikrosaniye avantaj sağlayabilir ama pratikte fark ihmal edilebilir. Yeni bir kurulumda ekosistem desteği daha geniş olduğu için Redis'i öneririz.

Tarayıcı önbelleği sunucumun yükünü azaltır mı?#

Dolaylı olarak evet. Tarayıcı önbelleği doğrudan ilk bayt süresini düşürmez; onun yerine geri dönen ziyaretçilerin statik dosyaları (görsel, CSS, JavaScript, font) tekrar indirmesini engeller. Bu sayede sunucunuza ulaşan istek sayısı ve gönderilen toplam bant genişliği ciddi biçimde azalır. Özellikle çok görselli sitelerde bu, hem sunucu kaynaklarını rahatlatır hem de ziyaretçinin ikinci ziyaretteki açılış süresini belirgin şekilde iyileştirir.

OPcache'i paylaşımlı hostingte açabilir miyim?#

Çoğu kaliteli paylaşımlı hosting sağlayıcısında OPcache zaten öntanımlı olarak etkindir; ayrıca bir şey yapmanıza gerek kalmaz. Clou.TR hosting paketlerinde OPcache açıktır. Kendi sunucunuzu yönetiyorsanız php.ini içinden opcache.enable=1 ile etkinleştirir ve opcache.memory_consumption ile opcache.max_accelerated_files değerlerini WordPress'in çok dosyalı yapısına göre yükseltirsiniz. Çalışıp çalışmadığını php -i | grep opcache.enable komutuyla veya bir phpinfo() sayfasıyla doğrulayabilirsiniz.

Kapanış#

WordPress performansı tek bir sihirli düğme değil, dört farklı önbellek katmanının uyum içinde çalışmasıdır. OPcache derleme maliyetini, sayfa önbelleği PHP ve veritabanı yükünü, nesne önbelleği tekrarlayan sorguları, tarayıcı önbelleği ise ağ trafiğini ortadan kaldırır. Her katmanı "hangi tekrarı engelliyor?" sorusuyla değerlendirdiğinizde, sitenizin ihtiyacına göre doğru kombinasyonu kurmak sandığınızdan kolaydır. En büyük kazanç genellikle sayfa önbelleği ve OPcache'ten gelir; nesne önbelleğini ise gerçekten ihtiyaç duyduğunuzda ekleyin.

Bu katmanların hepsini elinizin altında tutan, OPcache'i açık, LiteSpeed sayfa önbelleği hazır ve isteğe göre Redis destekli bir altyapı arıyorsanız Clou.TR WordPress hosting ve web hosting paketlerine göz atabilirsiniz. Daha fazla kaynak ve kök erişimi gerektiren yoğun projeler için VDS ve sanal sunucu çözümlerimiz, kurulumdan bakıma kadar destek için ise sunucu yönetimi ve WordPress bakım hizmetlerimiz yanınızda. Önbelleği doğru kurgulayın; ziyaretçileriniz farkı ilk saniyede hissedecek.