WordPress Hızlandırma: Adım Adım Kontrol Listesi

WordPress sitesini hızlandırmanın doğru sırası şudur: önce ölçün, sonra sunucu ve PHP sürümünü düzeltin, ardından sayfa önbelleğini, veritabanını, görselleri ve CDN’i ele alın. Sıra önemli, çünkü yavaş bir sunucuda görsel sıkıştırmak sonucu çok az değiştirir.

Bu liste her adımda ne yapacağınızı, hangi komutla kontrol edeceğinizi ve işe yaradığını nasıl göreceğinizi verir. Elementor kullanıyorsanız ona özgü ayarlar için Elementor hız optimizasyonu yazısına bakın; burada tüm WordPress sitelerini ilgilendiren katmanlar var.

WordPress hızlandırmadan önce ölçüm alın

Ölçüm almadan değişiklik yaparsanız neyin işe yaradığını bilemezsiniz. Başlangıç değerlerini bir tabloya yazın.

Hangi değerler?

TTFB eşiği için web.dev TTFB rehberine, diğer üçü için Core Web Vitals sayfasına bakın.

Nasıl ölçülür?

1. PageSpeed Insights ile ana sayfanızı ve en çok trafik alan bir yazıyı mobil modda ölçün. Aynı sayfayı üç kez ölçüp ortalama alın.

2. TTFB’yi doğrudan komut satırından da okuyabilirsiniz:

   curl -o /dev/null -s -w 'TTFB: %{time_starttransfer} sn\n' https://ornek.com/

3. Çıktıları ve tarihi bir yere kaydedin. Her adımdan sonra aynı sayfaları aynı şekilde yeniden ölçün.

Sonuç ilk istekte yavaş, sonrakilerde hızlıysa sayfa önbelleğiniz çalışıyor ama ısınmamış demektir. Bu yüzden önbellek ölçümünü ikinci istekten başlatın.

WordPress hızlandırma için sunucu ve PHP sürümü

Sunucu yanıt süresi her şeyin tabanıdır. Burada iki şeye bakın: PHP sürümü ve sunucu kaynakları.

PHP sürümü

php.net’e göre 27 Ekim 2026 itibarıyla desteklenen sürümler şöyle:

WordPress hosting el kitabı, üretimde PHP 8.4 veya üstünü öneriyor. WordPress 7.0 ile asgari sürüm 7.4 oldu; ayrıntı için WordPress 7.0 yenilikleri yazısına bakın. Kullandığınız sürümü şöyle görürsünüz:

php -v
wp --info

Eklentilerle uyumsuzluk riski olduğundan sürümü önce test ortamında yükseltin, sonra canlıda. Bu yolla yüklenme süresinde kazanç olup olmadığını, başlangıç ölçümüyle karşılaştırarak görün; kazancın büyüklüğü site ve eklentilere göre değişir, bu yüzden oran verilmiyor.

OPcache ve bellek

• OPcache, derlenmiş PHP kodunu bellekte tutar ve WordPress hosting el kitabında önerilen eklentiler arasındadır. Açık olup olmadığını hosting panelinden veya Araçlar > Site Sağlığı > Bilgi ekranından kontrol edin.
• memory_limit için çekirdek bir alt sınır belirlemiyor; hosting el kitabı 128M’yi yalnızca eklentisiz bir kurulum için yeterli sayıyor ve 256M’yi öneriyor. Sayfa oluşturucu, WooCommerce gibi ağır siteler için 512M ve üstü anılıyor.
• MySQL/MariaDB: El kitabı MySQL 8.4 LTS ile MariaDB 11.8, 11.4 ve 10.11 LTS sürümlerini öneriyor. Listede yer alan MySQL 8.0’ın (Nisan 2026) ve MariaDB 10.6’nın (Temmuz 2026) yaşam sonu tarihleri geçti; bu sürümlerdeyseniz hosting sağlayıcınıza yükseltme planını sorun.

Paylaşımlı hostingde bunları değiştiremiyorsanız, TTFB sürekli 1,8 saniyenin üstündeyse (web.dev bunu “kötü” sayıyor) sağlayıcı değiştirmek en etkili adım olabilir.

Önbellek: sayfa, nesne ve tarayıcı

Üç farklı önbellek var ve her biri farklı sorunu çözer.

Sayfa önbelleği

WordPress her istekte PHP çalıştırıp veritabanını sorgular. Sayfa önbelleği hazır HTML sunarak bu işi atlar. Hosting sağlayıcınızın sunucu düzeyinde önbelleği varsa onu kullanın; yoksa güvenilir bir önbellek eklentisi seçin. Yalnızca birini kullanın; iki önbellek katmanı çakışabilir.

