Bir müşterim geçtiğimiz ay elinde bir ekran görüntüsüyle geldi: PageSpeed Insights skoru 34. “Sitemiz çok yavaş, Google bizi cezalandırıyor mu?” diye sordu. Ölçüme birlikte baktığımızda ortaya çıkan tablo şuydu: masaüstü skoru 91, mobil skoru 34 ve asıl sorun tek bir görselden kaynaklanıyordu. Ana sayfadaki kapak fotoğrafı 4,2 MB’lık bir JPEG’di ve mobilde de aynı boyutta yükleniyordu.
Core Web Vitals konusundaki en yaygın yanılgı, bunun soyut bir “hız puanı” olduğu inancıdır. Oysa üç metrik de son derece somut kullanıcı deneyimlerini ölçer: sayfa ne zaman görünür hale geliyor, tıkladığımda ne zaman tepki veriyor ve okurken içerik ayağımın altından kayıyor mu. Bu yazıda üç metriği de WordPress özelinde ele alacağım — teoriden çok, gerçek projelerde tekrar tekrar karşılaştığım nedenlere ve çözümlere odaklanarak.
Core Web Vitals Nedir, Neyi Ölçer?
Google’ın kullanıcı deneyimini ölçmek için kullandığı üç temel metrik var:
- LCP (Largest Contentful Paint): Ekrandaki en büyük içerik öğesinin görünür hale gelme süresi. Hedef: 2,5 saniyenin altı.
- INP (Interaction to Next Paint): Kullanıcının bir etkileşiminden sonra sayfanın görsel tepki verme süresi. 2024’te FID’in yerini aldı. Hedef: 200 milisaniyenin altı.
- CLS (Cumulative Layout Shift): Sayfa yüklenirken içeriğin ne kadar kaydığı. Hedef: 0,1’in altı.
Önemli bir ayrım: PageSpeed Insights size iki farklı veri gösterir. Üstteki bölüm gerçek kullanıcı verisidir (CrUX); alttaki bölüm laboratuvar simülasyonudur (Lighthouse). Google’ın sıralama sinyali olarak kullandığı, gerçek kullanıcı verisidir. Laboratuvar skoru düşük ama gerçek kullanıcı verisi yeşilse panik yapmanıza gerek yok.
LCP: En Sık Karşılaşılan Sorun
Bir WordPress sitesinde LCP öğesi genellikle ana görsel (hero image) veya büyük puntolu başlık metnidir. LCP’yi bozan başlıca nedenler ve çözümleri:
Optimize edilmemiş görseller
Fotoğraf makinesinden çıkan bir görselin doğrudan yüklenmesi en sık gördüğüm hatadır. Çözüm katmanları:
- Görselleri WebP veya AVIF formatına dönüştürün; JPEG’e göre belirgin kazanç sağlar.
- Yükleme öncesi boyutlandırın. Alanı 1200 piksel genişliğindeyse 4000 piksellik dosya yüklemeyin.
- `srcset` ile duyarlı görsel setleri oluşturun; WordPress bunu varsayılan olarak yapar, ancak sayfa oluşturucular bazen devre dışı bırakır.
- Ekranın üst kısmındaki (above the fold) görsele tembel yükleme (lazy load) uygulamayın. Bu, LCP’yi doğrudan geciktirir.
Sunucu yanıt süresi (TTFB)
Sunucu ilk baytı geç gönderiyorsa, sonrasında ne yaparsanız yapın LCP kurtarılamaz. Paylaşımlı hostingde 800 ms üzeri TTFB sık görülür. Sunucu düzeyinde tam sayfa önbelleği, güncel PHP sürümü ve nesne önbelleği (Redis) bu değeri belirgin biçimde düşürür.
Render engelleyen kaynaklar
Head bölümünde sırayla yüklenen CSS ve JavaScript dosyaları, tarayıcının sayfayı çizmesini bekletir. Kritik CSS’i satır içine alın, geri kalanını ertelemeli yükleyin. JavaScript dosyalarına `defer` ekleyin.
Yazı tipleri
Google Fonts’u uzak sunucudan çekmek ek DNS ve bağlantı süresi demektir. Yazı tiplerini kendi sunucunuza taşıyın, `font-display: swap` kullanın ve gerçekten kullandığınız ağırlıkları yükleyin. Üç ağırlık yeterliyken dokuz ağırlık yüklemenin bedeli her ziyarette ödenir.
INP: Sitenizin Tepkisi Neden Gecikiyor?
INP, FID’den çok daha zorlu bir metriktir. FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; INP ise oturum boyunca yaşanan tüm etkileşimleri değerlendirir. Bu yüzden pek çok site, FID’de yeşilken INP’de sarıya düştü.
Ana suçlu neredeyse her zaman aşırı JavaScript’tir. WordPress’te bunun tipik kaynakları:
- Ağır sayfa oluşturucu eklentilerinin her sayfaya yüklediği ortak betikler
- Sohbet widget’ları, ısı haritası araçları, çoklu pazarlama pikselleri
- Yalnızca tek bir sayfada kullanılan bir eklentinin tüm sitede betik yüklemesi
- Sürüklenip bırakılan slider ve animasyon kütüphaneleri
Çözüm yaklaşımım şu sırayla ilerler:
- Envanter çıkarın. Hangi eklenti hangi sayfada hangi dosyayı yüklüyor, listeleyin.
- Koşullu yükleme kurun. İletişim formu betiği yalnızca iletişim sayfasında yüklensin.
- Üçüncü taraf betiklerini erteleyin. Sohbet widget’ı ilk etkileşime kadar beklesin; kullanıcı sayfayla temas ettiğinde yüklensin.
- Uzun görevleri bölün. 50 ms üzerindeki JavaScript görevleri ana iş parçacığını kilitler.
- Etiket yöneticisini disipline edin. Google Tag Manager içinde yıllardır duran, kimsenin kullanmadığı etiketler INP’nin sessiz katilidir.
Bir projede yalnızca kullanılmayan üç pazarlama pikselini kaldırarak INP’yi 340 ms’den 160 ms’ye indirmiştik. Kod yazmadan, sadece temizlik yaparak.
CLS: İçerik Neden Zıplıyor?
CLS’nin nedenleri diğer iki metriğe göre daha az sayıda ve çözümü daha nettir.
Boyutu belirtilmemiş görseller. Bir `<img>` etiketinde `width` ve `height` yoksa, tarayıcı görsel yüklenene kadar ona yer ayırmaz; yüklendiğinde altındaki her şey aşağı kayar. Tüm görsellere boyut niteliği ekleyin.
Reklam ve gömülü içerik alanları. iframe, harita, video gömme ve reklam blokları için CSS ile sabit yükseklik rezerve edin.
Geç yüklenen yazı tipleri. Yedek yazı tipiyle asıl yazı tipinin ölçüleri çok farklıysa, yazı tipi yüklendiğinde metin bloğu yeniden akar. `size-adjust` ve uyumlu yedek yazı tipi seçimi bunu azaltır.
Sonradan enjekte edilen çerez bandı ve duyuru çubukları. Sayfanın üstüne sonradan eklenen bir bant, altındaki tüm içeriği aşağı iter. Bu öğeleri sayfa akışının dışında (`position: fixed`) konumlandırın veya alanını baştan rezerve edin.
Ölçümü Doğru Yapmak
Optimizasyona başlamadan önce ölçüm disiplininizi kurun:
- PageSpeed Insights: Hem gerçek kullanıcı hem laboratuvar verisi için başlangıç noktası.
- Search Console > Core Web Vitals raporu: Sorunlu URL gruplarını toplu görmenizi sağlar. Tek tek sayfa test etmek yerine buradan başlayın.
- Chrome DevTools > Performance paneli: Uzun görevleri ve hangi betiğin ana iş parçacığını kilitlediğini görmenin tek doğru yolu.
- Web Vitals eklentisi veya kendi ölçüm kodunuz: Gerçek ziyaretçilerinizden sürekli veri toplamak, tek seferlik testlerden çok daha güvenilirdir.
Bir uyarı: ölçümü her zaman aynı koşullarda yapın. Önbelleği temizlendikten hemen sonra alınan ölçüm ile ısınmış önbellek üzerinden alınan ölçüm farklı çıkar ve boşuna zaman kaybettirir.
Eklenti Değil, Yöntem
Piyasada “tek tıkla Core Web Vitals düzeltme” vaadiyle satılan çok sayıda eklenti var. Bunların iyi olanları önbellek, dosya birleştirme ve tembel yükleme gibi işleri düzgün yapar ve gerçekten fayda sağlar. Ancak hiçbiri 4 MB’lık bir görseli sizin yerinize küçültmez, gereksiz eklentiyi kaldırmaz veya sayfa oluşturucunun ürettiği şişkin DOM yapısını sadeleştirmez.
Sıralamayı şöyle kurun: önce gereksiz olanı kaldırın, sonra kalanı optimize edin, en son önbellek katmanı ekleyin. Ters sıradan gidenler, sorunun üstünü örtüp altı ay sonra aynı noktaya döner.
Uygulama Sırası: 10 Adımlık Kontrol Listesi
Bir WordPress sitesinde Core Web Vitals iyileştirmesine başlarken izlediğim sıra şudur. Sıra önemlidir; sonraki adımın etkisini görebilmek için öncekinin tamamlanmış olması gerekir.
- Ölçümü sabitleyin. Search Console’daki Core Web Vitals raporundan sorunlu URL gruplarını çıkarın ve her gruptan bir temsilci sayfa seçin.
- Eklenti envanteri yapın. Etkin eklentileri listeleyin, son altı ayda kullanılmayanları devre dışı bırakın. Devre dışı bırakmak yetmez; silin, çünkü bazıları pasifken de kayıt bırakır.
- Hosting ve PHP sürümünü doğrulayın. Güncel PHP sürümü, yalnızca güvenlik değil performans farkı da yaratır.
- Sunucu düzeyinde önbellek kurun. Tam sayfa önbelleği, TTFB’yi en hızlı düşüren tek müdahaledir.
- Görsel kütüphanesini temizleyin. Toplu dönüştürme ile tüm medya kütüphanesini modern formata çevirin, aşırı büyük dosyaları yeniden boyutlandırın.
- Hero görselini özel olarak ele alın. Ön yükleme (`preload`) uygulayın, tembel yüklemeden çıkarın, boyut niteliklerini ekleyin.
- Yazı tiplerini yerelleştirin. Kendi sunucunuzdan servis edin ve yalnızca kullanılan ağırlıkları yükleyin.
- JavaScript’i erteleyin ve koşullandırın. Sayfa bazlı yükleme kuralları tanımlayın.
- Düzen kaymalarını kapatın. Gömülü içerik, reklam alanı ve duyuru bantları için alan rezerve edin.
- Yeniden ölçün ve 28 gün bekleyin. Gerçek kullanıcı verisi 28 günlük pencerede toplanır; iyileştirmenin rapora yansıması zaman alır.
Son madde çoğu zaman en zorudur. İyileştirmeyi yaptığınız gün Search Console’da hiçbir şey değişmez ve bu, işin yanlış yapıldığı anlamına gelmez.
Sayfa Oluşturucular ve Performans
Elementor, WPBakery ve benzeri sayfa oluşturucular esneklik sağlar; ancak ürettikleri iç içe geçmiş `div` yapısı ve her sayfaya yüklenen ortak betikler INP ve LCP üzerinde ölçülebilir bir yük oluşturur.
Bu, “sayfa oluşturucu kullanmayın” demek değil. Kullanacaksanız disiplin gerekir:
- Kullanılmayan widget ve özellikleri panelden kapatın
- İç içe bölüm sayısını sınırlayın; üç seviyeden fazla iç içe kapsayıcı gerekmiyordur
- Sayfa oluşturucunun kendi optimizasyon ayarlarını (CSS dosya yükleme modu, ikon kütüphanesi yüklemesi) mutlaka gözden geçirin
- Basit sayfaları blok editörle kurun; sayfa oluşturucuyu yalnızca gerçekten karmaşık düzenler için kullanın
Bir kurumsal sitede yalnızca blog yazılarını sayfa oluşturucudan blok editöre taşıyarak mobil LCP’de yaklaşık bir saniye kazandığımız oldu.
Gerçekçi Bir Beklenti
Her sitede 100/100 skoru hedeflemek anlamlı değildir. Reklam alan, çok dilli, e-ticaret yapan bir sitenin mobil skoru 75 olabilir ve bu tamamen sağlıklıdır. Önemli olan üç metriğin de “iyi” eşiğinde olması: LCP 2,5 sn altı, INP 200 ms altı, CLS 0,1 altı. Skorun kendisi bir rozet değil, teşhis aracıdır.
Ticari etkiye gelince: hız iyileştirmesinin dönüşüm oranına etkisi, arama sıralamasına etkisinden genellikle daha büyüktür. Sepete ulaşmadan sekmeyi kapatan bir ziyaretçi, kaybedilmiş bir sıralamadan daha pahalıdır.
Sonuç
Core Web Vitals, teknik bir zorunluluktan çok kullanıcıya verilen bir söz. Sayfa hızlı açılıyorsa, tıklamaya anında tepki veriyorsa ve okurken yerinden oynamıyorsa, hem ziyaretçi hem arama motoru memnun olur.
WordPress sitenizin Core Web Vitals değerlerini ölçüp somut bir iyileştirme planı çıkarmamı isterseniz, iletişime geçmeniz yeterli. Mevcut durumu birlikte inceleyip önceliklendirilmiş bir yol haritası hazırlayabiliriz.