WordPress Yavaşladı: Adım Adım Teşhis Rehberi

WordPress Yavaşladı: Adım Adım Teşhis Rehberi

"Site açılmıyor" ile "site geç açılıyor" birbirinden çok farklı iki problemdir ama WordPress kullanıcılarının büyük kısmı ikisini de aynı panik ile karşılar: eklenti mi bozdu, hosting mi yetersiz, yoksa tema mı ağır? Doğru cevabı bulmadan rastgele "hız eklentisi" kurup üstüne bir de önbellek eklentisi eklemek, çoğu zaman sorunu çözmek yerine katmanlayarak gizler. Bu yazıda WordPress yavaşlamasının kök nedenini bulmak için izlenebilecek, sondan başa değil baştan sona giden sistematik bir teşhis sırası anlatıyoruz: önce ölçüm, sonra hosting katmanı, sonra eklenti/tema, sonra veritabanı, sonra önbellekleme ve son olarak kod seviyesi analiz.

Büyükweb perspektifi: Destek talebi olarak gelen "sitem yavaş" şikayetlerinin büyük çoğunluğunda müşteri henüz hiçbir ölçüm yapmamış oluyor. Teşhis olmadan çözüm önermek, doktора gitmeden ilaç yazdırmaya benzer — bazen tutar, çoğu zaman tutmaz.

Yavaşlık Nerede Başlıyor? İlk 10 Dakikada Yapılacaklar

Teşhise başlamadan önce sorunu net bir şekilde tarif etmek gerekir. "Yavaş" kelimesi en az dört farklı anlama gelebilir:

• Sunucu tepki süresi (TTFB) yüksek: Tarayıcı ilk baytı geç alıyor, yani sorun sayfa render'ından önce başlıyor.
• Sayfa yükleniyor ama geç tamamlanıyor: HTML hızlı geliyor ama görsel, CSS, JS dosyaları sayfayı geciktiriyor.
• Yönetim paneli (wp-admin) yavaş, ön yüz normal: Bu genelde eklenti/veritabanı kaynaklı bir işarettir.
• Belirli sayfalar yavaş, diğerleri hızlı: Sorun büyük ihtimalle o sayfaya özgü bir sorgu veya eklenti bloğudur.

Bu dört senaryoyu birbirinden ayırmadan ilerlemek, teşhis sürecinin en sık yapılan hatasıdır. İlk 10 dakikanızı şu üç soruya cevap bulmaya ayırın: Yavaşlık her sayfada mı yoksa belirli sayfalarda mı? Giriş yapmış kullanıcıda da aynı mı, ziyaretçi modunda da aynı mı? Sorun ne zaman başladı — yakın zamanda kurulan bir eklenti, tema güncellemesi veya trafik artışı var mı?

Adım 1: Rakamlarla Konuşun — Hız Ölçüm Araçları ve Core Web Vitals

Teşhisin ilk kuralı: hisse değil, rakama güvenin. Tarayıcınızın geliştirici araçlarındaki Ağ (Network) sekmesi ile birlikte bağımsız bir hız ölçüm aracı kullanarak şu üç metriği not edin:

1. TTFB (Time to First Byte): Sunucunun ilk yanıtı ne kadar sürede döndürdüğü. 200ms altı iyi, 600ms üzeri sorunlu kabul edilir.
2. LCP (Largest Contentful Paint): Sayfanın ana içeriğinin görünür hale gelme süresi.
3. TBT (Total Blocking Time): JavaScript'in ana iş parçacığını ne kadar bloke ettiği.

Bu üç metrik aslında Core Web Vitals'ın temelini oluşturur ve Google'ın arama sıralamasında da dikkate aldığı sinyallerdir. Ölçümü aynı sayfada üç kez tekrarlayıp ortalama alın — tek ölçüm yanıltıcı olabilir, çünkü paylaşımlı sunucularda anlık yük dalgalanmaları sonucu etkiler. Core Web Vitals metriklerini iyileştirme konusunda daha derinlemesine bir teknik anlatım için WordPress Hız Optimizasyonu ve Core Web Vitals yazımıza bakabilirsiniz.

