Hız Neden Sadece Bir Teknik Mesele Değil, İş Meselesidir

WordPress sitenizin yükleme hızı, ziyaretçilerinizin sitenizde kalıp kalmayacağını belirleyen en kritik faktördür. Google’ın yaptığı araştırmaya göre, mobil sayfa yükleme süresi 1 saniyeden 3 saniyeye çıktığında terk etme (bounce) olasılığı %32 artmaktadır. Bu süre 5 saniyeye ulaştığında oran %90’a fırlar. Deloitte ve Google’ın ortak çalışması ise yükleme süresindeki yalnızca 0.1 saniyelik bir iyileşmenin perakende sitelerinde dönüşüm oranlarını %8.4, ortalama sipariş değerini ise %9.2 artırdığını ortaya koymuştur (Think with Google, 2020).

Bu rehberde, WordPress sitenizi yüzeysel “cache eklentisi kur ve unut” yaklaşımının ötesine taşıyacak, sunucu katmanından ön yüz katmanına kadar her seviyede uygulamanız gereken sistematik optimizasyon stratejilerini adım adım anlatıyoruz. Burada paylaşılan her teknik, yüzlerce WordPress projesinde test edilmiş ve sonuç vermiş uygulamalardır.

1. Core Web Vitals: Google’ın Hız Ölçütlerini Anlamak

Core Web Vitals, Google’ın 2021’den bu yana arama sıralamasında kullandığı ve gerçek kullanıcı verilerine (field data) dayanan üç temel performans metriğidir. Bu metriklerin üçünde de “iyi” eşiğini geçemeyen sayfalar, aynı içerik kalitesine sahip rakiplerinin gerisinde kalır.

LCP (Largest Contentful Paint) - Yükleme Hızı

LCP, sayfanın en büyük görsel öğesinin (hero görseli, ana başlık bloğu) render edildiği anı ölçer. Google’ın belirlediği eşik değer ≤2.5 saniyedir. HTTP Archive 2024 verilerine göre, mobil sayfaların yalnızca %59’u bu eşiği geçebilmektedir. Bu, WordPress sitelerinin büyük çoğunluğunun LCP konusunda ciddi sorunlar yaşadığı anlamına gelir.

LCP’yi iyileştirmenin en etkili yolu, sayfadaki en büyük görselin tarayıcı tarafından erken keşfedilmesini sağlamaktır. Google Chrome ekibi mühendislik lideri Addy Osmani’nin belirttiği gibi: “Hızlı bir LCP için ana hero görselinizi erken talep edin, srcset ve verimli modern görsel formatları kullanın, ekran dışı görselleri lazy-load ile yükleyin.”

INP (Interaction to Next Paint) - Etkileşim Yanıt Süresi

INP, Mart 2024’te First Input Delay (FID) metriğinin yerini almıştır. Kullanıcının sayfayla etkileşime geçtiğinde (tıklama, dokunma) tarayıcının ne kadar sürede görsel bir yanıt ürettiğini ölçer. Eşik değer ≤200 milisaniyedir. WordPress’in bu alandaki performansı 2023’te %69 olan “iyi” oranından, 2024’te %82’ye yükselmiştir (HTTP Archive, Web Almanac 2024).

CLS (Cumulative Layout Shift) - Görsel Kararlılık

CLS, sayfa yüklenirken öğelerin beklenmedik şekilde kaymasını (layout shift) ölçer. “İyi” eşiği ≤0.1’dir. WordPress siteleri bu metrikte 2023’te %77 olan “iyi” oranını 2024’te %82’ye çıkarmıştır. CLS sorunlarının en yaygın nedeni, boyutu belirtilmemiş görseller ve geç yüklenen reklamlardır.

2. Görsel Optimizasyonu: LCP’nin Kalbindeki Sorun

Optimize edilmemiş görseller, WordPress sitelerindeki hız sorunlarının bir numaralı sebebidir. Tipik bir WordPress sitesinde toplam sayfa ağırlığının %50-65’i görsellerden oluşur. Bu görsellerin formatı, boyutu ve yüklenme sırası doğrudan LCP skorunuzu belirler.

Modern Görsel Formatlarına Geçiş: WebP ve AVIF