Çalıştığını doğrulamak için iki kez istek atıp süreleri karşılaştırın:

curl -o /dev/null -s -w '1. istek: %{time_starttransfer} sn\n' https://ornek.com/
curl -o /dev/null -s -w '2. istek: %{time_starttransfer} sn\n' https://ornek.com/
curl -sI https://ornek.com/ | grep -i -E 'cache|age'

İkinci istek belirgin biçimde hızlıysa ve başlıklarda önbellekle ilgili bir alan (cache-control, age ya da sağlayıcıya özgü bir x-cache alanı) varsa önbellek çalışıyor. Alan adları sağlayıcıya göre değiştiği için kendi çıktınıza bakın. Giriş yapmış kullanıcılar ve sepet gibi sayfalar önbellekten dışlanmalıdır.

Nesne önbelleği

Nesne önbelleği, veritabanı sorgu sonuçlarını bellekte tutar. WordPress hosting el kitabı APCu, Memcached ve Redis’i öneriyor; bunlardan yalnızca biri yeterli. Dinamik sitelerde (üyelik, mağaza, çok sorgulu admin) sayfa önbelleğinin yetmediği yerde işe yarar. Hosting sağlayıcınız sunuyorsa genellikle panelden açılır; sonra WP-CLI ile sürücüyü kontrol edin:

wp cache type

Çıktıda Redis ya da Memcached gibi bir tür görmeniz, kalıcı nesne önbelleğinin bağlı olduğunu gösterir.

Tarayıcı önbelleği

Görsel, CSS ve JavaScript gibi statik dosyalara uzun Cache-Control süresi verirseniz ziyaretçinin tarayıcısı bunları tekrar indirmez. Ayar sunucuda (Apache, Nginx, LiteSpeed) ya da CDN’de yapılır. Kontrol:

curl -sI https://ornek.com/wp-content/themes/tema-adi/style.css | grep -i cache-control

Dosya adlarında sürüm parametresi varsa (?ver=...) uzun süre güvenle verilebilir.

Veritabanı temizliği

Veritabanı, her sayfa isteğinde yüklenen “autoload” seçenekleri yüzünden yavaşlayabilir. Şunlara bakın:

1. Autoload verisinin toplam boyutu:

   wp option list --autoload=on --format=total_bytes

   Değeri not edin, sonra en büyük seçeneklere bakın:

   wp option list --autoload=on --fields=option_name,size_bytes --format=csv | sort -t, -k2 -n -r | head -n 15

   Büyük kalemler çoğunlukla artık kullanılmayan eklentilerden kalır. Neyi sildiğinizi bilmeden silmeyin; önce yedek alın.

2. Süresi dolmuş geçici veriler:

   wp transient delete --expired

3. Revizyon sayısını sınırlayın. wp-config.php içine ekleyin:

   define( 'WP_POST_REVISIONS', 5 );

   Bu yalnızca yeni kayıtları sınırlar; eski revizyonlar yerinde kalır.

4. Tabloları iyileştirin:

   wp db optimize

Her adımdan önce wp db export yedek.sql ile yedek alın. Doğrulama: aynı total_bytes komutunu tekrar çalıştırın ve TTFB’yi yeniden ölçün.

Görselleri küçültme

Sayfaların çoğunda ağırlığın büyük kısmı görsellerdir.

• Doğru boyut ve format: Sitede 800 piksel genişlikte görünen görseli 4000 piksel olarak yüklemeyin; yüklemeden önce yeniden boyutlandırın. WebP ve AVIF aynı kalitede JPEG’den küçük dosya üretir. WordPress 7.1, tarayıcıda görsel işlemeyi ve AVIF ile HEIC için yerel desteği getirdi; sürümünüz 7.1’in altındaysa dönüştürmeyi yüklemeden önce yapın ya da bir optimizasyon eklentisi kullanın.

• Imagick: WordPress hosting el kitabı imagick eklentisini önerilen eklentiler arasında sayıyor ve daha iyi görsel kalitesi sağladığını belirtiyor; yoksa WordPress sınırlı özellikli GD’ye döner. Kurulu olup olmadığını Site Sağlığı > Bilgi > Ortam ekranından görürsünüz.

• Tembel yükleme: Ekranın altındaki görseller loading="lazy" ile yüklenmelidir, ama sayfanın en büyük görseline (LCP öğesi) tembel yükleme eklemeyin; gecikir. Sayfa kaynağında ilk büyük görselin loading="lazy" taşıyıp taşımadığına bakın.