Ölçüm sonuçlarını kaydederken şu ayrımı yapın: TTFB yüksekse sorun büyük ihtimalle sunucu/hosting veya veritabanı tarafında; TTFB normal ama LCP/TBT yüksekse sorun büyük ihtimalle tema, eklenti veya optimize edilmemiş görsellerdedir. Bu ayrım, sonraki adımlarda zaman kaybetmemenizi sağlar.

Adım 2: Hosting Katmanını Sorgulayın — Kaynak mı, Konfigürasyon mu?

TTFB yüksekse önce sunucu kaynaklarına bakmak gerekir. Paylaşımlı hosting ortamlarında CPU, RAM ve I/O kaynakları diğer kullanıcılarla paylaşılır; kontrol panelinizdeki kaynak kullanım grafiklerinden CPU veya bellek limitine yaklaşıp yaklaşmadığınızı görebilirsiniz. Aşağıdaki tablo, hangi belirtinin hangi kaynak darboğazına işaret ettiğini özetliyor:

Belirti	Olası Neden
Tüm sayfalarda sabit yüksek TTFB	CPU/RAM limiti dolmuş veya PHP-FPM işlem sayısı yetersiz
Belirli saatlerde (trafik zirvesinde) yavaşlama	Eşzamanlı bağlantı/işlem limiti aşımı
wp-admin yavaş, ön yüz hızlı	Veritabanı sorgu yükü veya cron görevleri
Ani, kalıcı yavaşlama	Yakın zamanda eklenen bir eklenti/entegrasyon veya trafik artışı

PHP sürümü de burada kritik bir değişkendir. Eski PHP sürümleri hem güvenlik hem performans açısından dezavantajlıdır; PHP 8.x serisine geçiş, bazı sitelerde ek maliyet olmadan gözle görülür bir hız kazancı sağlar. Sürüm yükseltme adımlarını WordPress PHP Sürümü Güncelleme Rehberi yazısında ayrıntılı anlattık.

Kaynak limitine gerçekten dayandığınızı doğruladıysanız — yani eklenti/tema optimizasyonuna rağmen kaynak tavanına vuruyorsanız — çözüm optimizasyon değil ölçeklemedir. Trafiği artan veya kaynak ihtiyacı paylaşımlı planın sınırlarını zorlayan projeler için WordPress Hosting paketlerimiz günlük otomatik yedekleme dahil olacak şekilde sunulur; paylaşımlı planı denemek isteyenler için koşullu 7 gün iade hakkı da geçerlidir, dolayısıyla kaynak testini düşük riskle yapabilirsiniz.

Büyükweb perspektifi: "Hosting yetersiz" tanısını koymadan önce eklenti/veritabanı optimizasyonunu tüketmiş olmak önemli. Aksi halde bir üst pakete geçip aynı sorunla birkaç ay sonra tekrar karşılaşırsınız — çünkü kök neden kaynak değil, kaynağı israf eden konfigürasyondu.

Adım 3: Eklenti ve Tema Denetimi — Şüpheli Listesini Daraltın

WordPress yavaşlamalarının en sık rastlanan nedeni, eklenti ve tema katmanındaki gereksiz yüktür. Bunu bulmanın en güvenilir yolu eleme testidir:

1. Sitenizi bir staging (test) ortamına klonlayın — canlı sitede deneme yapmayın. Staging ortamı kurulumu için WordPress Staging Ortamı Kurulumu rehberimizi izleyebilirsiniz.
2. Staging ortamında tüm eklentileri devre dışı bırakın, varsayılan bir temaya geçin, hız ölçümünü tekrarlayın.
3. Eklentileri tek tek (veya gruplar halinde ikili arama mantığıyla) yeniden etkinleştirip her seferinde ölçüm alın.
4. Hangi eklenti eklendiğinde TTFB veya LCP belirgin şekilde arttıysa, suçlu odur.