JPEG ve PNG formatları artık modern web için verimsizdir. WebP formatı aynı görsel kalitesinde JPEG’e kıyasla %25-35 daha küçük dosya boyutu sunar. AVIF formatı ise WebP’den bile %20 daha verimlidir. WordPress sitenizde bu formatlara geçmek için iki yol vardır:

  1. Sunucu taraflı dönüştürme: Nginx veya Apache modülleri ile istekleri otomatik olarak WebP/AVIF’e yönlendirme.
  2. WordPress eklentisi: ShortPixel veya Imagify gibi araçlar yüklenen her görseli otomatik olarak modern formata dönüştürür ve orijinali yedekler.

Responsive Images ve srcset Kullanımı

Tek bir büyük görsel yerine, ekran boyutuna göre farklı çözünürlüklerde görseller sunmak hem bant genişliğini korur hem de LCP’yi dramatik biçimde iyileştirir:

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px"
  alt="WordPress hız optimizasyonu sonuçları"
  width="1200"
  height="630"
  loading="eager"
  fetchpriority="high"
/>

Dikkat edilmesi gereken kritik nokta: Hero görseli (above-the-fold) için loading="eager" ve fetchpriority="high" kullanın. Bu iki attribute, tarayıcıya “bu görseli diğer her şeyden önce indir” mesajını verir. Ekranın altındaki görseller için ise loading="lazy" kullanarak gereksiz ağ trafiğini ortadan kaldırın.

Görsellere width ve height Tanımlamak (CLS Önlemi)

Her <img> etiketine mutlaka width ve height attribute’ları ekleyin. Tarayıcı bu bilgileri kullanarak görsel yüklenmeden önce gerekli alanı ayırır ve CLS (layout shift) sorununu kökten çözer.

3. Render-Blocking CSS ve JavaScript Eliminasyonu

Tarayıcı, sayfanın HTML’ini yukarıdan aşağıya okurken <head> bölümünde karşılaştığı her CSS ve JavaScript dosyasını indirip işleyene kadar sayfayı render edemez. Bu durum “render-blocking” olarak adlandırılır ve LCP ile INP’yi doğrudan yükseltir.

Critical CSS (Kritik CSS) Yöntemi

Sayfanın ilk ekranda (above-the-fold) görünen bölümü için gerekli olan minimal CSS’i doğrudan <head> içine inline olarak yerleştirin. Geri kalan CSS dosyalarını media="print" trick’i veya rel="preload" ile asenkron yükleyin:

<head>
  <style>
    /* Sadece above-the-fold için gereken minimal CSS */
    body { font-family: system-ui, sans-serif; margin: 0; }
    .hero { max-width: 1200px; margin: 0 auto; }
  </style>
  <link rel="preload" href="/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/style.css"></noscript>
</head>

JavaScript Defer ve Async Stratejisi

WordPress ekosisteminde en yaygın INP sorunlarının kaynağı, <head> bölümüne senkron olarak yüklenen üçüncü parti JavaScript dosyalarıdır (analytics, chat widget, reklam scriptleri). Bu dosyaların tamamına defer veya async attribute’ü eklenmeli, mümkünse Intersection Observer API ile yalnızca kullanıcı ilgili alana scroll ettiğinde yüklenmelidir.

WordPress temanızın functions.php dosyasında scriptleri footer’a taşımanın en güvenli yolu:

function move_scripts_to_footer() {
    remove_action('wp_head', 'wp_print_scripts');
    remove_action('wp_head', 'wp_print_head_scripts', 9);
    add_action('wp_footer', 'wp_print_scripts', 5);
    add_action('wp_footer', 'wp_print_head_scripts', 5);
}
add_action('after_setup_theme', 'move_scripts_to_footer');

4. Veritabanı Optimizasyonu: Gizli Performans Katili

WordPress veritabanı zamanla şişer. Post revision’lar, spam yorumlar, transient’lar, otomatik taslaklar ve en tehlikelisi wp_options tablosundaki gereksiz autoload verileri sunucu yanıt süresini (TTFB) dramatik biçimde yükseltir.

wp_options Tablosu ve Autoload Sorunu

