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

Core Web Vitals, Google'ın bir sayfanın yüklenme hızını, tepki süresini ve görsel kararlılığını ölçtüğü üç metriktir: LCP, INP ve CLS. Değerler gerçek ziyaretçilerden toplanır ve Google'ın sıralama sistemlerinde kullanılır. Aşağıda eşikleri, saha ve laboratuvar verisinin farkını, her metriğin sık nedenlerini anlatıyoruz. Üçüncü taraf betiklerin maliyeti, Next.js'e özgü çözümler ve kendi sitemizdeki bir ölçüm de var.

Core Web Vitals nedir, eşikler kaç?

Core Web Vitals'ta üç metrik vardır ve her birinin "iyi" sınırını Google belirlemiştir. LCP için 2,5 saniye, INP için 200 milisaniye, CLS için 0,1. Sayfanın geçmesi için üçünün de iyi olması gerekir.

Türkçe kaynakların bir kısmı hâlâ FID'i (ilk giriş gecikmesi) anlatıyor. INP, 12 Mart 2024'te FID'in yerini aldı. FID yalnızca ilk etkileşimin bekleme süresine bakıyordu. INP ise sayfadaki tıklama, dokunma ve tuş basışlarının tamamını izler. Kaydırma ve fareyle üzerine gelme INP'ye girmez.

Google bu metrikleri sıralama sistemlerinde kullandığını söylüyor. Aynı belgede iyi puanın üst sırayı garanti etmediği de yazıyor. Google'a göre en alakalı içerik, sayfa deneyimi zayıf olsa bile gösterilir. Hız iyi içeriğin yerine geçmez; iyi içeriğin geride kalmamasını sağlar.

Saha verisi ile laboratuvar verisi neden farklı çıkar?

Saha verisi gerçek ziyaretçilerin tarayıcısından, laboratuvar verisi tek bir test makinesinden gelir. PageSpeed Insights ikisini aynı ekranda gösterir. Üstteki gerçek kullanıcı bölümü sahadır; alttaki performans puanı Lighthouse'un laboratuvar ölçümüdür.

Saha verisinin kaynağı Chrome Kullanıcı Deneyimi Raporu'dur (CrUX). Veri, kullanım istatistiği paylaşmayı açmış Chrome kullanıcılarından toplanır. PageSpeed Insights son 28 günün verisini gösterir. Adres için yeterli veri yoksa sitenin tamamına ait veriye döner.

Laboratuvar ise tek bir cihazı, tek bir ağı ve tek bir konumu taklit eder. Önbellek boştur; gerçek ziyaretçinin tarayıcısında dosyaların bir kısmı zaten vardır. Kimse tıklamadığı için laboratuvar INP'yi ölçemez. Lighthouse onun yerine Toplam Engelleme Süresi'ne (TBT) bakar.

İkisi çeliştiğinde karar sahadan verilir. Google'ın web.dev rehberi de iki veri birlikte varsa önceliği saha verisine göre belirlemeyi öneriyor. Laboratuvar, nedeni bulmak ve düzeltmeyi hemen denemek için kullanılır.

75. yüzdelik ne demek?

75. yüzdelik, ziyaretlerin dörtte üçünün o değerde ya da daha iyi olduğu noktadır. Google sayfayı ortalamaya göre değil, bu noktaya göre değerlendirir. Mobil ve masaüstü ayrı ayrı ölçülür.

100 ziyaret düşünün ve LCP sürelerini küçükten büyüğe dizin. 75. sıradaki değer 2,5 saniye ya da altındaysa sayfa LCP'de iyidir. Ortalama 1,8 saniye olsa bile yavaş telefonlar 75. sırayı 3 saniyeye itebilir. Ortalamaya bakan sorunu görmez; yüzdeliğe bakan görür.

Düzeltme Search Console'a neden geç yansır?

Çünkü saha verisi 28 günlük kayan bir penceredir. Düzeltmeden sonraki ilk günlerde pencerenin çoğu hâlâ eski ziyaretlerden oluşur. Değer, eski ziyaretler pencereden çıktıkça yavaş yavaş iyileşir.

Search Console'daki Core Web Vitals raporu da CrUX verisini kullanır. Benzer adresleri gruplar ve grubun durumunu en kötü metriğe göre verir. LCP'si iyi ama CLS'si zayıf bir grup "zayıf" görünür. Düzeltmeyi doğrulamayı başlattığınızda 28 günlük bir izleme süresi başlar.

Pratikte düzeltmenin etkisi ilk gün laboratuvarda, dört hafta sonra sahada görülür. 14. günde pencerenin yarısı hâlâ eski ziyaretlerdir. Arada sayfayı yeniden değiştirmek, hangi değişikliğin işe yaradığını bulanıklaştırır.

LCP neden yavaş olur, nasıl düzeltilir?

