Core Web Vitals Nedir? LCP, INP ve CLS Optimizasyonu

Core Web Vitals, Google’ın sayfa deneyimini kullanıcı merkezli üç metrik üzerinden değerlendirdiği ölçüm setidir. Yalnızca bir hız testi puanı değildir; ziyaretçinin ana içeriği ne zaman gördüğünü, bir butona veya menüye dokunduğunda sayfanın ne kadar hızlı tepki verdiğini ve içeriklerin yükleme sırasında yer değiştirip değiştirmediğini gösterir.

Değerlendirme mobil ve masaüstü için ayrı yapılır. Özellikle Search Console raporu, Chrome kullanıcılarından anonim olarak toplanan saha verisini ve 75. yüzdelik deneyimi kullanır. Bu nedenle laboratuvar testi iyi görünürken gerçek kullanıcı verisi “iyileştirme gerekiyor” diyebilir. Teknik SEO çalışmasında bu farkı doğru okumak, yalnız skoru değil gerçek darboğazı iyileştirmeyi sağlar. Netasus’un SEO hizmeti bu teknik kontrolleri içerik ve taranabilirlik çalışmalarıyla birlikte ele alır.

LCP, “Largest Contentful Paint” ifadesinin kısaltmasıdır ve ilk görünüm alanındaki en büyük görselin, metin bloğunun veya video karesinin ne zaman çizildiğini ölçer. İyi bir kullanıcı deneyimi için LCP’nin sayfa ziyaretlerinin en az yüzde 75’inde 2,5 saniye veya altında olması hedeflenir.

Bir sayfadaki LCP öğesi çoğu zaman hero görseli, büyük başlık, banner veya üst bölümdeki geniş içerik alanıdır. LCP süresi yalnız dosyanın indirilmesinden oluşmaz; sunucudan ilk yanıtın gelmesi, kaynağın tarayıcı tarafından keşfedilmesi, indirme süresi ve öğenin ekrana çizilmesini geciktiren CSS ya da JavaScript işlemleri birlikte sonucu belirler.

LCP’nin yüksek çıkması çoğu zaman tek bir nedene bağlı değildir. Önce tarayıcının hangi öğeyi LCP olarak seçtiği, ardından sürenin hangi bölümde biriktiği belirlenmelidir.

İlk adım, Chrome performans araçları veya Lighthouse ile gerçek LCP öğesini bulmaktır. Görsel LCP ise uygun WebP ya da AVIF dosyası, doğru srcset ve sizes tanımları, gerçek width ve height değerleri kullanılmalıdır. İlk ekrandaki ana görsel lazy-load edilmemeli; gerekiyorsa fetchpriority="high" ile önceliklendirilmelidir.

Preload her görsele eklenmemelidir. Yalnız tarayıcının normal HTML akışında geç keşfettiği ve gerçekten LCP olan kaynak için, sayfada kullanılan URL ve responsive seçimle birebir eşleştiğinde yarar sağlar. CSS ve JavaScript tarafında render engelleyen işler azaltılmalı; fontlar yalnız kullanılan ağırlıklarla yüklenmeli ve sunucu yanıt süresi ayrı ölçülmelidir.

Performansla birlikte temiz bir responsive yapı hedefleniyorsa Ankara web tasarım yaklaşımında tasarım ve teknik teslimat aynı plan içinde değerlendirilmelidir.

INP, “Interaction to Next Paint” ifadesinin kısaltmasıdır. Kullanıcının tıklama, dokunma veya klavye etkileşimlerine sayfanın ne kadar hızlı görsel yanıt verdiğini değerlendirir. 200 ms veya daha düşük INP iyi kabul edilir; 200–500 ms arası iyileştirme gerektirir.

Mobil menüyü açmak, CTA butonuna dokunmak, SSS öğesini genişletmek veya bir filtreyi değiştirmek birer etkileşim örneğidir. Tarayıcı, etkileşimin başladığı andan sonraki görsel kareyi sunabildiği ana kadar geçen süreyi izler. Bu yüzden sayfa hızlı açılmış olsa bile ağır JavaScript işlemleri INP’yi yükseltebilir.