WordPress her sayfa yüklemesinde wp_options tablosundaki autoload='yes' olarak işaretlenmiş tüm satırları belleğe alır. Düzinelerce eklenti kurulup kaldırıldığında, bu tabloda yüzlerce artık (orphaned) autoload kaydı birikir. Bu verilerin boyutu 1 MB’ı aştığında TTFB ciddi şekilde etkilenir.

Autoload verilerini denetlemek için şu SQL sorgusunu kullanabilirsiniz:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

Bu sorgunun sonucu 500 KB’ın üzerindeyse temizlik yapmanız gerekir. Hangi eklentilerin en fazla autoload verisi bıraktığını görmek için:

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

Transient ve Revision Temizliği

Post revision’lar varsayılan olarak sınırsız tutulur. Yıllardır yayında olan bir sitede tek bir yazının 50’den fazla revision’ı olabilir. wp-config.php dosyanıza şu satırı ekleyerek revision sayısını sınırlandırın:

define('WP_POST_REVISIONS', 5);

Mevcut eski revision’ları temizlemek için WP-CLI kullanabilirsiniz:

wp post delete $(wp post list --post_type=revision --format=ids) --force

5. Önbellekleme (Cache) Katmanları: Doğru Strateji

Bir cache eklentisi kurmak, hız optimizasyonunun yalnızca başlangıç noktasıdır. Profesyonel bir WordPress hız optimizasyonunda dört ayrı önbellekleme katmanı birlikte çalışmalıdır:

Katman 1: Opcode Cache (PHP Seviyesi)

PHP dosyaları her istekte yeniden derlenmek yerine, OPcache aracılığıyla derlenmiş bytecode olarak bellekte tutulur. Bu, PHP işleme süresini %50-70 oranında azaltır. Hosting sağlayıcınızın OPcache’i aktif edip etmediğini kontrol edin ve php.ini dosyanızda şu ayarları doğrulayın:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60

Katman 2: Object Cache (Veritabanı Seviyesi)

WordPress, her sayfa yüklemesinde onlarca veritabanı sorgusu çalıştırır. Redis veya Memcached gibi bir in-memory object cache kullanarak bu sorguların sonuçlarını RAM’de tutabilir ve tekrar eden sorgularda veritabanına hiç gitmeden yanıt verebilirsiniz. Object cache, özellikle WooCommerce gibi veritabanı ağırlıklı sitelerde TTFB’yi 200-500ms iyileştirebilir.

Katman 3: Page Cache (Uygulama Seviyesi)

WP Rocket, LiteSpeed Cache veya W3 Total Cache gibi eklentiler, dinamik PHP sayfalarını statik HTML dosyalarına dönüştürerek sunucunun her istekte PHP ve MySQL çalıştırma ihtiyacını ortadan kaldırır. Bu katman, anonim ziyaretçiler için TTFB’yi 50ms altına düşürebilir.

Katman 4: CDN (Ağ Seviyesi)

Cloudflare, Bunny CDN veya Fastly gibi bir CDN (Content Delivery Network), statik dosyalarınızı (görseller, CSS, JS, fontlar) dünya genelindeki edge sunuculara dağıtarak ziyaretçinin fiziksel olarak en yakın sunucudan içerik almasını sağlar. Türkiye’deki bir ziyaretçi için Avrupa edge sunucusundan yanıt almak, ABD’deki origin sunucuya kıyasla 100-300ms kazandırır.

6. PHP Sürümü ve Sunucu Yapılandırması

PHP sürümünüz, WordPress performansınızı doğrudan etkiler. PHP 7.4 kullanan bir site, PHP 8.2’ye geçtiğinde sırf bu yükseltme sayesinde %15-25 hız artışı elde edebilir. PHP 8.3 ise JIT (Just-in-Time) derleyici iyileştirmeleriyle bu farkı daha da açar.

PHP Sürümünüzü Kontrol Edin

WordPress yönetici panelinde Araçlar → Site Sağlığı bölümünden PHP sürümünüzü kontrol edebilirsiniz. PHP 7.4 veya altındaysanız, acil güncelleme yapmanız gerekir. Güncellemeden önce:

  1. Tüm eklenti ve temaların PHP 8.x uyumluluğunu kontrol edin.
  2. Staging ortamında test yapın.
  3. Tam yedek alın (veritabanı + dosyalar).
  4. Hosting panelinden PHP sürümünü yükseltin.

