Core Web Vitals nedir? Sayfa deneyimi ve SEO sıralaması

Bir e-ticaret sitesinin sahibi, reklam bütçesini artırdığı hâlde satışların neden yerinde saydığını anlamaya çalışıyor. Analytics'e bakınca tablo netleşiyor: ziyaretçilerin önemli bir kısmı ürün sayfası daha tam açılmadan geri dönüyor; mobilde sayfa yüklenirken düğmeler yerinden oynuyor ve insanlar yanlış yere basıyor. Sorun trafikte değil, sayfanın elde nasıl hissettirdiğinde. İşte Google'ın Core Web Vitals dediği ölçütler tam da bu deneyimi sayısallaştırmak için var: sayfa ne kadar hızlı kullanılabilir hâle geliyor, tıklamaya ne kadar çabuk yanıt veriyor ve gözünüzün önünde ne kadar kararlı duruyor.

Bu yazıda Core Web Vitals'ın ne olduğunu, üç temel metriğin (LCP, INP, CLS) her birinin sade bir dille neyi ölçtüğünü ve hangi hataların onları bozduğunu, saha verisi ile laboratuvar verisi arasındaki farkı, bu ölçütlerin hem sıralamaya hem dönüşüme neden dokunduğunu, nasıl ölçüleceğini ve bir KOBİ sitesinde nereden başlanması gerektiğini adım adım anlatıyoruz. Kesin eşik değerleri zamanla güncellendiği için burada rakam vermiyoruz; bunun yerine mantığı kuruyoruz ve güncel sayılar için Google'ın kendi belgelerine bakmanızı öneriyoruz.

1LCP · yükleme2INP · etkileşim3CLS · kayma4Sayfa deneyimi

Core Web Vitals nedir ve Google neden önemsiyor?

Core Web Vitals, Google'ın "sayfa deneyimi" (page experience) sinyalleri içinde öne çıkardığı, gerçek kullanıcıların bir sayfayı ne kadar akıcı deneyimlediğini ölçen bir metrik setidir. Yıllarca "hızlı site" kavramı bulanıktı; herkesin farklı bir tanımı vardı. Google bu bulanıklığı üç somut, ölçülebilir boyuta indirdi: yüklenme, etkileşim ve görsel kararlılık.

Amaç, arama motorunun kullanıcıyı memnun edecek sayfaları ödüllendirmesi. SEO'nun temel mantığı zaten "aramayı yapan kişiye en iyi yanıtı sun" üzerine kuruludur; içerik ne kadar iyi olursa olsun, açılması eziyet olan bir sayfa kötü bir yanıttır. Core Web Vitals bu sezgiyi denetlenebilir bir ölçüye çevirir ve teknik SEO çalışmasının somut bir parçası hâline getirir.

Core Web Vitals, "hızlı site" gibi belirsiz bir hedefi üç net soruya indirger: Yüklendi mi? Dokunuşuma cevap verdi mi? Yerinde durdu mu?

LCP: Sayfanın gerçekten "açıldığı" an

LCP (Largest Contentful Paint), ekranın görünen bölümündeki en büyük içerik parçasının — çoğu zaman kapak görseli, ürün fotoğrafı ya da büyük bir başlık bloğunun — ne zaman çizildiğini ölçer. Kullanıcı için bu an, sayfanın "artık burada" hissettiği andır; teknik olarak her şey bitmemiş olsa bile, ana içerik geldiğinde algı olarak sayfa açılmıştır.

LCP'yi en çok bozan şey genelde ağır bir kapak görselidir: sıkıştırılmamış, gereğinden büyük çözünürlükte yüklenen bir hero fotoğrafı, yavaş bir sunucu yanıtı ve içeriği geciktiren, oluşturmayı engelleyen (render-blocking) CSS ile JavaScript dosyaları. Örneğin bir emlak sitesinde her ilan sayfasının en üstündeki dev fotoğraf tam boyutunda sunuluyorsa, mobil kullanıcı içeriğe ulaşmadan önce uzun süre boş bir alana bakar. "İyi" ile "geliştirilmesi gereken" arasındaki sınır zamanla güncellenir; hedef aralığını bir rakam olarak ezberlemek yerine Google'ın belgelerinden teyit edin.

