Core Web Vitals sıralamayı ne kadar etkiler?

Google, sayfa deneyimini sıralama sistemlerinde dikkate aldığını belirtir; ancak alakalı ve faydalı içerik çok daha belirleyicidir. Core Web Vitals'ı iyileştirmek daha çok kullanıcı deneyimi ve dönüşüm açısından değerlidir.

PageSpeed Insights puanım yüksek ama Search Console'da sorun görünüyor. Neden?

PageSpeed puanı laboratuvar ortamındaki tek bir testi yansıtır. Search Console ise farklı cihaz ve bağlantılardaki gerçek kullanıcı verisini kullanır. Yavaş cihazlardaki kullanıcılar ya da etkileşim sorunları laboratuvar testinde görünmeyebilir.

İyileştirmelerin Search Console'a yansıması ne kadar sürer?

Saha verisi 28 günlük bir dönem üzerinden hesaplandığı için değişikliklerin raporlara tam olarak yansıması genellikle birkaç hafta sürer.

FID hâlâ bir Core Web Vitals metriği mi?

Hayır. FID, 2024 yılında yerini INP'ye bıraktı. INP sayfadaki tüm etkileşimleri dikkate aldığı için yanıt verebilirliği daha kapsamlı ölçer.

Core Web Vitals Nasıl İyileştirilir? LCP, INP ve CLS Rehberi

Sitenizin yavaş açıldığını, tıklamalara geç tepki verdiğini ya da içerik yüklenirken sayfanın kaydığını fark ediyorsanız, sorun büyük olasılıkla Core Web Vitals metriklerinde görünüyordur. Bu yazıda Core Web Vitals nasıl iyileştirilir sorusunu üç metrik üzerinden ele alıyor; ölçümden teşhise, teşhisten çözüme giden yolu adım adım anlatıyoruz.

Core Web Vitals nedir?

Core Web Vitals, Google'ın gerçek kullanıcı deneyimini ölçmek için tanımladığı üç metrikten oluşur: yükleme için LCP, etkileşim yanıt süresi için INP ve görsel kararlılık için CLS. INP, 2024 yılında FID'nin yerini aldı ve yalnızca ilk etkileşimi değil, sayfa ömrü boyunca yapılan etkileşimleri dikkate alır. Değerlendirme, ziyaretlerin 75. yüzdelik dilimine göre yapılır; yani kullanıcılarınızın büyük çoğunluğunun iyi deneyim yaşaması hedeflenir.

Metrik	İyi	İyileştirme gerekli	Zayıf
LCP	≤ 2,5 sn	2,5–4 sn	> 4 sn
INP	≤ 200 ms	200–500 ms	> 500 ms
CLS	≤ 0,1	0,1–0,25	> 0,25

Önce doğru ölçün: saha verisi ve laboratuvar verisi

İyileştirmeye başlamadan önce iki veri türünü ayırt etmek gerekir. Saha verisi gerçek Chrome kullanıcılarından toplanır (CrUX) ve Google'ın değerlendirmesinde kullanılan veridir. Laboratuvar verisi ise Lighthouse gibi araçların kontrollü bir ortamda ürettiği sonuçtur ve hata ayıklamak için idealdir.

PageSpeed Insights, aynı sayfa için hem saha hem laboratuvar verisini gösterir.
Search Console'daki Core Web Vitals raporu, sorunlu URL gruplarını site genelinde listeler.
Chrome DevTools'taki Performance paneli, hangi kodun ana iş parçacığını meşgul ettiğini gösterir.
Kendi siteniz için gerçek kullanıcı ölçümü (RUM) eklemek, trafiği düşük sayfalarda bile veri toplamanızı sağlar.

Ölçüme başlarken sayfaları tek tek değil, şablon bazında gruplamak da işinizi kolaylaştırır. Ürün detay sayfaları, kategori sayfaları, blog yazıları ve açılış sayfaları genellikle aynı bileşenleri paylaşır; bir şablondaki sorunu çözdüğünüzde o şablonu kullanan yüzlerce sayfa birlikte iyileşir. Search Console'daki URL grupları da bu mantıkla oluşturulur. Hangi şablonun en çok trafik aldığını analitik verisinden çıkarıp önceliği ona göre belirlemek, sınırlı geliştirme zamanını en verimli şekilde kullanmanızı sağlar.

Lighthouse puanının yüksek olması, saha verisinin de iyi olduğu anlamına gelmez. Özellikle INP, laboratuvar ortamında doğrudan ölçülemez; gerçek kullanıcı etkileşimleri gerekir.

LCP nasıl iyileştirilir?

LCP öğesi çoğu zaman bir kahraman görseli, büyük bir başlık ya da video posteridir. Süreyi dört parçaya ayırmak teşhisi kolaylaştırır: sunucu yanıt süresi (TTFB), kaynağın keşfedilme gecikmesi, kaynağın indirilme süresi ve oluşturma gecikmesi. Hangi parçanın uzun sürdüğünü bilmeden yapılan iyileştirmeler çoğu zaman yanlış yere odaklanır; örneğin sorun yavaş sunucudaysa görseli ne kadar sıkıştırırsanız sıkıştırın belirgin bir fark görmezsiniz.

