LCP, Sıralamayı Gerçekten Etkileyen Metrik Neden Bu
Üç Core Web Vitals metriğinden — LCP, INP ve CLS — Largest Contentful Paint, çoğu WordPress sitesinin başarısız olduğu ve tek bir nedene en doğrudan bağlı olanıdır: görseller.
LCP, sayfadaki en büyük görünür öğenin render edilmesinin ne kadar sürdüğünü ölçer. WordPress sitelerinin büyük çoğunluğunda — bloglar, ürün sayfaları, ajans portfolyoları — bu öğe bir görseldir: bir hero banner, öne çıkan görsel, katlama üstü ürün fotoğrafı.
PageSpeed Insights veya Search Console'da LCP puanın kırmızıysa, çözümün yeni bir host veya cache eklentisi olmama ihtimali yüksek. Sorun genellikle görselin kendisi.
Checklist
Bunları sırayla uygula. Her biri görsellerin LCP'yi yavaşlattığı belirli bir yolu hedefliyor.
1. Gerçek LCP öğeni belirle
Bir şeyi düzeltmeden önce, ölçülen şeyin ne olduğunu doğrula. Chrome DevTools → Performance sekmesi → sayfa yüklemesini kaydet → zaman çizelgesinde "LCP" işaretini ara. Tam olarak hangi öğe olduğunu gösterecek.
Alternatif olarak, sayfayı PageSpeed Insights'ten geçir — rapor, LCP öğesini "Diagnostics" altında doğrudan adlandırır.
Tahmin etme. Yanlış görseli optimize etmek zaman kaybettirir ve puanı değiştirmez.
2. Dosya formatını kontrol et
JPEG ve PNG, hâlâ çok fazla sitede sunulan 1990'lar formatları. WebP, eşdeğer kalitede JPEG'den kabaca %25–35 daha küçük, AVIF ise daha ileri gidiyor — JPEG'den genellikle %50 daha küçük.
LCP görselin hâlâ ham bir JPEG veya PNG ise, bu neredeyse her zaman mevcut en yüksek etkili düzeltmedir. Mekaniği için WordPress görsellerini WebP'ye dönüştürme rehberimize bak — kısa versiyonu: Erdo Image Optimizer bunu otomatik olarak, sunucunun kendi GD veya Imagick kütüphanesini kullanarak, API anahtarı gerektirmeden yapıyor.
3. Gerçek render edilen boyutları kontrol et
800px genişliğindeki bir hero kapsayıcısında gösterilen 4000×3000px bir fotoğraf, indirilen byte'ların kabaca %90'ını ziyan ediyor. Tarayıcı, küçültmeden önce tüm dosyayı indirmek zorunda.
Bunu görsele sağ tıklayıp → Inspect → doğal boyutu, computed styles'taki render edilen width/height ile karşılaştırarak kontrol et. Doğal boyut, render edilen boyutun ~1,5 katından fazlaysa, görsel sadece sıkıştırma değil yeniden boyutlandırma da gerektiriyor.
4. Açık width ve height attribute'ları ekle
Eksik width/height attribute'ları LCP'ye doğrudan zarar vermez, ama CLS'ye (layout shift metriği) zarar verir, ve yüklenirken layout'u kaydıran bir sayfa genellikle LCP ölçümünü de geciktirir. Her <img> etiketi, tarayıcının dosya indirilmeden önce yer ayırabilmesi için açık boyutlara sahip olmalı.
5. LCP adayını asla lazy-load yapma
En sık gördüğümüz hata bu: bir "performans" eklentisi, hero görseli de dahil olmak üzere sayfadaki her görsele loading="lazy" ekliyor. Lazy loading, tarayıcıya görseli viewport'a yaklaşana kadar getirmemesini söyler — bu da LCP puanını belirleyen görsel için istediğinin tam tersi.
Çözüm: katlama üstü görseller eagerly yüklenmeli (loading="lazy" attribute'u olmadan veya açıkça loading="eager" ile), ideal olarak fetchpriority="high" ile. Sadece katlama altındaki görseller lazy-load edilmeli.
6. LCP görseli tarayıcının ilk gördüğü şey değilse preload et
LCP görselin bir CSS background-image üzerinden yükleniyorsa, veya JavaScript'in sayfa yüklendikten sonra render ettiği bir slider/carousel içine gömülüyse, tarayıcı bunu yükleme sürecinin geç bir noktasına kadar fark etmez. <head> içine o belirli görsel için bir <link rel="preload" as="image"> etiketi eklemek, tarayıcıya onu her şeyle paralel olarak hemen getirmesini söyler.
7. Görselin kendisi için sunucu yanıt süresini kontrol et
Doğru boyutlu, doğru formatlı bir WebP görsel, cache header'ı olmayan optimize edilmemiş bir origin'den sunuluyorsa hâlâ hızlı yüklenmez. Görsellerinin uzun cache ömrüyle (statik varlıklar için Cache-Control: max-age=31536000) sunulduğunu doğrula ve birden fazla bölgeden anlamlı trafiğin varsa bir CDN düşün.
8. Her değişiklikten sonra yeniden test et
Sekiz adımı toplu uygulayıp sonunda bir kez test etme. Formatı düzelt, yeniden test et. Boyutları düzelt, yeniden test et. Bu, birden fazla şeyin aynı anda yanlış olduğu bir siteyi sorun giderirken hangi değişikliğin gerçekten etki yarattığını gösterir.
Bunu Ölçekte Yapmak
50 sayfalık bir sitedeki her görseli elle denetlemek gerçekçi değil. Erdo Image Optimizer'ın yerleşik SEO denetiminin kapattığı boşluk tam olarak bu — sitendeki her görseli tarar ve aşırı büyük dosyaları, eksik lazy-loading attribute'larını (ve tersi hatayı — katlama üstü görselleri lazy-load yapmayı), yanlış formatları ve eksik alt metni tek bir raporda işaretler.
Yüklemede otomatik WebP/AVIF dönüşümüyle birleşince, bu checklist'in çoğu tekrarlayan bir manuel denetim olmaktan çıkıp tek seferlik bir kuruluma dönüşür.
Özetle
LCP sorunları bir hosting veya cache sorunu gibi hissettiriyor çünkü çoğu genel "siteni hızlandır" tavsiyesi bunu varsayıyor. Pratikte, tipik bir WordPress sitesinde çözüm neredeyse her zaman: doğru formatı, doğru boyutta, doğru öncelikle sunmak. Daha pahalı bir host veya sunucu seviyesinde bir cache katmanına geçmeden önce yukarıdaki checklist'i uygula — sorun genellikle orada değil.