INP: Tıkladıktan sonraki o kısa bekleme

INP (Interaction to Next Paint), kullanıcının bir etkileşiminin — bir düğmeye basmanın, menüyü açmanın, forma yazmanın — ekranda görünür bir yanıta dönüşmesinin ne kadar sürdüğünü ölçer. 2024'te INP, eski FID (First Input Delay) metriğinin yerini alarak resmi bir Core Web Vitals oldu; çünkü FID yalnızca ilk etkileşimin gecikmesine bakıyordu, INP ise sayfadaki etkileşimlerin genel yanıt verme kalitesini yansıtır.

INP'yi bozan baş suçlu ağır JavaScript'tir: tıklamayı işleyen kodun tarayıcının ana iş parçacığını (main thread) uzun süre meşgul etmesi. Örneğin bir ürün sayfasında "Sepete ekle" düğmesine basıldığında arka planda ağır analitik ve öneri kodları aynı anda çalışıyorsa, kullanıcı düğmenin "tıklandığını" hemen göremez ve çoğu zaman ikinci kez basar. Sayfa aslında yüklenmiştir ama dokununca "donuk" hissettirir — dönüşümü sessizce öldüren tam da bu histir.

CLS: Gözünüzün önünde kayan düzen

CLS (Cumulative Layout Shift), sayfa yüklenirken öğelerin beklenmedik şekilde ne kadar yer değiştirdiğini ölçer. Herkesin yaşadığı o andır: bir yazıyı okumaya başlarsınız, üstte geç yüklenen bir reklam ya da görsel araya girer, bütün metin aşağı kayar ve yanlışlıkla istemediğiniz bir bağlantıya basarsınız.

CLS'yi bozan tipik nedenler bellidir: boyutu önceden belirtilmemiş görseller ve reklamlar, sonradan yüklenip düzeni iten banner'lar, geç gelen yazı tipleri (fontlar) yüzünden metnin yeniden akması. Örneğin bir haber sitesinde makale metni hemen gelir ama görseller için yer ayrılmadığından, her fotoğraf yüklendikçe okuduğunuz satır zıplar. Çözümün özü, her öğeye baştan yer ayırmaktır.

Saha verisi ve laboratuvar verisi: İkisi de gerekli

Core Web Vitals'ı okurken iki farklı veri türüyle karşılaşırsınız ve ikisini karıştırmak yaygın bir hatadır. Saha verisi (field data), gerçek kullanıcıların gerçek cihaz ve bağlantılarında yaşadığı deneyimi toplar; Google'ın sıralama bağlamında baktığı asıl veri budur. Laboratuvar verisi (lab data) ise kontrollü, standart bir ortamda yapılan tek seferlik bir simülasyondur.

Fark önemlidir: laboratuvarda kusursuz görünen bir sayfa, yavaş bir telefonu ve zayıf bağlantısı olan gerçek bir kullanıcıda kötü puan alabilir. Bu yüzden laboratuvar verisi hatayı ayıklamak, saha verisi ise "gerçekte ne oluyor" sorusuna yanıt vermek için kullanılır. İkisi çeliştiğinde, karar verirken saha verisine ağırlık verin.

Neden önemli: Hem sıralama hem dönüşüm

Core Web Vitals, Google'ın sıralama sinyallerinden biridir — ama tek başına belirleyici değildir. Alakalı ve güçlü içerik hâlâ birincil faktördür; Core Web Vitals daha çok "diğer her şey eşitken" fark yaratan bir eşik gibi çalışır. Yani kötü bir deneyim sizi geriye çekebilir, ama tek başına mükemmel bir skor zayıf içeriği zirveye taşımaz.

Asıl büyük etki çoğu zaman sıralamada değil, kullanıcı davranışındadır. Yavaş açılan, dokununca donan, altınızda kayan bir sayfa hemen çıkma (bounce) oranını artırır ve dönüşüm oranını düşürür. Özellikle sabrın çok kısa olduğu mobilde, bir açılış sayfasının ilk saniyelerdeki akıcılığı, reklama harcanan bütçenin geri dönüp dönmeyeceğini belirler. Core Web Vitals'ı yalnızca bir SEO görevi değil, doğrudan bir gelir meselesi olarak görmek daha doğrudur.