Sık karşılaşılan ağır eklenti kategorileri şunlardır: sayfa oluşturucu (page builder) eklentileri, çok sayıda widget/blok içeren "her şeyi yapan" tema paketleri, gereksiz sosyal medya/istatistik entegrasyonları ve arka planda sürekli tarama yapan güvenlik eklentileri. Güvenlik eklentileri özellikle dikkat gerektirir çünkü gerçek zamanlı dosya taraması yapan bazı yapılandırmalar CPU'yu ciddi şekilde tüketebilir; bu eklentileri doğru yapılandırmak için Wordfence ve Sucuri Karşılaştırması yazımıza bakabilirsiniz.

Tema tarafında da benzer bir mantık geçerlidir: çok sayıda demo içerik, gömülü slider kütüphanesi ve kullanılmayan stil dosyası taşıyan "her şey dahil" temalar, sayfanın ihtiyaç duymadığı CSS/JS dosyalarını yükleyerek TBT ve LCP metriklerini kötüleştirir. Bu eleme sürecinde bulduğunuz sonuçları not edin; aynı zamanda eklenti sayısını azaltmak uzun vadede güvenlik yüzeyini de küçültür.

Adım 4: Veritabanı Şişkinliği ve Yavaş Sorgular

wp-admin paneli yavaşsa veya ön yüzde belirli sayfalar (özellikle çok yorum/ürün içeren sayfalar) yavaşsa, sorun genellikle veritabanı katmanındadır. WordPress veritabanı zamanla üç şekilde şişer:

• Post revizyonları: Her kayıt işleminde yeni bir revizyon satırı eklenir, yüzlerce revizyon biriken içerikler sorgu süresini uzatır.
• Autoload edilen options: wp_options tablosunda autoload=yes olarak işaretlenmiş, her sayfa yüklemesinde otomatik çekilen ayarlar. Bazı eklentiler burada gereksiz büyük veri saklar.
• Süresi dolmuş transient'lar: Geçici önbellek verileri temizlenmediğinde tabloyu şişirir.

phpMyAdmin veya benzer bir veritabanı yönetim aracından şu sorguyla en büyük tabloları görebilirsiniz:

SELECT table_name AS Tablo, 
       ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Boyut (MB)"
FROM information_schema.TABLES
WHERE table_schema = "veritabani_adiniz"
ORDER BY (data_length + index_length) DESC
LIMIT 10;

wp_options tablosunda autoload yükünü kontrol etmek için:

SELECT SUM(LENGTH(option_value)) AS toplam_boyut, option_name
FROM wp_options
WHERE autoload = 'yes'
GROUP BY option_name
ORDER BY toplam_boyut DESC
LIMIT 20;

wp-cli kullanıyorsanız aynı temizliği komut satırından da yapabilirsiniz:

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp transient delete --expired
wp db optimize

Bu üç komut sırasıyla eski revizyonları siler, süresi dolmuş transient'ları temizler ve tablo indekslerini yeniden düzenler. Veritabanı bakımını düzenli bir alışkanlık haline getirmek istiyorsanız WordPress Veritabanı Optimizasyonu yazımızda kalıcı bir bakım planı bulabilirsiniz.

Adım 5: Önbellekleme, CDN ve Görsel Optimizasyonu

TTFB normal ama sayfa tamamlanma süresi (LCP) yüksekse, sorun genellikle önbellekleme eksikliği veya optimize edilmemiş görsellerdir. Kontrol edilmesi gereken üç katman şudur:

