PageSpeed ve Core Web Vitals

PageSpeed Insights (PSI), bir URL için iki farklı kanıt türünü aynı ekranda sunar: Chrome User Experience Report’tan (CrUX) gelen gerçek kullanıcı “saha” verisi ve Lighthouse’un kontrollü ortamda ürettiği “laboratuvar” testi. Birincisi son 28 gündeki deneyimi anlatır; ikincisi belirli bir anda sorun teşhis etmeye yardım eder. Sonuçları doğru kullanmanın ilk kuralı bu iki veri kümesini birbirine karıştırmamaktır.

Saha verisi ile laboratuvar puanı arasındaki fark

Yeni veya düşük trafikli bir sayfada “gerçek kullanıcı verisi yok” mesajı hata değildir. PSI, yeterli URL verisi yoksa bazen aynı originin toplam verisini gösterebilir; origin için de örnek yetersizse saha bölümü oluşmaz. Laboratuvar puanının yüksek olması gerçek kullanıcıların aynı deneyimi yaşadığını kanıtlamaz; saha verisinin zayıf olması da o anki kod sürümünün kesinlikle yavaş olduğu anlamına gelmez, çünkü pencere geçmiş 28 günü içerir.

Güncel Core Web Vitals eşikleri

Core Web Vitals, yükleme, etkileşim ve görsel kararlılığı temsil eden LCP, INP ve CLS’den oluşur. Google araçları değerlendirmede mobil ve masaüstünü ayrı ele alır ve kullanıcı deneyimlerinin 75. yüzdelik değerine bakar. Bir sayfa ya da originin değerlendirmeyi geçmesi için yeterli verisi bulunan üç metriğin de “iyi” aralıkta olması gerekir.

LCP (Largest Contentful Paint), görünüm alanındaki en büyük uygun içerik öğesinin gösterilme zamanını ölçer. Bu öğe çoğu sitede kahraman görseli, büyük başlık alanı veya metin bloğudur. INP (Interaction to Next Paint), bir ziyaret boyunca tıklama, dokunma ve klavye etkileşimlerinin gecikmelerini gözler ve genel yanıt verebilirliği temsil eder. CLS (Cumulative Layout Shift), kullanıcı girişinin hemen ardından oluşmayan beklenmedik yer değişimlerini bir skorla toplar.

Bir PSI raporu nasıl okunur?

1. Doğru URL ve cihazı seçin.

   Ana sayfa kadar içerik, liste ve işlem sayfalarını da ayrı test edin. Mobil ve masaüstü kullanıcıları farklı kaynaklara ve arayüze maruz kalabilir.

2. Önce saha verisinin kapsamını okuyun.

   Verinin “Bu URL”ye mi, tüm origin’e mi ait olduğunu kontrol edin. 75. yüzdelikte hangi Core Web Vitals metriğinin değerlendirmeyi geçmediğini belirleyin.

3. Laboratuvarda aynı metriğin izini sürün.

   LCP öğesi, uzun ana iş parçacığı görevleri, düzen kaymaları ve ağ zincirleri gibi tanıları açın. Laboratuvar INP’yi gerçek bir ziyaret boyunca ölçemez; Total Blocking Time gibi tanılar yalnız yön gösterir.

4. En büyük kullanıcı etkisini seçin.

   Yüzlerce küçük öneriyi aynı anda uygulamak yerine kötü saha metriğine ve en çok kullanılan şablona öncelik verin. Tasarruf tahminleri kesin sonuç değil, karşılaştırma aracıdır.

5. Değişikliği ölçerek yayınlayın.

   Önce geliştirme ortamında birkaç tekrar test edin; sonra gerçek kullanıcı ölçümü ve Search Console eğilimini izleyin. Saha penceresinin değişikliği göstermesi zaman alır.

LCP’yi iyileştirme sırası

Önce LCP öğesinin ne olduğunu bulun. Öğe bir görselse HTML içinde erken keşfedilebilir olması, doğru boyutlu dosya kullanması ve gereksiz tembel yüklemeden kaçınması önemlidir. Modern biçim ve sıkıştırma aktarım boyutunu azaltabilir; fakat görünenden büyük bir görseli yalnız WebP/AVIF’e çevirmek temel boyut sorununu çözmez. Kritik görselin önceliği gerektiğinde fetchpriority="high" ile belirtilebilir; her görsele yüksek öncelik vermek kaynak yarışını kötüleştirir.

