Temel çıkarım: WordPress'te düşük bir PageSpeed Insights skoru neredeyse her zaman aynı birkaç nedene dayanır — optimize edilmemiş görseller, render-blocking scriptler ve cache eksikliği. Bunları sırayla düzelt, her değişiklikten sonra yeniden test et; çoğu site hosting yükseltmesi veya tema yeniden yazımı olmadan kırmızıdan yeşile geçer.
WordPress Siteleri PageSpeed Insights'ta Neden Düşük Puan Alır
WordPress, eklenti, page builder ve üçüncü taraf script eklemeyi kolaylaştırıyor — her biri kendi CSS'ini, JavaScript'ini, bazen de harici isteklerini ekliyor. Bir page builder, birkaç pazarlama eklentisi ve optimize edilmemiş medyaya sahip varsayılan bir kurulum, tek bir sayfa için kolayca 3-4MB varlık gönderebilir.
PageSpeed Insights, test ettiğin her URL'de iki ayrı analiz çalıştırır:
- Lab verisi: Google'ın sunucularında sabit ağ ve cihaz koşulları altında anında çalıştırılan simüle edilmiş bir Lighthouse denetimi. Belirli sorunları yakalamak için faydalı ama bir anlık görüntü, gerçek kullanıcı davranışı değil.
- Field verisi: Chrome User Experience Report'tan (CrUX) alınan, siteni son 28 günde ziyaret eden gerçek Chrome kullanıcılarından gelen gerçek ölçümler. Bu sadece sitenin yeterli Chrome trafiğine sahip olması durumunda görünür.
Bir site lab'da 95 alıp field verisinde hâlâ "poor" (zayıf) görünebilir — genellikle gerçek kullanıcıların lab simülasyonunun varsaydığından daha yavaş bağlantılarda veya daha eski cihazlarda olması yüzünden. İkisi de önemli, ama Search Console'un Core Web Vitals raporu field verisini kullanıyor, yani arama sıralama sinyallerine bağlı olan bu.
Skoru Gerçekten Değiştiren Sıra
Bunları sırayla uygula — her biri genellikle bir sonrakinden daha büyük etkiye sahip, o yüzden sırayı bozmak önce küçük kazanımlar için zaman kaybettirir.
1. Önce görselleri düzelt
Ortalama bir WordPress sayfasında görseller, toplam sayfa ağırlığının %50-80'ini oluşturur. Bu neredeyse her zaman en yüksek etkili tek düzeltme ve genellikle kırmızı bir Largest Contentful Paint (LCP) skorunu tetikleyen şey — çünkü çoğu sayfada LCP öğesi bir hero görseli, öne çıkan görsel veya katlama üstü ürün fotoğrafıdır.
Katlama üstündeki her görselde kontrol edilmesi gereken üç şey:
- Format — hâlâ ham JPEG veya PNG mi? WebP, eşdeğer kalitede kabaca %25-35 daha küçüktür, AVIF ise JPEG'e kıyasla genellikle boyutu yarıya indirir.
- Boyutlar — 4000px genişliğindeki bir fotoğraf 800px'lik bir kapsayıcıya mı sıkıştırılıyor? Tarayıcı, küçültmeden önce tüm dosyayı indirmek zorunda kalır.
- Yükleme önceliği — LCP görseli yanlışlıkla
loading="lazy"olarak mı işaretlenmiş? Bu, gördüğümüz en yaygın hatalardan biri: bir "hız" eklentisi, hero görseli de dahil sayfadaki her görseli lazy-load yapıyor.
Bunu Core Web Vitals görsel checklist'imizde ve WebP dönüştürme rehberimizde daha derinlemesine ele alıyoruz. Erdo Image Optimizer, format dönüşümünü ve lazy-loading düzeltmesini sunucunun kendi GD veya Imagick kütüphanesini kullanarak otomatik olarak yapar — harici API veya aylık kota yok.
2. Render-blocking CSS ve JavaScript'i ortadan kaldır
<head> içindeki async, defer veya bir media query olmadan her <script> ve <link rel="stylesheet">, tarayıcının indirip (scriptler için) çalıştırana kadar sayfayı render etmesini engeller. Page builder'lar ve çok amaçlı temalar burada sık suçlu — genellikle kullanılmayan sayfalarda bile tam bir ikon kütüphanesi veya animasyon framework'ü yüklerler.
Çözüm her zaman "eklentiyi kaldır" değildir — genellikle kritik olmayan scriptleri ertelemek ve ilk ekran için gereken az miktardaki CSS'i inline yapmak yeterlidir. Çoğu cache ve performans eklentisinin bunun için bir ayarı var; etkinleştirdikten sonra dikkatli test et, çünkü agresif erteleme bazen yükleme sırasına bağımlı bir scripti bozabilir.
3. Sunucu tarafı ve tarayıcı cache'ini aç
Her tek istekte PHP ve MySQL tarafından yeniden oluşturulması gereken bir sayfa, Time to First Byte (TTFB)'ye yüzlerce milisaniye ekler, bu da LCP dahil sonrasındaki her şeyi geciktirir. Sayfa cache'i (tekrar ziyaretçilere önceden oluşturulmuş statik bir HTML dosyası sunmak) ve object cache (tekrarlanan veritabanı sorgularından kaçınmak) ikisi de değerlidir, çoğu cache eklentisi ikisini de makul varsayılanlarla yapılandırır.
Bu adım önemli, ama nadiren en büyük skor belirleyicisi — iyi cache'lenmiş 2MB'lık sıkıştırılmamış bir hero görsele sahip bir sayfa hâlâ LCP'de başarısız olur.
4. Eklenti sayısını ve kalitesini denetle
Eklenti sayısının kendisi doğal olarak bir performans sorunu değildir — sadece gerektiği yerde varlıklarını yükleyen iyi kodlanmış bir eklenti çok az maliyete sahiptir. Asıl sorun, mevcut sayfanın kullanıp kullanmadığına bakmaksızın CSS/JS'i site genelinde yükleyen eklentilerdir. On tane hafif, iyi kapsamlı eklenti, iki tane kötü kodlanmış eklentiden daha az sorunludur.
Pratik bir denetim: Chrome DevTools → Network sekmesini aç, yavaş bir sayfayı yeniden yükle ve boyuta göre sırala. Beklenmedik şekilde büyük olan her şey araştırmaya değer — onu yükleyen eklenti veya tema bileşenine kadar takip et.
Hızlı Referans: Core Web Vitals Eşikleri
| Metrik | İyi | İyileştirme Gerekli | Zayıf |
|---|---|---|---|
| LCP (Largest Contentful Paint) | 2,5 saniyenin altı | 2,5s – 4s | 4 saniyeden fazla |
| INP (Interaction to Next Paint) | 200ms altı | 200ms – 500ms | 500ms'den fazla |
| CLS (Cumulative Layout Shift) | 0,1 altı | 0,1 – 0,25 | 0,25'ten fazla |
Bunlar Google'ın yayınladığı, gerçek ziyaretlerin 75. yüzdelik diliminde ölçülen eşikler — yani metriğin geçmesi için ziyaretçilerinin dörtte üçünün "İyi" aralığına düşmesi gerekiyor.
Uygulamalı Bir Örnek
Oldukça tipik bir kuruluma sahip (page builder, 3 pazarlama eklentisi, optimize edilmemiş ürün fotoğrafçılığı) bir WooCommerce mağazasının yakın zamanlı bir denetiminde, görselleri ve render-blocking scriptleri ele almadan önce ve sonraki dağılım şöyleydi:
| Değişiklik | Önce LCP | Sonra LCP |
|---|---|---|
| Hero + ürün görsellerini WebP'ye dönüştür | 4,8s | 3,6s |
| Aşırı büyük görsel boyutlarını düzelt | 3,6s | 2,9s |
Hero görselden loading="lazy" kaldır |
2,9s | 2,1s |
Bu üç değişikliğin hiçbiri hosting, cache yapılandırması veya tema koduna dokunmadı — sadece görsel işlemeyle LCP'yi "zayıf"tan "iyi"ye taşıdı. Bu, çoğu WordPress denetiminde gördüğümüzle tutarlı: görseller bakılacak son yer değil, ilk yerdir.
Kaçınılması Gereken Hata
PageSpeed Insights kırmızı döndüğünde yaygın bir içgüdü, "suçluyu" bulmayı umarak eklentileri teker teker devre dışı bırakmaya başlamaktır. Bu yavaş ve genellikle sonuçsuzdur, çünkü asıl darboğaz sıklıkla bir eklenti bile değil, aşırı büyük tek bir görseldir. Önce PageSpeed Insights raporunun "Diagnostics" bölümüne bak — gerçek LCP öğesini adlandırır ve render'ı engelleyen belirli kaynakları listeler, bu da deneme-yanılma yöntemiyle eklenti kapatmaktan çok daha hızlı bir başlangıç noktasıdır.
Özetle
WordPress'te kırmızı bir PageSpeed Insights skoru bir hosting yükseltmesi veya tam bir tema yeniden yapımı gerektiriyormuş gibi hissettirir, ama pratikte çözüm neredeyse her zaman daha dar: görselleri modern bir formatta doğru boyutta al, gereksiz scriptlerle render'ı engellemeyi bırak, cache'lenebilecek her şeyi cache'le ve ihtiyaç duymadıkları varlıkları yükleyen eklentileri budayarak. Bu dördünü sırayla uygula ve her birinden sonra yeniden test et — genellikle ilk bir iki adımda hangi düzeltmenin asıl işi yaptığını anlarsın.
Görseller en büyük sorunun çıkarsa (genellikle öyle olur), Erdo Image Optimizer yukarıda ele alınan format dönüşümünü, boyut uyarılarını ve lazy-loading denetimini otomatikleştirir, böylece tekrarlayan manuel bir kontrol yerine tek seferlik bir kuruluma dönüşür.