1. Sayfa önbelleği (page cache): Her ziyaretçide PHP'nin sıfırdan çalışmasını önler. Önbellekleme eklentisi kurulu değilse veya yanlış yapılandırılmışsa (örneğin giriş yapmış kullanıcı önbelleğe takılıyorsa) hem hız hem doğruluk sorunu yaşanır.
2. Statik dosya dağıtımı (CDN): Görsel, CSS ve JS dosyalarının ziyaretçiye coğrafi olarak yakın sunuculardan sunulması TTFB'yi düşürür, özellikle uluslararası ziyaretçisi olan siteler için kritiktir. Kurulum adımları için WordPress CDN (Cloudflare) Kurulumu rehberine bakabilirsiniz.
3. Görsel optimizasyonu: Sıkıştırılmamış, orijinal çözünürlükte yüklenen görseller LCP'yi doğrudan kötüleştirir. Modern görsel formatlarına dönüştürme ve boyut sıkıştırma, çoğu sitede ilk denenmesi gereken hızlı kazançtır.

Bu üç katmanı ayrı ayrı test edin — CDN aktifken ölçüm, kapalıyken ölçüm; önbellek eklentisi aktifken ölçüm, kapalıyken ölçüm. Böylece her katmanın gerçek katkısını rakamla görürsünüz, "eklendi ama fark etmedi" yanılgısına düşmezsiniz.

Adım 6: Kod Seviyesi Teşhis — Sorgu Profili, Debug Log ve wp-cron

Yukarıdaki adımlar sorunu daraltmadıysa, kod seviyesinde daha detaylı bir profil çıkarmak gerekir. Bunun için wp-config.php dosyasına aşağıdaki satırları ekleyerek hata ve uyarı kayıtlarını dosyaya yönlendirebilirsiniz (canlı sitede ekranda göstermeyin):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Oluşan wp-content/debug.log dosyasını inceleyerek tekrar eden uyarıları, yavaş fonksiyon çağrılarını veya eksik dosya hatalarını görebilirsiniz. Sorgu bazlı profilleme yapan bir teşhis eklentisi kullanmak (canlıda değil, staging ortamında) hangi eklentinin kaç sorgu çalıştırdığını, hangi kancanın (hook) ne kadar süre tükettiğini net şekilde gösterir — bu, "eleme testi"nden çok daha hızlı sonuç verir.

Bir diğer sık gözden kaçan nokta wp-cron'dur. WordPress'in varsayılan zamanlanmış görev sistemi, her sayfa ziyaretinde tetiklenir; yüksek trafikli sitelerde bu, gereksiz arka plan yükü oluşturabilir. wp-cron'u sunucu seviyesinde gerçek bir zamanlanmış görev (cron job) ile değiştirmek, özellikle e-ticaret ve çok içerikli sitelerde performansı belirgin şekilde iyileştirir:

// wp-config.php içine ekleyin
define( 'DISABLE_WP_CRON', true );

Bu tanımı ekledikten sonra sunucu tarafında gerçek bir zamanlanmış görev oluşturup wp-cron.php dosyasını düzenli aralıklarla tetiklemeniz gerekir; aksi halde zamanlanmış yayınlar ve eklenti görevleri çalışmaz.