LCP, ilk ekrandaki en büyük görselin ya da metin bloğunun çizildiği andır. Süre dört parçaya ayrılır: ilk bayt süresi (TTFB), kaynak yükleme gecikmesi, kaynak indirme süresi ve çizim gecikmesi. Uzun olan parça, düzeltmenin yerini gösterir.

web.dev rehberine göre sürenin büyük kısmı HTML belgesine ve LCP kaynağına harcanmalıdır. Önerilen dağılımda ilk bayta ve indirmeye yaklaşık yüzde 40'ar pay düşer. Yükleme gecikmesi ile çizim gecikmesi ise yüzde 10'un altında kalmalıdır.

En sık rastlanan nedenler ve düzeltmeleri:

• Kahraman görseline loading="lazy" verilmiş: LCP görseli hiçbir zaman tembel yüklenmemeli.
• Görsel geç keşfediliyor: HTML'de doğrudan yer almalı ve fetchpriority="high" ile işaretlenmeli.
• Görsel çok büyük: telefona masaüstü boyutu gidiyorsa srcset ve sizes düzeltilmeli.
• Sunucu geç cevap veriyor: önbellek ve içerik dağıtım ağı ilk bayt süresini kısaltır.
• Metin geç görünüyor: başlığı gizleyen giriş animasyonu ve engelleyici CSS çizimi geciktirir.

İlk bayt süresinde sunucunun önündeki katman da etkilidir. Kendi sitemizin önünde Cloudflare var; önbellek ve ağ tarafını Cloudflare kullanmanın faydaları yazımızda anlattık.

INP neden kötü çıkar, nasıl düzeltilir?

INP, bir tıklama ya da dokunuştan sonra ekranın değişmesine kadar geçen süredir. Sayfadaki en yavaş etkileşimlerden biri raporlanır. Kötü INP'nin nedeni çoğu zaman ana iş parçacığını meşgul eden JavaScript'tir.

Bir etkileşim üç aşamadan geçer. Giriş gecikmesi, tarayıcı başka bir işle meşgulken olayın beklediği süredir. İşleme süresi, tıklamaya bağlı kodun çalıştığı süredir. Sunum gecikmesi ise sonucun ekrana çizilmesini bekleyen kısımdır.

• Uzun görevler: 50 milisaniyeyi aşan görevler parçalara bölünmeli, araya ana iş parçacığına dönüş konmalı.
• Ağır tıklama işleyicisi: ekranda görünen değişiklik önce yapılmalı, kayıt ve ölçüm sonraya bırakılmalı.
• Büyük DOM: binlerce öğeli sayfada her değişiklik daha pahalı çizilir.
• Açılışta çalışan betikler: sayfa yüklenirken yapılan tıklama giriş gecikmesine takılır.
• Stil okuyup hemen yazmak: döngü içinde ölçüm, tarayıcıyı düzeni tekrar tekrar hesaplamaya zorlar.

CLS neden olur, nasıl önlenir?

CLS, sayfa açıkken içeriğin beklenmedik biçimde yer değiştirmesini puanlayan metriktir. Kullanıcı bir düğmeye uzanırken üstüne görsel yüklenirse yanlış yere dokunur. Kullanıcının tıklamasından sonraki 500 milisaniyedeki kaymalar sayılmaz.

• Boyutsuz görsel: width ve height ya da CSS aspect-ratio ile yer önceden ayrılmalı.
• Reklam, harita ve video gömmeleri: kutuya en az yükseklik (min-height) verilmeli.
• Sonradan eklenen içerik: duyuru şeridi içeriği aşağı itmemeli, ayrılmış yerde açılmalı.
• Web yazı tipi: yedek yazı tipi ile asıl yazı tipinin ölçüsü birbirine yaklaştırılmalı.
• Konum animasyonu: top ve left yerine transform ile hareket ettirilmeli.

Çerez penceresi ayrı bir dikkat ister. Sayfanın akışına eklenirse bütün içeriği aşağı iter. Sabit konumlu bir katman olarak açılırsa içerik yerinden oynamaz.

Üçüncü taraf betikler ne kadar yük getirir?

Üçüncü taraf betik, sitenin kendi sunucusundan değil başka bir firmanın sunucusundan yüklenen koddur. Etiket yöneticisi, reklam pikselleri, canlı destek ve çerez onay araçları bu gruptadır. Her biri ağ bağlantısı kurar ve ana iş parçacığında çalışır.

Maliyet siteden siteye değişir; ortalama bir sayı vermek yanıltıcı olur. Ölçmek için iki yol var. Lighthouse'un üçüncü taraf özeti, her sağlayıcının aktarım boyutunu ve ana iş parçacığı süresini listeler. Chrome DevTools'ta bir alan adını engelleyip sayfayı yeniden ölçmek de farkı gösterir.

Kendi sitemizde Meta Pixel ve Dönüşüm API'si yalnızca çerez onayından sonra çalışıyor. Onay vermeyen ziyaretçinin tarayıcısına Pixel betiği hiç inmez. Kural gizlilik için kuruldu, ama hıza da yarıyor.