INP çoğunlukla ana iş parçacığındaki uzun görevlerden yükselir. Ağır başlangıç kodu, gereksiz event handler’lar, büyük DOM güncellemeleri, üçüncü taraf scriptleri ve masaüstüne özel kodun mobilde de çalışması kullanıcının etkileşimini sırada bekletebilir.

CLS, “Cumulative Layout Shift” ifadesinin kısaltmasıdır ve beklenmeyen yerleşim kaymalarını ölçer. Sayfa yüklenirken başlığın aşağı itilmesi, butonun yer değiştirmesi veya kullanıcının dokunacağı kartın son anda kayması CLS sorununa örnektir.

CLS zaman birimiyle ölçülmez. Görünür içeriğin ne kadarının, ne kadar uzağa ve beklenmedik biçimde hareket ettiğini ifade eden bir skordur. 0,1 veya daha düşük CLS iyi deneyim hedefidir; 0,1–0,25 arası iyileştirme gerektirir.

CLS için temel yaklaşım, sonradan gelecek içeriğin alanını önceden ayırmaktır. Görsellerin doğal ölçüleri, reklam veya embed alanlarının yüksekliği ve sabit CTA gibi bileşenlerin sayfa akışındaki etkisi baştan tanımlanmalıdır.

Search Console Core Web Vitals raporu, URL’leri benzer deneyime sahip gruplar hâlinde gösterir. Bir örnek URL’nin yanında görülen sorun, yalnız o sayfanın tek test sonucu değildir; aynı şablonu veya benzer davranışı paylaşan URL grubunun son 28 günlük gerçek kullanıcı verisini temsil eder.

Bu nedenle “bir anda bütün sayfalar bozuldu” sonucu çıkarılmamalıdır. Ortak şablondaki bir darboğaz çok sayıda URL’yi aynı grupta etkileyebilir. Düzeltme yapıldıktan sonra saha verisinin yenilenmesi zaman alır; Search Console raporu anında değişmez.

Mobil cihazlarda işlemci gücü, ağ kalitesi ve bellek kapasitesi masaüstünden farklıdır. Aynı JavaScript işi düşük güçlü bir telefonda daha uzun sürebilir; yüksek DPR ekran ise beklenenden daha büyük görsel kaynağı seçebilir. Bu nedenle desktop sonucu üzerinden mobil performans kararı verilmemelidir.

Mobil performans, tasarım kararlarının sonradan kontrol edildiği ayrı bir test değil; kurumsal web sitesi planının ilk günden itibaren parçası olmalıdır.

Core Web Vitals, teknik kalite ve sayfa deneyiminin bir parçasıdır; tek başına sıralama garantisi vermez. Arama niyetini karşılayan içerik, otorite, taranabilirlik, index durumu ve diğer SEO sinyallerinin yerine geçmez.

Bununla birlikte hızlı, kararlı ve etkileşime duyarlı bir sayfa ziyaretçinin içeriğe ulaşmasını kolaylaştırır. Özellikle aynı içerik kalitesine sahip sayfalarda zayıf deneyimi iyileştirmek hem kullanıcı memnuniyeti hem de teknik sürdürülebilirlik açısından değerlidir.

Tek bir Lighthouse raporuna bakıp her dosyada değişiklik yapmak, gerçek darboğazı gizleyebilir. Özellikle mevcut tasarım sistemi incelenmeden eklenen override’lar ve aşırı kaynak önceliklendirmesi performansı iyileştirmek yerine yeni sorunlar üretir.

Teknik kapsamın fiyatlandırmaya nasıl yansıdığını değerlendirirken web tasarım fiyatları içeriğindeki kapsam kalemleri de dikkate alınmalıdır.

Sağlıklı optimizasyon, her metriği ayrı ölçen ve değişiklik sonrasında aynı koşullarda yeniden doğrulayan kontrollü bir süreçtir.