CMS Performans ve Hız Ayarları: WordPress, Joomla, Drupal

CMS tabanlı sitelerde hız neden bu kadar kritik?

İster WordPress, ister Joomla, ister Drupal kullanıyor olun; ölçek büyüdükçe sorun genelde temadan önce altyapıda patlar. CMS performansı problemleri çoğu zaman yanlış yapılandırılmış PHP, veritabanı veya cache katmanından kaynaklanır. Tema değiştirmek ya da eklenti silmek bazen işe yarar; sunucu tarafı zayıfsa tek başına yeterli olmaz.

Canlı sistem yöneten herkes bilir: Trafik bir anda ikiye katlandığında ilk darbe CPU, disk I/O ve veritabanına gelir. Özellikle paylaşımlı hosting ortamında saniyeler içinde 504 hataları, timeout sorunları ve admin paneline bile girememe gibi sıkıntılar ortaya çıkabilir. Bu yüzden CMS’inizi taşıyacağınız VPS, bulut veya dedicated sunucuyu iş yükünüze göre seçmek ve güncel, ölçülebilir varsayılanlarla kurmak gerekir.

Buradaki odak, tek tek CMS ayarlarından çok altyapının üç katmanında: web sunucusu ve PHP, veritabanı ve cache. WordPress hızlandırma, Joomla sunucu ayarları veya Drupal optimize çalışmaları yaparken temel prensip aynı kalıyor: statik içeriği mümkün olduğunca önbellekten servis etmek, dinamik sorgu sayısını azaltmak ve ağır işlemleri arka plana taşımak.

Altyapı seçimi: VPS, bulut ve dedicated arasında denge

İyi ayarlanmamış güçlü bir dedicated sunucu, düzgün yapılandırılmış orta seviye bir VPS’ten daha yavaş çalışabilir. Önce iş yükünü ve büyüme hızınızı doğru okumak gerekiyor.

• Az trafikli kurumsal site veya blog için genellikle 2 vCPU, 4 GB RAM ve hızlı SSD depolama iş görür.
• Yoğun eklentili WordPress, çok dilli Joomla veya ağır modüllü Drupal sitelerinde 4 vCPU, 8 GB RAM ve mümkünse NVMe diskle başlamak daha güvenlidir.
• E-ticaret, üyelik tabanlı sistemler veya yoğun API çağrısı alan projelerde sanal veri merkezi ya da dedicated sunucu tercih edip kaynakları yatayda ölçeklemek daha sağlıklıdır.

Türkiye lokasyonlu, düşük gecikmeli bir altyapı arıyorsanız, CMS’inizi doğrudan paylaşımlı hosting yerine örneğin VPS.TC VPS ya da bulut sunucu üzerinde çalıştırmak size daha tutarlı performans ve yapılandırma özgürlüğü sağlar. Kendi Nginx, PHP-FPM ve veritabanı sürümlerinizi seçebilirsiniz.

Buradaki kritik nokta şu: Donanımı rastgele büyütmek yerine darboğazı önce tespit edin. CPU mu doluyor, RAM mi şişiyor, disk I/O mu tıkanıyor, yoksa veritabanı sorguları mı yavaş? Ölçmeden yapılan her optimizasyon üretim ortamında risk demek.

Web sunucusu ve PHP katmanında kritik ayarlar

PHP sürümü, OPcache ve FPM havuz ayarları

WordPress, Joomla ve Drupal’ın güncel desteklenen sürümleri PHP 8.3, 8.4 ve projenin uyumluluk durumuna göre PHP 8.5 ile çalışabiliyor. Eylül 2026’da yeni kurulumlarda destek süresi bitmiş PHP 7.x veya erken PHP 8.x sürümlerini kullanmak için teknik bir gerekçe olmadıkça ısrar etmeyin. CMS, eklenti ve tema uyumluluğunu staging ortamında doğrulayıp desteklenen en yeni kararlı sürüme geçin.

PHP-FPM ile OPcache’i birlikte ele almak gerekir. OPcache, PHP dosyalarının derlenmiş halini bellekte tuttuğu için her istekte dosya okuma ve derleme maliyetini azaltır. Üretim ortamında başlangıç için şu değerler makul olabilir:

• opcache.enable=1
• opcache.memory_consumption=256 (çok sayıda eklenti veya uygulama dosyası varsa 512 MB ölçülerek değerlendirilebilir)
• opcache.max_accelerated_files=30000
• opcache.validate_timestamps=0 (yalnızca kontrollü bir deploy süreciniz varsa)