Canlı destek araçlarında en etkili yol cephe (facade) yaklaşımıdır. Sayfada gerçek pencere yerine onun görüntüsü durur. Ziyaretçi tıkladığında asıl betik yüklenir. Hiç tıklamayan ziyaretçi bu betiğin bedelini ödemez.

Next.js sitesinde nelere dikkat edilir?

Next.js hız için hazır araçlar verir, ama yanlış ayarla bu araçlar ters de çalışabilir. Üç bileşen öne çıkar: next/image, next/font ve next/script. Dördüncü konu, istemci bileşenlerinin taşıdığı JavaScript yüküdür.

• next/image: varsayılan yükleme tembeldir (lazy). İlk ekrandaki LCP görseline loading="eager" ya da fetchPriority="high" verilmelidir.
• Next.js 16'da priority özelliği kullanımdan kalktı; yerine preload geldi. Belgeler çoğu durumda eager ya da fetchPriority kullanmayı öneriyor.
• sizes: ekranla genişliği değişen görselde sizes yazılmazsa telefona gereğinden büyük dosya gidebilir.
• next/font: yazı tipini derleme sırasında indirip siteden sunar; tarayıcı Google'a istek atmaz.
• Yedek yazı tipi ayarı (adjustFontFallback) varsayılan olarak açıktır ve yazı tipi geldiğinde oluşan kaymayı azaltır.
• Yazı tipi ön yüklemesi varsayılan olarak açıktır. Çok kalınlıklı ailede birçok dosya erken iner ve LCP görseliyle yarışır.
• next/script: etiket yöneticisi için varsayılan afterInteractive, canlı destek ve sosyal medya eklentileri için lazyOnload uygundur.
• İstemci bileşenleri: "use client" yazılan her bileşenin kodu tarayıcıya iner ve açılışta çalışır. Sayfanın tamamını istemci bileşeni yapmak açılıştaki tıklamaları geciktirir.

İki altyapının farkını Next.js ve WordPress karşılaştırması yazımızda ele aldık. WordPress'te aynı işler eklentilerle yapılır; Next.js'te ise kodun kendisinde çözülür.

Yeniden boyama süresi 2000 ms'den 9 ms'ye nasıl indi?

Kendi sitemizde bir animasyon katmanına verilen CSS maskesi kaydırmayı takılır hâle getiriyordu. Maskeyi hareketli katmandan çıkarınca en uzun kare süresi yaklaşık 2000 milisaniyeden 9 milisaniyeye indi. Ölçtüğümüz şey yeniden boyama süresiydi, INP değildi.

Hareketli katmanda üç parçalı bir CSS maskesi (mask-image) vardı ve katmanın içi her karede değişiyordu. Tarayıcı da maskeyi her karede yeniden hesaplayıp boyuyordu. Belirti, sayfa kaydırılırken titremeydi; en belirgin hâli masaüstü Chrome'daydı.

Ölçmek için sayfayı kaydırırken ardışık kareler arasındaki süreyi kaydettik (requestAnimationFrame aralıkları). Maske varken en uzun kare yaklaşık 2000 milisaniye sürdü. Maskeyi çizimin içinde çözünce aynı ölçüm 9,4 milisaniyeye indi. Saniyede 60 kare için bir karenin bütçesi yaklaşık 16,7 milisaniyedir.

Ölçtüğümüz değer bir INP değeri değildir. INP kaydırmayı saymaz; yalnızca tıklama, dokunma ve tuş basışına bakar. Ama 2 saniyelik bir kare sırasında gelen dokunuş, o karenin bitmesini beklerdi. Sorun INP'ye de sızabilirdi; yalnızca bizim ölçtüğümüz şey o değildi. Ölçüm de saha değil, kendi tarayıcımızdaki laboratuvar ölçümüydü.

İki ders çıkardık. Hareketli bir katmana CSS maskesi verilmez; maske ya hiç oynamayan bir katmana ya da çizimin kendisine taşınır. Ölçüm de iki kez alınır, çünkü ilk turdaki tek tük uzun kareler tarayıcının ısınmasından gelebilir.

Önce hangi metriği düzeltmeli?

Önce Search Console'da "zayıf" görünen ve en çok trafik alan sayfa grubundaki metrik ele alınır. Aynı grupta emeği az, etkisi büyük işle başlanır. Aşağıdaki tablo bizim değerlendirmemizdir, Google'ın verdiği bir sıralama değildir.

Reklam trafiği alan sayfalarda hız ayrıca bütçe demektir. Bu bağı Google Ads açılış sayfası rehberimizde Kalite Puanı üzerinden anlattık. Teknik SEO'nun geri kalanı için SEO teknik kontrol listesi sayfamızı kullanabilirsiniz. Hızı baştan hesaba katan bir site için web tasarım hizmetimiz sayfasına bakabilirsiniz.