Son olarak, dış servislere yapılan HTTP istekleri (ödeme entegrasyonları, hava durumu widget'ları, harici API çağrıları) sayfa yüklenirken senkron şekilde çalışıyorsa, o servis yavaşladığında sizin siteniz de yavaşlar. Bu tür entegrasyonları asenkron hale getirmek veya önbelleklemek, dış kaynaklı yavaşlamaları büyük ölçüde ortadan kaldırır.

Teşhis Sonrası: Kalıcı Çözüm İçin Kontrol Listesi

Tüm adımları tamamladıktan sonra bulgularınızı kalıcı bir bakım rutinine dönüştürün:

• Ölçüm sonuçlarını (TTFB, LCP, TBT) düzenli aralıklarla kaydedin, tek seferlik değil sürekli izleyin.
• Kullanmadığınız eklenti ve temaları silin, sadece devre dışı bırakmayın.
• Veritabanı bakımını (revizyon temizliği, transient temizliği, tablo optimizasyonu) periyodik hale getirin.
• Büyük değişiklik yapmadan önce staging ortamında test edin, canlıda doğrudan denemeyin.
• Yedekleme eklentinizin zamanlamasını trafik yoğun saatlerin dışına alın — büyük bir manuel yedekleme işlemi, sitenizi geçici olarak yavaşlatabilir. Hosting/reseller/VDS paketlerinde günlük otomatik yedekleme zaten sunucu seviyesinde çalıştığı için bu yükü panel eklentisine bindirmeden de güvenli kalabilirsiniz.
• Trafik büyüdükçe kaynak kullanım grafiklerini takip edin; sürekli tavan yapıyorsanız optimizasyon değil, ölçekleme zamanı gelmiş demektir.

Bu kontrol listesini üç ayda bir tekrarlamak, "sitem neden yavaşladı" sorusunu tekrar sormanızı büyük ölçüde önler.

Sıkça Sorulan Sorular

WordPress sitem neden aniden yavaşladı?

Ani yavaşlamalar genellikle yakın zamanda eklenen bir eklenti/entegrasyon, tema güncellemesi, trafik artışı veya bir arka plan görevinin (yedekleme, tarama, senkronizasyon) o an çalışmasıyla ilişkilidir. Değişiklik geçmişinizi kontrol ederek başlayın.

Hangi araçla hız ölçümü yapmalıyım?

Tarayıcınızın geliştirici araçlarındaki Network sekmesi ile birlikte bağımsız bir hız ölçüm servisi kullanarak TTFB, LCP ve TBT metriklerini en az üç kez ölçüp ortalamasını alın. Tek ölçüme güvenmeyin.

Önbellekleme eklentisi kurmak yeterli mi?

Hayır. Önbellekleme, LCP/TBT kaynaklı sorunları iyileştirir ama TTFB yüksekse (sunucu/veritabanı kaynaklı) etkisi sınırlı kalır. Önce kök nedeni bulmadan önbellekleme eklentisi kurmak, sorunu gizleyebilir ama çözmez.

Kaç eklenti "çok fazla" sayılır?

Sabit bir sayı yoktur; önemli olan eklenti sayısı değil, her eklentinin sayfa başına eklediği sorgu ve kod yüküdür. On hafif eklenti, üç ağır eklentiden daha az soruna yol açabilir. Eleme testiyle gerçek etkiyi ölçün.

Veritabanı optimizasyonunu ne sıklıkla yapmalıyım?

Aktif içerik üretilen sitelerde ayda bir; düşük trafikli, az güncellenen sitelerde üç ayda bir yeterlidir. Revizyon ve transient temizliğini otomatikleştiren bir rutin kurmak en pratik yoldur.

Sorun hosting kaynağından mı, yoksa yapılandırmadan mı geldiğini nasıl anlarım?

Eklenti/tema eleme testini ve veritabanı bakımını tamamladıktan sonra hâlâ kaynak kullanım grafikleriniz sürekli tavan yapıyorsa, sorun kaynaktır. Bu iki adımı atlayıp doğrudan "hosting yetersiz" sonucuna varmak yanıltıcı olabilir.

Site büyüdükçe paylaşımlı hosting yeterli kalır mı?

Trafik ve veritabanı boyutu arttıkça paylaşımlı kaynaklar sınırlı kalabilir. Bu noktada VDS gibi kendi kaynak havuzuna sahip bir çözüme geçmek, aynı optimizasyonları uygulamaya devam etmek koşuluyla belirgin bir performans farkı yaratır.

Büyükweb Hizmetleri

WordPress performans teşhisini tamamladıktan sonra hosting katmanınızı yeniden değerlendirmek isterseniz:

• WordPress Hosting — günlük otomatik yedekleme dahil, hosting ve reseller paketlerinde koşullu 7 gün iade hakkıyla deneyebileceğiniz paketler.

Sorularınız için 0850 302 60 70 numaralı satış öncesi destek numaramızdan bize ulaşabilir veya iletişim sayfası üzerinden mesaj bırakabilirsiniz.