PHP 8.5 gibi yeni bir sürüme geçerken yalnızca PHP-FPM servisini değil, ilgili php-fpm, Redis/APCu uzantılarını ve CMS eklentilerini de test edin. validate_timestamps=0 kullanıp dosya değişikliğinden sonra FPM’i yeniden başlatmayı unutursanız, eski kodun çalıştığını sanabilirsiniz.

PHP-FPM havuz ayarları, özellikle yüksek trafikli WordPress hızlandırma senaryolarında büyük fark yaratır. Basit bir örnek şöyle olabilir:

[www]
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500

Bu değerler her sistem için geçerli değildir. pm.max_children değerini RAM kapasitesine, PHP süreçlerinin gerçek bellek tüketimine ve eşzamanlı istek sayısına göre belirleyin. Ben bir müşterinin yoğun saatlerde swap’e düştüğünü incelerken sorunun CPU olmadığını, FPM süreçlerinin RAM’i tükettiğini ps ve free -h çıktılarıyla görmüştüm. Daha yüksek bir sayı yazmak çözüm değil; bazen tam tersidir.

Nginx veya Apache için bağlantı ve sıkıştırma ayarları

Web sunucusu tarafında hedef, bağlantıları verimli yönetmek ve metin tabanlı yanıtları gereksiz CPU harcamadan küçültmektir.

Nginx kullanıyorsanız, keepalive ve gzip ayarları için başlangıç noktası şöyle olabilir:

http {
    keepalive_timeout 15;
    sendfile on;
    tcp_nopush on;

    gzip on;
    gzip_comp_level 5;
    gzip_min_length 1024;
    gzip_types text/css application/javascript application/json image/svg+xml;
}

Modern istemcilerde Brotli de değerlendirilebilir. Nginx kurulumunuzdaki Brotli modülünü ve dağıtım paketlerini kontrol etmeden rastgele bir direktif eklemeyin; nginx -t çalıştırmadan reload etmek, geçmişte benim de yaptığım gereksiz bir kumardı.

Apache kullanıyorsanız event MPM ve mod_http2 ile PHP-FPM entegrasyonunu, yani mod_proxy_fcgi yaklaşımını tercih edin. mod_php her kurulumda yanlış değildir; fakat ayrı PHP-FPM havuzları ve daha kontrollü kaynak yönetimi gereken sunucularda daha sınırlı kalabilir. mod_deflate veya Brotli ile HTML, CSS ve JavaScript yanıtlarını sıkıştırabilirsiniz.

Her şeyi maksimuma açmak doğru değil. gzip_comp_level 9 CPU’yu gereksiz yorabilir; kazanılan bant genişliği çoğu senaryoda bu bedeli karşılamaz. Üretimde değişiklikleri önce test edip canlıya alırken hata oranı, yanıt süresi ve CPU kullanımını birlikte izleyin.

Veritabanı katmanını ayarlamak

MySQL/MariaDB için temel tampon ve bağlantı ayarları

WordPress, Joomla ve Drupal’ın büyük çoğunluğu MySQL veya MariaDB üzerinde çalışıyor. Veritabanı yavaşsa, PHP ve sayfa cache’i bazı istekleri kurtarır; fakat dinamik sayfaların toplam süresini tamamen saklayamaz.

İlk bakılacak yer InnoDB yapılandırmasıdır. innodb_buffer_pool_size çok küçükse sık kullanılan veri ve indeksler RAM’e sığmaz, disk erişimi artar. Ayrı bir veritabanı sunucusunda başlangıç için RAM’in yaklaşık yüzde 50-70’i değerlendirilebilir; aynı makinede PHP, web sunucusu ve Redis de çalışıyorsa bu oranı körü körüne uygulamayın.

[mysqld]
innodb_buffer_pool_size = 4G
max_connections = 100
skip_name_resolve = ON
query_cache_type = 0
query_cache_size = 0

innodb_log_file_size satırını eski rehberlerden kopyalayıp doğrudan kullanmayın. MySQL 8.0.30 ve sonraki sürümlerde redo log yönetimi değişti; MariaDB ve MySQL sürümüne göre ilgili güncel değişkenler farklı olabilir. Önce SELECT VERSION(); çıktısını alın, ardından kullandığınız sürümün resmi dokümantasyonuna göre redo log kapasitesini ayarlayın.

MySQL 8.0’da query cache zaten kaldırılmıştır. MariaDB’de bulunabilse de yoğun yazma trafiğinde çoğu uygulama için kapalı bırakmak daha güvenlidir. max_connections değerini de alışkanlıkla 1000 yapmayın. Her bağlantının bellek maliyeti vardır; bağlantı havuzu veya uygulama tarafındaki limitler çoğu zaman daha temiz bir çözüm sunar.

CMS seviyesinde temizlik ve indeks kullanımı

