Core Web Vitals Nedir? LCP, INP ve CLS ile Site Hızını İyileştirme

Core Web Vitals nedir, hangi üç metrikten oluşur?

Core Web Vitals, bir sayfanın gerçek ziyaretçiler için ne kadar hızlı yüklendiğini, etkileşime ne kadar çabuk tepki verdiğini ve yüklenirken ne kadar sabit kaldığını ölçen üç metrikten oluşur: LCP, INP ve CLS. Google bu üçlüyü sayfa deneyiminin ölçülebilir çekirdeği olarak kullanır.

LCP (Largest Contentful Paint), sayfa açılmaya başladıktan sonra ilk ekrandaki en büyük içerik öğesinin (çoğu zaman ana görsel, başlık bloğu ya da video kapağı) ekranda belirmesine kadar geçen süredir. INP (Interaction to Next Paint), ziyaretçinin tıklama, dokunma ve klavye etkileşimlerinin ardından sayfanın bir sonraki kareyi çizmesine kadar geçen gecikmeyi ölçer; web.dev’e göre fareyle üzerine gelme, yakınlaştırma ve kaydırma INP’ye dahil değildir. CLS (Cumulative Layout Shift) ise öğelerin beklenmedik biçimde yer değiştirme miktarını birimsiz bir puanla ifade eder.

INP, 12 Mart 2024’te FID’nin yerini alarak kararlı Core Web Vitals metriği oldu. Bu yüzden FID’ye göre hazırlanmış eski hız planları bugün eksik kalır; denetimlerimizde yalnızca üç güncel metriği birlikte ele alıyoruz.

LCP, INP ve CLS için iyi eşikler nedir?

Google’ın sınıflandırmasında LCP 2,5 saniye ve altında, INP 200 milisaniye ve altında, CLS 0,1 ve altında “iyi” sayılır. LCP’de 4 saniyenin, INP’de 500 milisaniyenin, CLS’de 0,25’in üstü “zayıf”tır; aradaki değerler “iyileştirilmeli” bölgesine düşer.

Değerlendirme tek bir ziyarete göre yapılmaz. Bir sayfanın “iyi” sayılması için sayfa yüklemelerinin 75. yüzdeliğinin eşiği karşılaması gerekir; yani deneyimlerin en az dörtte üçü iyi bölgede kalmalıdır. Ölçüm mobil ve masaüstü için ayrı yapılır, bu yüzden masaüstünde yeşil görünen bir sayfa mobilde eşiği aşabilir. Mobil sürümün neden ayrıca ele alınması gerektiğini mobil SEO yazımızda anlattık.

Eski rehberlerde sık görülen “sunucu yanıtı 200 ms, dosyalar 15 kB, görseller 100 kB altında olmalı” türünden sabit rakamlar Google’ın ölçütü değildir. Sunucu yanıtı (TTFB) için web.dev’in kaba rehberi 0,8 saniye ve altıdır; TTFB bir Core Web Vitals metriği olmasa da LCP’nin ilk halkasıdır. Dosya boyutunda ise tek doğru sayı yoktur: ölçüt, o dosyanın LCP’yi ya da etkileşimleri geciktirip geciktirmediğidir.

Saha verisi ile laboratuvar verisi arasındaki fark nedir?

Saha verisi gerçek ziyaretçilerin cihazlarından toplanan ölçümdür ve Google’ın değerlendirmesi buna dayanır; laboratuvar verisi ise belirli bir cihaz ve bağlantı koşulu taklit edilerek alınan test sonucudur ve sorunun kaynağını bulmaya yarar. İkisi farklı soruları cevapladığı için sayıları çoğu zaman birbirini tutmaz.

Saha verisinin kaynağı Chrome Kullanıcı Deneyimi Raporu’dur (CrUX). Bu rapor, kullanım istatistiği paylaşımını açmış ve tarama geçmişini senkronize eden Chrome kullanıcılarından anonim veri toplar ve yalnızca herkese açık, yeterince ziyaret alan sayfaları kapsar. PageSpeed Insights bu veriyi önceki 28 günlük dönem üzerinden gösterir; yeni yayımlanan ya da az ziyaret alan bir sayfada yeterli veri yoksa alan adı düzeyindeki veriye döner.