Gzip/Brotli Sıkıştırma

Sunucunuzda Gzip veya daha modern olan Brotli sıkıştırmayı aktif ederek, transfer edilen dosya boyutlarını %60-80 oranında küçültebilirsiniz. Nginx için Brotli konfigürasyonu:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

7. Font Optimizasyonu: Görünmez Metin Sorunu

Web fontları, düzgün yönetilmezse hem LCP’yi hem CLS’yi olumsuz etkiler. Tarayıcı özel fontu indirene kadar metin ya hiç görünmez (FOIT - Flash of Invisible Text) ya da sistem fontuyla gösterilip sonra değişir (FOUT - Flash of Unstyled Text).

font-display: swap Kullanımı

CSS’inizdeki @font-face kurallarına font-display: swap ekleyerek, tarayıcının font yüklenene kadar sistem fontuyla metni göstermesini sağlayın. Bu, LCP’nin font indirme süresinden bağımsız hale gelmesini sağlar:

@font-face {
  font-family: 'DM Sans';
  src: url('/fonts/dm-sans.woff2') format('woff2');
  font-display: swap;
}

Font Dosyalarını Preload ile Erken Yükleme

Sayfada kullanılan ana font dosyasını <link rel="preload"> ile erken keşfettirin:

<link rel="preload" href="/fonts/dm-sans.woff2" as="font" type="font/woff2" crossorigin>

Self-Hosting vs Google Fonts CDN

Google Fonts CDN kullanmak yerine font dosyalarını kendi sunucunuzda barındırmak (self-hosting), üçüncü parti DNS çözümleme süresini ortadan kaldırır ve GDPR uyumluluğunu sağlar. google-webfonts-helper aracını kullanarak Google Fonts’tan istediğiniz fontu WOFF2 formatında indirip doğrudan projenize ekleyebilirsiniz.

8. Eklenti Sayısını Azaltma: Her Eklenti Bir Maliyet

Sitenize eklediğiniz her WordPress eklentisi, en az bir CSS dosyası, bir JavaScript dosyası ve birkaç veritabanı sorgusu demektir. 40-50 eklentili bir sitede, bu “küçük” maliyetler birikir ve sayfa yükleme süresini 2-3 saniye artırır.

Eklenti Audit Süreci

  1. Query Monitor eklentisini kurun ve her eklentinin kaç veritabanı sorgusu çalıştırdığını, ne kadar bellek tükettiğini ve hangi sayfada hangi scriptleri yüklediğini analiz edin.
  2. Gereksiz eklentileri silin: SEO eklentisi + cache eklentisi + güvenlik eklentisi + analitik eklentisi = 4 eklenti zaten yeterlidir.
  3. Kodla değiştirin: Google Analytics kodu, basit yönlendirmeler, özel CSS eklemeleri ve sosyal medya ikonları gibi basit işlevler functions.php veya temanız üzerinden direkt kodlanabilir.

Eğer sitenizde 30’dan fazla aktif eklenti varsa, profesyonel bir eklenti auditi yaptırmanız şiddetle önerilir. WordPress siteniz yavaş mı çalışıyor? Sorun sayfamız bu konuda derinlemesine bilgi sunmaktadır.

9. Performans İzleme ve Sürekli Optimizasyon

Hız optimizasyonu, bir kere yapılıp unutulacak bir iş değildir. Her yeni eklenti güncellemesi, her yeni blog yazısı ve her yeni görsel yüklemesi performansınızı etkileyebilir. Bu yüzden sürekli izleme sistemi kurmanız gerekir.

Önerilen İzleme Araçları

  • Google Search Console → Core Web Vitals raporu: Gerçek kullanıcı verilerine (CrUX) dayalı performans takibi.
  • PageSpeed Insights: Hem lab hem field verilerini tek ekranda gösteren Google aracı.
  • WebPageTest.org: Farklı lokasyonlardan ve farklı cihazlardan detaylı waterfall analizi.
  • SpeedVitals: Aylık otomatik performans raporları ve trend analizi.