WordPress hızlandırma çalışmalarında gereksiz revizyon kayıtları, otomatik taslaklar ve şişmiş wp_options tablosu klasik sorunlardır. Düzgün bir bakım takvimi ile:

• Eski revizyonları ve otomatik taslakları temizleyebilir,
• autoload edilen ama artık kullanılmayan seçenekleri tespit edip kaldırabilir,
• Yavaş sorgu kayıtlarına bakarak gerçekten ihtiyaç duyulan indeksleri ekleyebilirsiniz.

Joomla ve Drupal tarafında da log ve oturum tabloları zamanla şişer. Drupal’ın güncel sürümlerinde log kayıtları veritabanı yerine syslog gibi kanallara yönlendirilebilir; bu seçeneği uygulamanızın hata ayıklama ihtiyacıyla birlikte değerlendirin. Sadece tabloyu silmek yerine kayıt saklama süresini ve cron temizliğini belirleyin.

Bu işlemleri doğrudan üretim veritabanında denemeyin. Önce geri dönüşü doğrulanmış bir yedek alın, tercihen staging ortamında test edin, ardından bakım penceresi açın. WHERE’siz bir DELETE komutunun ne kadar hızlı çalıştığını görmek istemezsiniz.

WordPress hızlandırma için sunucu odaklı pratikler

WordPress ekosisteminde çok sayıda cache eklentisi var; asıl kazanım, eklentiyi doğru yapılandırılmış bir sunucu ortamıyla birleştirdiğinizde ortaya çıkar.

Önce PHP tarafında OPcache’in stabil çalıştığından emin olun. Ardından object cache için Redis veya Memcached tercih etmek, özellikle çok sorgu yapan eklentilerde rahatlama sağlayabilir. Redis’i internete açık bırakmayın; Unix socket veya yalnızca yerel ağ üzerinden erişim ve kimlik doğrulama kullanın.

Yoğun trafik alan sitelerde WordPress cron sistemini gerçek cron’a taşımak da gereksiz istek yükünü azaltır:

define('DISABLE_WP_CRON', true);

Bu satırdan sonra sistem cron’unda dakikada bir çalışan bir görev ekleyebilirsiniz:

# WordPress cron'u gerçek cron üzerinden çalıştırmak için
* * * * * www-data php /var/www/site/public/wp-cron.php >/dev/null 2>&1

Buradaki yolu ve kullanıcıyı kendi kurulumunuza göre değiştirin. Cron’u yanlış kullanıcıyla çalıştırmak dosya sahipliğini bozabilir. Bir keresinde yedek script’ine fazladan bir yıldız eklenip görevin her dakika çalıştığını, posta kuyruğu büyüyünce fark etmiştim. Cron satırını kaydettikten sonra journalctl veya ilgili mail logunu kontrol etmek küçük bir sigorta.

Nginx kullanıyorsanız WordPress için FastCGI cache, anonim kullanıcı trafiğinde yanıt süresini ciddi biçimde azaltabilir. Giriş yapmış kullanıcıları, sepeti olan ziyaretçileri ve özel cookie taşıyan istekleri cache dışında bırakın. Cache anahtarını ve temizleme mekanizmasını test etmeden canlıya almayın.

Resimleri otomatik sıkıştıran ve WebP ya da AVIF üreten çözümler, CDN ve HTTP/2 desteği de önemlidir. HTTP/3 kullanılacaksa istemci, CDN veya ters proxy desteğini ayrıca doğrulayın; yalnızca sunucuda UDP 443 açmak HTTP/3 kurulumu sayılmaz.

Joomla sunucu ayarları ile kararlı hız

Joomla, modül ve eklentiler üzerinden genişletildiği için kötü yazılmış birkaç bileşen tüm siteyi yavaşlatabilir. Sunucu tarafında alacağınız önlemler bu etkiyi sınırlayabilir; kusurlu bir sorguyu cache ile sonsuza kadar gizleyemezsiniz.

Öncelikle Joomla sürümünüzün desteklediği PHP 8.x dalını seçip OPcache’i etkinleştirin. Joomla’nın dahili cache mekanizmasını etkinleştirirken, oturum ve cache verisinin birden fazla web sunucusunda paylaşılması gerekiyorsa Redis gibi bir store kullanın. Tek sunuculu küçük kurulumlarda dosya cache’i, yönetimi daha basit olduğu için yeterli olabilir.

Joomla sunucu ayarları tarafında dikkat edilmesi gereken başlıklar:

• Gzip veya Brotli sıkıştırmasını web sunucusu seviyesinde etkinleştirmek,
• Birden fazla uygulama düğümü varsa session verisini Redis gibi merkezi bir store’da tutmak,
• PHP-FPM havuzunu admin trafiğini ve arka plan görevlerini hesaba katarak boyutlandırmak,
• Gereksiz Apache modüllerini kapatmak veya Nginx tarafında fazla kural yükünü azaltmak.