LCP yalnız görsel sorunu değildir. Yavaş ilk sunucu cevabı bütün zinciri geciktirir. Önbellekleme, CDN, veritabanı sorgusu ve sunucu tarafı üretimi ayrı ölçün. Ekranı engelleyen CSS ve senkron komut dosyalarını azaltın; kritik stili küçük ve denetlenebilir tutun. Web fontu LCP metnini geciktiriyorsa alt küme, ön yükleme ve uygun font-display stratejisi deneyin.

INP’yi iyileştirme sırası

INP; giriş gecikmesi, olay işleyicinin çalışma süresi ve tarayıcının sonraki kareyi çizmesine kadar geçen sunum gecikmesinden etkilenir. İlk adım uzun JavaScript görevlerini geliştirici araçlarında bulmaktır. Büyük görevleri daha küçük parçalara bölmek, kullanılmayan kodu yüklememek ve üçüncü taraf betikleri gerçekten ihtiyaç olduğunda başlatmak ana iş parçacığını rahatlatır.

Bir düğme tıklandığında binlerce DOM öğesini güncellemek yerine görünür bölümü sınırlayın; ağır hesaplamayı mümkünse Web Worker’a taşıyın. Kullanıcıya hemen görsel geri bildirim verin ancak gerçek işlemi gizleyen sahte ilerleme sunmayın. Çerez yönetimi, reklam, analiz ve sohbet betiklerini tek tek ölçün; “async” veya “defer” kullanmak çalışma maliyetini ortadan kaldırmaz.

CLS’yi iyileştirme sırası

Görsel, video, iframe ve reklam yuvaları için yüklemeden önce genişlik-yükseklik ya da aspect-ratio ile alan ayırın. Mevcut içeriğin üstüne sonradan banner eklemeyin; sabit alan ayırın veya kullanıcı etkileşimiyle açın. Font değişiminde farklı karakter ölçüleri satırların kaymasına neden olabilir; uygun yedek font metrikleri ve kontrollü font yükleme bunu azaltır.

Animasyonlarda düzeni değiştiren top, left, genişlik gibi özellikler yerine uygun olduğunda transform kullanın. Kullanıcının tıklamasından hemen sonra beklenen açılır panel kayması CLS sayılmayabilir; yine de erişilebilir ve öngörülebilir arayüz gereklidir. Lighthouse kayma işaretlerini gösterse de bütün yaşam döngüsündeki kaymalar için gerçek kullanıcı gözlemi daha kapsayıcıdır.

Belirtiye göre karar matrisi

Örnek iyileştirme planı

Bu plan “LCP kesin 2,5 saniyenin altına iner” sözü vermez. Kullanıcı cihazları, bağlantı, kişiselleştirme ve üçüncü taraf hizmetler sonucu etkiler. İyileştirmenin etkisini dağılım ve iş metriğiyle doğrulamak gerekir.

SEO ve AdSense ile ilişkisi

Google, iyi Core Web Vitals değerlerini kullanıcı deneyimi ve Search başarısı için önerir; fakat sayfa deneyimi tek bir sıralama sinyali değildir. En alakalı ve faydalı içerik, daha zayıf deneyime rağmen gösterilebilir. Mükemmel puan uğruna içeriği veya gerekli işlevi azaltmak doğru optimizasyon değildir. Hız, erişilebilirlik, güvenli HTTPS, mobil kullanılabilirlik ve ana içeriği kapatmayan reklam yerleşimi birlikte değerlendirilmelidir.

PageSpeed puanı AdSense kabul garantisi de değildir. Yayıncı politikaları, özgün ve yeterli içerik, gezinme, kullanıcı güveni ve reklam yerleşimi ayrı başlıklardır. Araç sonucunu kesin onay formülü olarak değil, ölçülebilir kullanıcı deneyimi girdisi olarak kullanın.

Yayın ve izleme kontrol listesi

• Mobil ve masaüstünde ana sayfa dışında kritik şablonları da test ettim.
• Saha verisinin URL’ye mi origine mi ait olduğunu ve 28 günlük pencereyi kontrol ettim.
• LCP, INP ve CLS’nin 75. yüzdelik değerlerini ayrı kaydettim.
• Laboratuvar testini birkaç kez çalıştırıp tek uç değere göre karar vermedim.
• En sorunlu metrik için öğe, kod ve ağ düzeyinde kök neden belirledim.
• Üçüncü taraf betikleri iş değeri ve çalışma maliyetiyle birlikte değerlendirdim.
• Değişiklik öncesi ve sonrası aynı URL/koşullarda karşılaştırma yaptım.
• Gerçek kullanıcı eğilimini, hata oranını ve dönüşüm gibi iş metriklerini izledim.

PageSpeed raporu oluştur →