Sunucu yanıtını hızlandırın: Statik üretim, önbellekleme ve CDN kullanımı TTFB'yi düşürür.
LCP görselini erken keşfettirin: Görseli HTML içinde doğrudan img etiketiyle verin, yüksek öncelik (fetchpriority) tanımlayın ve bu görsele lazy loading uygulamayın.
Dosya boyutunu küçültün: AVIF veya WebP kullanın, ekrana uygun boyutlarda srcset ile sunun.
Oluşturmayı engelleyen kaynakları azaltın: Kritik CSS'i satır içine alın, gereksiz üçüncü taraf betikleri erteleyin.

INP nasıl iyileştirilir?

INP, kullanıcı bir butona tıkladığında ya da bir alana yazdığında ekranın ne kadar sürede güncellendiğini ölçer. Kötü INP'nin ana nedeni, ana iş parçacığını uzun süre meşgul eden JavaScript görevleridir.

Uzun görevleri bölün: 50 ms'yi aşan işleri küçük parçalara ayırın ve aralarda tarayıcıya kontrolü geri verin.
Olay işleyicilerini hafifletin: Tıklamadan sonra önce görsel geri bildirimi gösterin, ağır hesaplamayı sonraya bırakın.
JavaScript miktarını azaltın: Kullanılmayan kütüphaneleri kaldırın, kod bölme (code splitting) uygulayın; mümkün olan bileşenleri sunucu tarafında oluşturun.
Üçüncü taraf betikleri denetleyin: Analitik, sohbet ve reklam etiketleri INP'yi ciddi biçimde etkileyebilir.
Büyük DOM'dan kaçının: Çok sayıda öğe içeren listelerde sanallaştırma kullanın.

CLS nasıl iyileştirilir?

CLS, kullanıcı okurken ya da tıklamak üzereyken içeriğin beklenmedik şekilde kaymasını ölçer. Çözümlerin çoğu basittir ama disiplin ister:

Tüm görsel, video ve iframe öğelerine genişlik ve yükseklik ya da aspect-ratio tanımlayın.
Reklam, banner ve çerez bildirimleri için önceden yer ayırın; içeriğin üstüne sonradan eklemeyin.
Web fontlarında font-display ayarını ve yedek font metriklerini düzenleyerek metin kaymasını azaltın.
Animasyonlarda top, left gibi yerleşimi değiştiren özellikler yerine transform kullanın.

Bu kararların çoğu tasarım aşamasında verilir. Bileşenlerin boyutlarını ve yükleme durumlarını baştan tanımlayan bir UI/UX tasarım süreci, CLS sorunlarını geliştirme öncesinde önler.

Core Web Vitals çalışmalarında sık yapılan hatalar

Performans projelerinde emeğin boşa gitmesine yol açan bazı hatalar tekrar tekrar karşımıza çıkıyor:

Yalnızca ana sayfayı optimize etmek: Google değerlendirmeyi benzer sayfa grupları üzerinden yapar. Ürün, kategori veya blog şablonları trafiğin çoğunu alıyorsa, asıl iş oradadır.
Masaüstü sonuçlarıyla yetinmek: Mobil cihazlar hem daha yavaş işlemciye hem de daha değişken bağlantıya sahiptir. Sorunlar çoğu zaman önce mobilde ortaya çıkar.
Puan peşinde koşmak: Lighthouse puanını yükseltmek için gerçek kullanıcıya fayda sağlamayan hileler (örneğin içeriği botlardan gizlemek) hem risklidir hem de saha verisini iyileştirmez.
Her görsele lazy loading uygulamak: Ekranın üst kısmındaki ana görseli geç yüklemek LCP'yi doğrudan kötüleştirir.
Üçüncü taraf etiketleri kontrolsüz bırakmak: Pazarlama ekibinin etiket yöneticisi üzerinden eklediği her yeni betik, geliştirici ekibin fark etmediği bir INP sorunu yaratabilir. Etiket ekleme sürecine basit bir performans kontrolü koymak bu riski azaltır.

Bu hataların ortak noktası, ölçümün gerçek kullanıcı verisinden kopmasıdır. Hangi değişikliği yaparsanız yapın, etkisini saha verisinde doğrulamadan işi tamamlanmış saymayın.

İyileştirmeleri kalıcı hâle getirmek

Core Web Vitals bir kere düzeltilip unutulacak bir iş değildir; her yeni özellik, betik veya kampanya sayfası metrikleri bozabilir. Performans bütçesi tanımlayın, sürekli entegrasyon sürecine Lighthouse kontrolleri ekleyin ve saha verisini düzenli izleyin. Saha verisinin 28 günlük bir pencerede toplandığını, bu yüzden yaptığınız değişikliklerin raporlara yansımasının birkaç hafta sürebileceğini unutmayın. Next.js kullanan projeler için pratik öneriler Next.js SEO ve web performans taktikleri yazımızda yer alıyor.

BernSoftware olarak performansı sonradan eklenen bir iyileştirme değil, mimarinin bir parçası olarak ele alıyoruz. Sitenizin Core Web Vitals değerlerini birlikte incelemek için web yazılım geliştirme hizmetimize göz atabilir ya da bize yazabilirsiniz.