Admin panelinde yapılan yapılandırma değişikliklerini staging Joomla kopyasında test edin. Özellikle cache ve sıkıştırma ayarlarında bozulmayı bu şekilde daha erken görürsünüz. Yanlış bir .htaccess kuralı, tüm siteyi 500 hata ekranına çevirebilir.

Drupal optimize ipuçları

Drupal, esnekliği ve modüler yapısı sayesinde büyük projelerde sık tercih ediliyor; yanlış yapılandırıldığında ağır çalışabiliyor. Burada da sunucu tarafı ayarları önemli bir kaldıraç.

Drupal’ın cache sistemini kullanabilmek için PHP OPcache’i etkinleştirin. APCu, tek sunuculu kurulumlarda yerel cache için; Redis ise paylaşılan cache ve session ihtiyacı olan çoklu sunucu senaryolarında değerlendirilebilir. Redis’i her durumda zorunlu bir bileşen gibi kurmak yerine trafik ve mimariye göre karar verin.

Asset CSS ve JavaScript birleştirme ile küçültme ayarlarını kontrollü biçimde etkinleştirin. HTTP/2 ve uygun altyapıda HTTP/3 desteği olan bir ters proxy arkasında Drupal çalıştırmak bağlantı yönetimini iyileştirebilir; fakat uygulama içindeki yavaş sorguyu ortadan kaldırmaz.

Drupal optimize çalışmalarında log ve cron yapılandırmasını atlamayın. Yoğun log tutan modüller diski doldurabilir, düzenli çalışmayan cron görevleri ise cache temizliği ve kuyruk işlemlerini aksatabilir. Cron sıklığını trafik profiliniz ve arka plan işlerinin süresiyle uyumlu hale getirin.

Veritabanı sorgularını da izleyin. Yavaş sorgu logları ve uygulama seviyesindeki profil araçları hangi sorgunun beklediğini gösterebilir. Bu sorgulara uygun indeks eklemek, kimi zaman donanımı iki katına çıkarmaktan daha etkili olur; indeksi eklemeden önce yazma maliyetini ve sorgu planını kontrol edin.

İzleme, log analizi ve sürekli iyileştirme için yol haritası

Sunucunuza SSH ile bağlandığınızda ilk iş anlık durumu görmek olmalı. Ben başlangıçta htop açarım; ardından disk ve ağ tarafını ayrı ayrı incelerim.

# Temel canlı izleme komutları
htop
iostat -xz 1
vmstat 1
ss -tnp | head

iostat komutu yoksa Debian ve Ubuntu’da genellikle sysstat paketini kurmanız gerekir. Bu komutlar CPU mu dolu, disk mi bekliyor, yoksa TCP bağlantıları mı birikiyor sorularına başlangıç cevabı verir. Ardından web sunucusu access ve error logları, PHP-FPM logları ve veritabanı slow query log’u ile tabloyu netleştirin.

Her büyük değişiklikten önce dosya sistemi, veritabanı ve mümkünse snapshot bazlı tam yedek alın. Yedek dosyasının var olması yeterli değil; geri dönüşü düzenli olarak deneyin. Özellikle VDS veya bulut sunucu kullanıyorsanız snapshot hızlı geri dönüş için yararlıdır, fakat tek başına yedek stratejisi değildir.

İlerlerken şu döngü işimi kolaylaştırıyor:

• Ölç: CPU, RAM, disk I/O, sorgu süreleri ve yanıt sürelerini izle.
• Darboğazı bul: En çok kaynak tüketen bileşeni tespit et.
• Hedefli değişiklik yap: Sadece ilgili katmanda ayar değiştir.
• Tekrar ölç: Değişikliğin etkisini rakamlarla gör.

İlk adım olarak mevcut sunucunuzda küçük bir performans envanteri çıkarın: Hangi PHP sürümü kullanılıyor, OPcache aktif mi, veritabanı tamponları yeterli mi, cache mekanizması nasıl çalışıyor? Ardından ayarları staging ortamında deneyip canlıya kontrollü geçin. Benim laboratuvarımda Proxmox üzerindeki test makineleri bu yüzden var; müşterinin sunucusu deneme tahtası değil.

WordPress sitenizin hız ayarlarını yaparken SEO tarafını da gözden geçirmek isterseniz, WordPress SEO eklentileri rehberime göz atabilirsiniz. Hangi eklentinin hangi özellikleri sunduğunu ve performansı nasıl etkileyebileceğini bu yazıda karşılaştırdım.

Sık Sorulan Sorular