Laboratuvar testi (Lighthouse) ise geliştirme sırasında ve yayından önce vazgeçilmezdir: gerçek kullanıcı yokken bile hangi dosyanın ana iş parçacığını kilitlediğini, hangi görselin geç keşfedildiğini gösterir. INP gerçek bir etkileşim gerektirdiği için sayfa yükleme testiyle tam ölçülemez; yavaş etkileşimi Chrome DevTools’ta elle tekrarlayarak incelemek gerekir.

Kararı saha verisine bakarak veriyor, teşhisi laboratuvar verisiyle koyuyoruz. Laboratuvar puanı yüksek olduğu hâlde saha verisinde INP’si zayıf kalan sayfalar denetimlerde sık karşımıza çıkıyor: test ortamı güçlü bir işlemciyle çalışıyor, gerçek ziyaretçinin telefonu ise çoğu zaman öyle değil.

Site hızı sıralamayı ne ölçüde etkiler?

Core Web Vitals Google’ın sıralama sistemlerinde kullanılır ama tek başına sıralatmaz: Google, iyi sonuçların üst sıraları garanti etmediğini ve sayfa deneyimi zayıf olsa bile en alakalı içeriği göstermeyi hedeflediğini açıkça belirtir. Hız, alaka ve içerik kalitesi birbirine yakın sayfalar arasında fark yaratan bir etkendir.

Google’ın sayfa deneyimi belgesi tek bir “sayfa deneyimi sinyali” olmadığını, çekirdek sıralama sistemlerinin genel sayfa deneyimiyle uyumlu çeşitli sinyallere baktığını söyler. HTTPS ile güvenli bağlantı, mobil cihazlarda sorunsuz çalışma, aşırı reklamdan ve içeriği kapatan araya giren katmanlardan kaçınma da bu deneyimin parçasıdır.

Pratikte bunu eşik mantığıyla okuyoruz. Eşiğin belirgin biçimde üstünde, özellikle mobilde yavaş kalan sayfalar hem kullanıcı hem arama tarafında geride kalabiliyor. Eşiği zaten karşılayan bir sayfada birkaç milisaniye kazanmak için uzun süre uğraşmak ise genellikle içerik ve otorite çalışmasına ayrılacak zamanı yiyor.

Yavaşlığın asıl maliyeti çoğu zaman satış tarafında çıkar: ürün, sepet ve ödeme adımlarındaki gecikme, işlemin yarıda bırakılma riskini artırır. Hızın dönüşüme etkisini e-ticarette dönüşüm oranı yazımızda ayrıntılı ele aldık.

LCP nasıl iyileştirilir? Görseller, sunucu yanıtı ve kaynak önceliği

LCP’yi iyileştirmenin yolu, en büyük öğeyi erken keşfettirmek, hızlı indirmek ve engelsiz çizdirmektir. web.dev, LCP süresini dört parçaya ayırır: ilk bayta kadar geçen süre (TTFB), kaynak yükleme gecikmesi, kaynak indirme süresi ve öğe çizim gecikmesi. Hangi parçanın uzun olduğu, düzeltmenin nerede yapılacağını söyler.

• Sunucu yanıtını kısaltın. Sayfa önbelleği, güncel sunucu yazılımı, azaltılmış veritabanı sorguları ve ziyaretçiye yakın bir CDN, TTFB’yi düşürür. İlk bayt gelmeden tarayıcıda hiçbir şey başlayamaz.
• LCP görselini lazy loading’e bırakmayın. loading özniteliğindeki lazy değeri ilk ekranın altındaki görseller içindir; ana görselde kaçınılmaz bir yükleme gecikmesi yaratır.
• Önceliği ana görsele verin. Muhtemel LCP görseline fetchpriority özniteliğini high değeriyle eklemek, tarayıcıya önce onu indirmesini söyler. Yalnızca CSS ya da JavaScript içinden çağrılan bir görsel ise önceden yükleme (preload) ile erken keşfettirilmelidir. Yüksek önceliği bir iki görselden fazlasına vermek işe yaramaz.
• Dosyayı küçültün. AVIF veya WebP biçimi, ekran genişliğine göre srcset ile sunulan boyutlar ve doğru sıkıştırma indirme süresini kısaltır. HTTP/2 veya HTTP/3 destekleyen bir sunucu, birçok dosyanın aynı bağlantı üzerinden paralel inmesini sağlar.
• Çizimi engelleyen kaynakları azaltın. head içindeki eşzamanlı betikler ve şişkin stil dosyaları, görsel inmiş olsa bile çizimi bekletir. Kritik CSS’i küçük tutmak, kullanılmayan CSS ve JavaScript’i ayıklamak ve kalan dosyaları küçültüp sıkıştırmak bu gecikmeyi kapatır.

