Core Web Vitals üç ölçüdür: LCP, INP ve CLS. Google'ın iyi saydığı eşikler LCP için 2,5 saniye, INP için 200 milisaniye, CLS için 0,1. Bu üçünü kendi sitemde ölçerken en çok CLS'te yanıldım, aşağıda neyi nasıl düzelttiğimi yazıyorum.

Önce neyi ölçtüğünüzü bilin

İki tür veri var. Lighthouse gibi araçlar laboratuvar verisi verir: tek bir ziyaretin simülasyonudur. Saha verisi gerçek ziyaretçilerden toplanır ve Search Console'daki Core Web Vitals raporunda görünür. Eşikler saha verisinde değerlendirilir, sayfa yüklemelerinin dörtte üçünün eşiği geçmesi beklenir.

Kendi sitemde Lighthouse aynı sayfaya bir gün 90, ertesi gün 100 verdi. Nedeni analiz kodunun ölçüm penceresinde yüklenmesiydi, toplam engelleme süresi 150 ile 670 milisaniye arasında oynuyordu. Analizi ilk etkileşime, en geç beş saniyeye bağladım. Tek bir ölçüme bakıp karar vermeyin, aynı sayfayı üç kez çalıştırıp ortalamasına bakın.

LCP, INP ve CLS ne anlama geliyor

LCP, sayfanın en büyük görünür öğesinin çizilme süresidir. Çoğu sitede ilk ekrandaki görsel ya da büyük başlık bloğudur. 2,5 saniyenin altı iyi, 4 saniyenin üstü zayıf sayılıyor.

INP, bir tıklamadan ya da dokunuştan sonra ekranın güncellenmesindeki gecikmedir ve FID'in yerini aldı. Ayrıntısı için INP yazıma bakabilirsiniz. CLS ise sayfa yüklenirken öğelerin yer değiştirmesini sayar. Okurken satırın kayması bunun örneğidir.

Kendi sitemde düzelttiğim üç şey

Yazı tipi yüzünden kayma

Yazı tipini font-display swap ile yüklüyordum. Yavaş 4G simülasyonunda CLS 0,13 ile 0,41 arasında gidip geliyordu. Montserrat yaklaşık 98 KB ve yedek yazı tipinden geniş, yüklenince başlık ile sohbet balonu yeniden ölçülüyordu. font-display optional'a geçtim, aynı koşulda CLS 0 ve 0,011 çıktı. Bedeli şu: yazı tipi geç gelirse o ziyaret yedek yazı tipiyle kalıyor. Markanız için yazı tipi görünümü kaymadan daha önemliyse tersini seçersiniz.

Stil dosyasının geç keşfedilmesi

Ana sayfada harici stil dosyasının bağlantısı 628. satırdaydı. Tarayıcı onu 21.000. baytta keşfediyordu. Bağlantıyı 8. satıra aldım, artık 269. baytta bulunuyor. Lighthouse'un oluşturmayı engelleme bulgusu tam bunu gösteriyordu.

Boyutu yazılmayan görseller

Her görselde width ve height yazıyorum. Boyut yazılmazsa tarayıcı yer ayırmaz, görsel yüklenince altındaki metni aşağı iter. Bu CLS'in en sık görülen nedenlerinden biri ve düzeltmesi iki satır. LCP elemanı çoğu zaman bir görsel olduğu için görselleri WebP'ye çevirip küçültüyorum, bunu Görsel Sıkıştırma ve WebP aracımla yapabilirsiniz. Yazı tipini kendi sunucunuzdan vermek isterseniz TTF/OTF → WOFF2 dönüştürücümü kullanabilirsiniz, logo ve ikonlar için SVG Optimize aracı dosya boyutunu düşürüyor.

Teknik SEO: Google siteyi okuyabiliyor mu

Hız iyi olsa da Google sayfayı bulamıyorsa ya da aynı sayfayı iki adres sanıyorsa o hızın bir faydası kalmıyor. Baktığım yerler şunlar: robots.txt ve sitemap, canonical etiketi, noindex, yönlendirmeler ve yapılandırılmış veri.

Bir sitemde 29 sayfa hem uzantılı hem uzantısız adreste 200 dönüyordu. Google bunları iki ayrı sayfa sayabilir. Barındırma tarafındaki güzel adres ayarını kapattım, kalan 29 çift için 301 yönlendirmesi yazdım. Canonical hatalarının nasıl oluştuğunu canonical yazımda anlattım.

Sık sorulan sorular şemasında cevap metni sayfadaki cevapla aynı olmalı. Bunu karşılaştıran bir denetim yazdım. İlk taramada ana sayfadaki beş cevabın şemada farklı yazıldığını buldum ve eşitledim. Şema hatalarının Search Console'daki karşılığı için şema yazıma bakın.

Hangi sırayla düzeltiyorum