Nasıl ölçülür: PageSpeed Insights, Search Console, Lighthouse

İyi haber şu: Core Web Vitals'ı ölçmek için ücretli bir araca gerek yok; Google'ın kendi araçları hem saha hem laboratuvar verisini ücretsiz sunar.

• PageSpeed Insights: tek bir URL girip hem saha hem laboratuvar verisini bir arada görmenin en hızlı yolu; her metrik için somut iyileştirme önerileri de verir.
• Search Console Core Web Vitals raporu: tek tek sayfaları değil sitenizin tamamını gruplar hâlinde gösterir; hangi sayfa kümelerinin "iyi", hangilerinin "geliştirilmesi gereken" durumda olduğunu ölçekte görürsünüz. Search Console'un ne olduğunu bilmek, bu raporu doğru okumanın ön koşuludur.
• Lighthouse (ve Chrome DevTools): tarayıcının içinden, geliştirme sırasında tek bir sayfayı laboratuvar koşullarında test etmek için idealdir.

Pratik akış nettir: genel resmi Search Console'dan görün, sorunlu bir sayfayı PageSpeed Insights'ta inceleyin, düzeltmeyi yayına almadan önce Lighthouse ile doğrulayın.

Her metriği iyileştirmek ve KOBİ için öncelik sırası

İyileştirme kulağa teknik gelir ama çoğu kazanç birkaç temel adımdan gelir. Her metriğin kendine özgü bir "en büyük kaldıracı" vardır.

LCP için

Kapak/hero görselini uygun boyutta ve modern formatta sunun, gereğinden büyük dosyaları sıkıştırın; sunucu yanıt süresini hızlandırın (önbellek, iyi bir barındırma); içeriği geciktiren, oluşturmayı engelleyen kaynakları azaltın.

INP için

Ağır JavaScript'i azaltın: gereksiz üçüncü taraf betiklerini (script) temizleyin, kodu parçalayın, ana iş parçacığını uzun süre meşgul eden işleri erteleyin. Sayfada çalışan her ek izleme kodunun bir bedeli olduğunu unutmayın.

CLS için

Görsellere, reklamlara ve gömülü içeriklere baştan sabit yer ayırın; yazı tiplerini kararlı yükleyin; sonradan araya girip düzeni iten öğelerden kaçının.

KOBİ tarafında pragmatik öncelik sırası ise şöyle görünür:

• Önce gelir getiren sayfalarla başlayın: en çok trafik ve gelir getiren birkaç şablonu (ana sayfa, ürün/hizmet sayfası, açılış sayfası) her şeyden önce ele alın.
• Önce mobili düzeltin: saha verisinin en kötü olduğu ve ziyaretçilerinizin çoğunun bulunduğu yer orasıdır.
• En kötü metriği hedefleyin: her şeyi aynı anda cilalamak yerine, saha verisinde LCP, INP ve CLS'den hangisi en düşükse ona odaklanın.

Core Web Vitals'ı, yapısal veri işaretlemesi gibi diğer teknik iyileştirmelerle birlikte, bir kerelik proje değil düzenli bir bakım alışkanlığı olarak ele almak en sağlıklısıdır.

Sıkça sorulan sorular

Core Web Vitals aslında eski bir gerçeği ölçülebilir kılar: insanlar hızlı, kararlı ve dokununca yanıt veren sayfaları sever, gerisini terk eder. LCP yüklenmeyi, INP etkileşimi, CLS ise kararlılığı temsil eder; üçünü birden mükemmelleştirmeye çalışmak yerine en çok gelir getiren sayfalarda en kötü metrikten başlamak, kısa sürede hem sıralamaya hem dönüşüme yansır. Bu iyileştirmelerin karşılığını görmek de ayrı bir disiplin ister: reklamdan gelen ziyaretçinin gerçekten satışa dönüp dönmediğini izlemek gerekir. Rocketly gibi bir CRM ve pazarlama merkezi, hızlanan sayfalarınızdan gelen adayları tek bir yerde toplayıp dönüşüme kadar takip ederek teknik iyileştirmenin ticari sonucunu görünür kılar.