Görsel tarafının ayrıntılarını, yani biçim seçimini, boyutlandırmayı ve lazy loading kurallarını görsel SEO yazımızda anlattık. LCP öğesi bir başlık ya da metin bloğu olduğunda ise sorun çoğu zaman geç yüklenen web yazı tipleri ve çizimi engelleyen CSS’tir.

INP nasıl iyileştirilir? JavaScript ve üçüncü taraf kodlar

INP’yi iyileştirmek, etkileşim anında ana iş parçacığını boş tutmak demektir: uzun JavaScript görevlerini bölmek, gereksiz ya da ağır üçüncü taraf kodları azaltmak ve etkileşimden sonra yapılan işi hafifletmek. Tarayıcı ana iş parçacığında aynı anda tek iş yapar; 50 milisaniyeyi aşan her görev “uzun görev” sayılır ve bir tıklamanın işlenmesini bekletebilir.

web.dev bir etkileşimi üç parçaya ayırır: giriş gecikmesi (ana iş parçacığı meşgulken etkileşimin beklediği süre), işleme süresi (olay kodunun çalışması) ve sunum gecikmesi (sonucu gösteren yeni karenin çizilmesi). Denetimlerde en sık rastladığımız tablo, sayfa yüklenirken çalışan analitik, reklam, canlı sohbet ve ısı haritası betiklerinin giriş gecikmesini şişirmesidir.

• Üçüncü taraf betikleri envanterleyin. Her etiketin ne işe yaradığını ve kimin kullandığını yazın; kullanılmayanı kaldırın, gerekli olanı ihtiyaç duyulduğu ana erteleyin.
• Uzun görevleri bölün. Büyük bir olay işleyicisini parçalara ayırıp aralarda tarayıcıya çizim fırsatı vermek (yield), etkileşimin hemen görsel karşılık bulmasını sağlar.
• Önce görsel geri bildirimi verin. Menünün açılması ya da butonun basılı görünmesi gibi görünen tepkiyi önce çizin; analitik gönderimi gibi arka plan işlerini sonraya bırakın.
• DOM’u sade tutun. Çok kalabalık sayfalarda her etkileşimden sonraki stil ve düzen hesaplaması uzar; sunum gecikmesi çoğunlukla buradan gelir.
• Eklentileri ölçerek ayıklayın. Eklentileri toptan silmek yerine her birinin yüklediği betiği ve etkileşim maliyetini ölçüp gereksiz olanı kaldırmak hem daha güvenli hem kalıcı sonuç verir.

WordPress sitelerde tema ve eklenti seçiminin hıza etkisini WordPress SEO yazımızda ayrıca ele aldık. INP gerçek kullanıcı etkileşimine bağlı olduğundan düzeltmenin etkisi saha verisinde görülür; yayından önce aynı etkileşimi DevTools’ta tekrarlayarak doğruluyoruz.

CLS nasıl düzeltilir? Boyutsuz medya, reklam alanları ve yazı tipleri

CLS, içeriğe yüklenmeden önce yer ayırarak düzeltilir: görsel, video, reklam ve gömülü alanlara boyut vermek, sonradan eklenen öğelerle mevcut içeriği aşağı itmemek ve web yazı tiplerini metni zıplatmadan yüklemek. web.dev’e göre kötü CLS’nin en yaygın nedenleri boyutsuz görseller, boyutsuz reklam, gömülü içerik ve iframe’ler, sayfaya sonradan eklenen içerikler ve web yazı tipleridir.

• Görsel ve videolara boyut verin. width ve height öznitelikleri ya da CSS aspect-ratio özelliği, tarayıcının dosya inmeden önce alan ayırmasını sağlar.
• Reklam ve gömülü alanları rezerve edin. Reklamın gelip gelmeyeceği belli olmasa da alanın en olası yüksekliği baştan ayrılmalıdır; boş kalan bir alan, kayan metinden daha az rahatsız eder.
• Sonradan gelen bantlarla içeriği itmeyin. Çerez bildirimi, kampanya şeridi ya da stok uyarısı gibi sonradan eklenen öğeler ya önceden ayrılmış bir alana ya da içeriği yerinden oynatmayan sabit bir katmana yerleştirilmelidir.
• Yazı tiplerini yönetin. Web yazı tipi geç geldiğinde metin yeniden dizilir. font-display ayarı, kritik yazı tipinin önceden yüklenmesi ve ölçüleri yakın bir yedek yazı tipi bu kaymayı azaltır.
• Animasyonları transform ile yapın. Konum ve boyut değiştiren animasyonlarda top, left ya da height yerine transform kullanmak diğer öğeleri yerinden oynatmaz ve CLS’ye eklenmez.