Önce LCP'ye bakıyorum, çünkü çoğu sitede kazanç orada. İlk ekrandaki görsele loading lazy yazmıyorum. Tembel yükleme ilk ekran dışındaki görseller için. İlk ekrandakine uygulanırsa tarayıcı onu geç istiyor ve LCP kötüleşiyor.

İkinci adım sayfayı bekleten dosyalar. Stil bağlantısını sayfanın en üstüne alıyorum, betikleri defer ile yüklüyorum. Çerez onayı gibi yardımcı betikler sayfanın çizilmesini geciktirmemeli. Üçüncüsü CLS: görsellere boyut, yazı tipine optional, sonradan eklenen bloklara yer ayırma. INP'ye en son bakıyorum, çünkü az JavaScript ile yazılmış bir sitede çoğu zaman sorun orada çıkmıyor. Ağır bir betik ya da eklenti varsa sorun orada başlıyor.

Önbellek ve sürüm etiketi

Paylaşılan JavaScript dosyalarım yedi gün boyunca tarayıcı önbelleğinde kalıyor. Bu hızlı bir çözüm ama dosyayı değiştirince ziyaretçi eski halini görebilir. Bu yüzden dosya adının sonuna sürüm etiketi koyuyorum, örneğin soru işareti, v ve tarih. Dosyayı her değiştirdiğimde etiketi tüm sayfalarda güncelliyorum. Bunu atlarsam yeni kod yayında olsa bile ziyaretçilerin bir kısmı bir hafta eski kodla çalışıyor.

Mobil ve masaüstü sonuçlarına ayrı bakıyorum. Lighthouse mobilde yavaş bir ağ ve zayıf bir işlemci simüle ediyor, bu yüzden masaüstü puanı genellikle mobilden yüksek çıkıyor. Search Console'daki rapor da iki cihazı ayrı gösteriyor.

Search Console'da nereye bakıyorum

Core Web Vitals raporunda sayfalar iyi, geliştirilmesi gereken ve zayıf gruplarına ayrılıyor. Rapor gerçek ziyaretçi verisinden çıktığı için trafiği az olan sitelerde yeterli veri toplanmayabiliyor ve rapor boş kalabiliyor. Bu durumda elimde yalnızca laboratuvar ölçümü kalıyor, bunu da kesin hüküm gibi okumuyorum.

Rapor doluysa önce zayıf grubun hangi adreslerden oluştuğuna bakıyorum. Çoğu zaman aynı şablonu kullanan bir sayfa grubu aynı nedenle zayıf çıkıyor. Tek bir şablonu düzeltmek onlarca sayfayı birden kurtarıyor.

Sınırlarım

Hızı düzelttikten sonra sıralamanın ne kadar değiştiğini ölçmedim, bu yüzden sayı vermiyorum. Bildiğim kadarıyla Google sayfa deneyimini sıralama sinyallerinden biri sayıyor, tek başına yeterli görmüyor. Hız, içeriği olmayan bir sayfayı yukarı taşımaz. Çalışmalarım saf HTML üzerine kurulu. Eklenti yığını olan bir sitede aynı sorunların çözüm yolu farklı, o tür sitelerde deneyimim sınırlı.

Sitenizin adresini yazarsanız ücretsiz ön analizde hız ve teknik durumuna da bakıyorum, raporu aynı gün gönderiyorum. Daha geniş çerçeve için SEO danışmanlığı sayfama, hız ve kullanıcı davranışı ilişkisi için web sitesi hızı yazıma göz atın. Aynı konunun genel SEO tarafı SEO rehberimde duruyor.

Sık Sorulan Sorular

Core Web Vitals nedir?

Google'ın sayfa deneyimini ölçmek için kullandığı üç metriktir: LCP yükleme hızını, INP etkileşim gecikmesini, CLS görsel kaymayı ölçer. İyi eşikler LCP için 2,5 saniye, INP için 200 milisaniye ve CLS için 0,1.

LCP kaç saniye olmalı?

Google 2,5 saniyenin altını iyi, 4 saniyenin üstünü zayıf sayıyor. Arası iyileştirme gerektiriyor. Değerlendirme gerçek ziyaretçi verisinde yapılır.

Lighthouse puanı neden her seferinde değişiyor?

Lighthouse tek bir ziyareti simüle eder, ağ ve işlemci durumu her çalıştırmada farklıdır. Sayfada geç yüklenen betikler farkı büyütür. Kendi sitemde 90 ile 100 arasında oynayan puanın nedeni analiz kodunun zamanlamasıydı.

Sayfa hızı tek başına sıralama getirir mi?

Getirmez. Hız bir sinyaldir, içeriğin yerini tutmaz. Hız düzeltmesinin sıralamaya etkisini ben ölçmedim, bu yüzden bir oran ya da süre vaat etmiyorum.