• Yeniden oluşturma: Tema boyutlarını değiştirdiyseniz mevcut görselleri yeniden üretin:

  wp media regenerate --yes

  Büyük kütüphanede uzun sürer, önce yedek alın.

Doğrulama: PageSpeed Insights raporunda “Görselleri doğru boyutlandırın” ve “Yeni nesil biçimlerde görseller sunun” uyarılarının kalkmasına ve LCP değerinin düşmesine bakın.

CDN kullanımı

CDN, statik dosyaları ziyaretçiye coğrafi olarak yakın sunuculardan verir. Ziyaretçileriniz sunucunuzdan uzaktaysa (örneğin sunucu yurt dışında, ziyaretçi Türkiye’de) fark yaratır. Kurulumdan sonra:

1. Statik dosyaların CDN adresinden geldiğini tarayıcı Ağ sekmesinden kontrol edin.
2. Sayfa önbelleği güncellendiğinde CDN önbelleğini de temizlemeyi öğrenin; eski dosya görünüyorsa sebep genellikle odur.
3. TTFB ve LCP’yi tekrar ölçün.

Sunucunuz zaten ziyaretçilere yakınsa ve görseller küçükse CDN’in katkısı küçük kalır. Önce önceki adımları bitirin.

Eklenti ve tema yükünü gözden geçirme

Eklenti sayısı tek başına ölçüt değildir; her eklentinin her sayfada ne yüklediği önemlidir.

wp plugin list --status=active --fields=name,version

Listeyi gözden geçirip kullanmadıklarınızı devre dışı bırakın ve her kapatışta TTFB ve PageSpeed ölçümünü karşılaştırın. Bir eklentinin kapatılması farkı gösteriyorsa yerine daha hafif bir alternatif arayın. Yalnızca bazı sayfalarda gereken eklentilerin diğer sayfalarda script yüklememesi gerekir.

Üçüncü taraf script’ler ve ön yüz

Sunucu hızlı olsa bile tarayıcıda çalışan script’ler etkileşimi (INP) ve yüklenmeyi yavaşlatabilir. Sayfa kaynağından ya da tarayıcının Ağ sekmesinden şunlara bakın:

• Analitik, sohbet, reklam ve sosyal medya script’lerinden hangileri her sayfada yükleniyor?
• Kullanmadığınız yazı tipi ailesi ya da ağırlığı var mı? Gerekenden fazla yazı tipi dosyası indirmek LCP’yi geciktirir.
• İletişim formu gibi tek sayfada gereken script ve stiller tüm sitede yükleniyor mu?
• Slider, popup ve animasyon eklentileri gerçekten gerekli mi?

Her kalemi kaldırdığınızda ya da yalnızca gereken sayfaya sınırladığınızda PageSpeed’i yeniden ölçün. Etkisi küçük olanı geri alıp bırakmak yerine tutmayın; her script bir bakım yüküdür.

Yapmamanız gerekenler

• Yedeksiz veritabanı temizliği. Autoload ve geçici veri temizliği geri alınamaz.
• Giriş yapılmış sayfaları önbelleğe almak. Kullanıcıya özel içerik başkasına görünebilir.

Elementor ya da benzeri bir sayfa oluşturucu kullanıyorsanız ek yük kaynakları farklıdır; onlar için Elementor hız optimizasyonu rehberini ayrıca uygulayın.

Sonuç ölçümü: önce ve sonra

Tüm adımları tamamladıktan sonra başlangıçta yazdığınız tabloyu yeniden doldurun:

Laboratuvar ölçümleri (PageSpeed’in simülasyonu) hemen değişir; gerçek kullanıcı verisi (Chrome kullanıcı deneyimi raporu) yaklaşık 28 günlük pencereyle güncellenir. Değişikliğin gerçek ziyaretçilerde görünmesi zaman alır.

Sitenizin neden yavaş olduğunu kendiniz çözemiyorsanız hız optimizasyonu hizmetimi inceleyebilir ya da sitenizin adresini iletişim sayfasından gönderebilirsiniz.

Sonuç

WordPress hızlandırmada en büyük kazanç genellikle üç yerden gelir: güncel PHP ve yeterli sunucu, çalışan bir sayfa önbelleği, boyutlandırılmış görseller. Veritabanı temizliği ve CDN bunların üstüne eklenir. Her adımı tek tek yapıp ölçerseniz hangisinin işe yaradığını görürsünüz.