Laboratuvar testi çoğunlukla yükleme anındaki kaymaları yakalar; sayfa kaydırılırken geç yüklenen ve kendisine yer ayrılmamış içerikten doğan kaymalar ise saha verisinde ortaya çıkar. Bu yüzden CrUX verisindeki CLS değeri Lighthouse sonucundan belirgin biçimde kötüyse sorunu yükleme anında değil, sayfanın kullanımı sırasında arıyoruz.

Hangi araçlarla ölçülür? PageSpeed Insights, Search Console ve CrUX

Core Web Vitals için temel araçlar üçtür: tek bir URL’nin saha ve laboratuvar verisini birlikte gösteren PageSpeed Insights, sitenin tamamını benzer sayfa gruplarıyla izleyen Search Console’daki Core Web Vitals (Önemli Web Verileri) raporu ve ham saha verisinin kaynağı olan CrUX. Sorunu ayıklarken bunlara Chrome DevTools, WebPageTest ve GTmetrix gibi laboratuvar araçları eklenir.

Search Console raporu benzer deneyimi paylaşan URL’leri gruplar ve mobil ile masaüstünü ayrı gösterir. Bir düzeltmeyi yayına aldıktan sonra rapordaki doğrulama başlatıldığında Google sorunu 28 günlük bir izleme dönemi boyunca takip eder; düzeltmenin karşılığı bu yüzden raporda hemen değil, veri penceresi yenilendikçe görünür.

Ahrefs ya da Semrush gibi genel SEO araçlarının hız ölçümleri de fikir verir, ama Google’ın değerlendirmesiyle aynı veri değildir. Karar verirken saha verisi gösteren araçları esas alıyoruz.

Core Web Vitals iyileştirmeleri hangi sırayla ele alınmalı?

İyileştirmeye saha verisinde eşiği aşan metrikten ve en çok trafik alan şablondan başlanır; tek tek URL’lerle değil, aynı sorunu paylaşan sayfa gruplarıyla çalışılır. Sıra, etkisi büyük ve geri alınması kolay düzeltmelerden ağır mimari değişikliklere doğru ilerler.

1. Durumu saha verisiyle tespit edin. Search Console’da mobil ve masaüstü raporlarını ayrı okuyup eşiği aşan metrikleri ve URL gruplarını çıkarın.
2. Şablonu belirleyin. Sorunlu grubun ortak şablonunu (ürün, kategori, blog yazısı) bulun; tek bir şablondaki düzeltme o şablonu kullanan bütün sayfaları birden iyileştirir.
3. Hızlı kazanımları uygulayın. LCP görselinin önceliği, görsel boyutları, kullanılmayan üçüncü taraf betikler ve önbellek ayarları genellikle az emekle belirgin fark yaratır.
4. Yapısal sorunlara geçin. Yetersiz hosting, ağır tema ya da sayfa oluşturucu ve tamamen tarayıcıda işlenen içerik gibi konular planlı bir geliştirme gerektirir.
5. Yayından önce laboratuvarda, sonra sahada doğrulayın. Search Console’da doğrulamayı başlatın ve değişikliğin etkisini bir sonraki veri dönemi boyunca izleyin.
6. Geri kaymayı önleyin. Yeni eklenti, etiket ya da kampanya bileşeni eklemeden önce performans etkisini ölçün; hızın en sık bozulduğu an, sonradan eklenen küçük parçalardır.

Hız büyük ölçüde sitenin nasıl kurulduğuyla belirlenir, sonradan yapılan yamaların etkisi sınırlıdır. Web tasarım projelerimizde LCP, INP ve CLS hedeflerini geliştirme aşamasından itibaren ölçüyoruz; yayındaki sitelerde ise hız çalışmasını SEO paketlerimizdeki teknik iyileştirmelerin parçası olarak yürütüyoruz. Bu metriklerin tarama, dizine ekleme ve diğer teknik kontrollerle ilişkisini teknik SEO nedir yazımızda, sitenizin bugünkü değerlerini ise ücretsiz analizde görebilirsiniz.