Aylık Performans Checklist

Her ay aşağıdaki kontrol listesini uygulayın:

  1. PageSpeed Insights’ta mobil ve masaüstü skorları kontrol edin.
  2. wp_options autoload boyutunu SQL sorgusuyla denetleyin.
  3. Kullanılmayan eklentileri tespit edip silin.
  4. Yeni yüklenen görsellerin WebP/AVIF formatında olduğunu doğrulayın.
  5. PHP sürümünün güncel olduğunu kontrol edin.

Sonuç ve Eylem Planı

WordPress hız optimizasyonu, tek bir eklenti kurarak çözülebilecek bir sorun değildir. Kalıcı performans kazanımı, sunucu katmanından (PHP sürümü, OPcache, Object Cache) uygulama katmanına (veritabanı temizliği, eklenti auditi) ve ön yüz katmanına (görsel optimizasyonu, critical CSS, font yönetimi) kadar her seviyede sistematik bir yaklaşım gerektirir.

Bu rehberdeki adımları uyguladığınızda, tipik bir WordPress sitesinin PageSpeed skorunu 30-40 bandından 90+ bandına taşımanız teknik olarak mümkündür. Ancak her sitenin mimarisi, eklenti yapısı ve hosting altyapısı farklıdır. Profesyonel bir analiz, optimizasyon sürecini doğru başlangıç noktasından başlatır ve gereksiz deneme-yanılma sürecini ortadan kaldırır.

Sitenizin mevcut hız durumunu profesyonel olarak analiz ettirmek ve somut bir aksiyon planı almak için hız optimizasyonu hizmetimizi inceleyebilirsiniz. WordPress hosting limitlerinden kaynaklanan sorunlarınız varsa hosting limit sorunları sayfamız da size yol gösterecektir.

Uzman Görüşü

"For a fast LCP: request your key hero image early, use srcset and efficient modern image formats, and lazy-load offscreen images. (Hızlı bir LCP için: ana hero görselinizi erken talep edin, srcset ve verimli modern görsel formatları kullanın, ekran dışı görselleri lazy-load ile yükleyin.)"
Addy Osmani Engineering Lead @ Google Chrome Kaynağa Git →

Sıkça Sorulan Sorular

WordPress sitemi nasıl hızlandırırım?

WordPress hızlandırma işlemi üç temel katmandan oluşur: sunucu altyapısı (PHP sürümü, object cache, CDN), uygulama katmanı (veritabanı temizliği, eklenti sayısını azaltma, render-blocking kaynakları eliminasyonu) ve ön yüz katmanı (görsel optimizasyonu, lazy loading, critical CSS). Bu üç katman birlikte optimize edilmediğinde kalıcı hız kazanımı sağlanamaz.

Core Web Vitals nedir ve neden önemlidir?

Core Web Vitals, Google'ın sayfa deneyimini ölçmek için belirlediği üç metrikten oluşur: LCP (yükleme hızı, eşik ≤2.5s), INP (etkileşim yanıt süresi, eşik ≤200ms) ve CLS (görsel kararlılık, eşik ≤0.1). Bu metriklerin üçünde de 'iyi' skora sahip sayfalar, Google sıralamasında doğrudan avantaj elde eder.

WordPress'te en çok hız kaybettiren şey nedir?

HTTP Archive 2024 verilerine göre, WordPress sitelerinde en yaygın hız sorunları sırasıyla optimize edilmemiş görseller (LCP'yi doğrudan etkiler), aşırı JavaScript yükü (INP'yi yükseltir) ve çok sayıda gereksiz eklenti (hem sunucu hem istemci tarafında kaynak tüketir). Bu üç faktör tek başına PageSpeed skorunuzu 30-40 puan düşürebilir.

Önbellekleme (cache) eklentisi yeterli mi?

Hayır. Bir cache eklentisi yalnızca sunucu tarafı yanıt süresini (TTFB) iyileştirir. Ancak LCP sorunları genellikle görsellerin geç yüklenmesinden, INP sorunları ise ağır JavaScript'ten kaynaklanır. Kalıcı hız için cache + CDN + görsel optimizasyonu + JavaScript eliminasyonu birlikte uygulanmalıdır.