Core Web Vitals Nedir? LCP, INP ve CLS Metriklerini Okuma Rehberi

Hız raporlarındaki renkli skorlar çoğu zaman yanlış okunur. 100 üzerinden alınan puan bir hedef değildir; asıl anlam, o puanı oluşturan üç ölçümde ve bunların hangi kullanıcı deneyimini temsil ettiğindedir.

Bu yazı üç temel metriği tek tek açıyor: ne ölçer, eşik nedir, kötü çıktığında sebebi genellikle nedir. Sonunda saha verisi ile laboratuvar verisi arasındaki farkı ve raporu doğru okuma yöntemini bulacaksınız.

Üç metrik, tek tabloda

Metrik	Ölçtüğü	İyi	Geliştirilmeli	Zayıf
LCP	En büyük içeriğin görünme süresi	≤ 2.5 sn	2.5 - 4.0 sn	> 4.0 sn
INP	Etkileşime yanıt gecikmesi	≤ 200 ms	200 - 500 ms	> 500 ms
CLS	Beklenmedik düzen kayması	≤ 0.1	0.1 - 0.25	> 0.25

Bir sayfanın "geçti" sayılması için üç metrikte de 75. yüzdelik diliminin iyi aralıkta olması gerekir. Yani ziyaretlerin dörtte üçü eşiği tutturmalıdır — ortalama değil, yüzdelik dilim.

LCP — En büyük içerikli boyama

Ne ölçer

Sayfa açıldıktan sonra, görünür alandaki en büyük öğenin ekrana çizilme süresi. Bu öğe genellikle hero görseli, büyük bir başlık ya da video kapak resmidir. Kullanıcı açısından anlamı basittir: "sayfa yüklendi" hissinin oluştuğu an.

Kötü çıkmasının yaygın sebepleri

• Optimize edilmemiş hero görseli. 2-3 MB'lık bir JPEG tek başına LCP'yi saniyelerce geciktirir. Modern formatlar ve doğru boyutlandırma çoğu durumda sorunu çözer.
• Sunucu yanıt süresi. İlk baytın gelmesi 600 ms'yi geçiyorsa geri kalan her şey gecikmeli başlar. Barındırma kalitesi ve önbellek yapılandırması burada belirleyicidir.
• Engelleyici kaynaklar. Head bölümünde yüklenen büyük CSS ve senkron JavaScript dosyaları, tarayıcının çizime başlamasını erteler.
• Web fontları. Yazı tipi inmeden metnin gizlendiği yapılandırmalar, metin LCP öğesiyse süreyi doğrudan uzatır.
• Görselin geç keşfedilmesi. Hero görseli CSS arka planı olarak tanımlandığında tarayıcı onu geç fark eder.

Pratik yaklaşım

Önce LCP öğesinin ne olduğunu tespit edin — tahmin etmeyin, ölçüm aracı size söyler. Sonra yalnızca o öğeye odaklanın: erken yüklenmesini sağlayın, boyutunu düşürün, gecikmeli yükleme listesinden çıkarın. Görsel LCP öğesiyse ona asla "lazy" yükleme uygulanmamalıdır.

INP — Sonraki boyamayla etkileşim

Ne ölçer

Kullanıcı bir şeye tıkladığında ya da bir tuşa bastığında, ekranda görsel bir değişiklik oluşana kadar geçen süre. Sayfa ziyareti boyunca yaşanan tüm etkileşimler arasından en kötüye yakın bir değer raporlanır.

Bu metrik 2024'te eski FID ölçümünün yerini aldı ve daha zorlayıcıdır: FID yalnızca ilk etkileşimin başlama gecikmesine bakıyordu, INP ise tüm etkileşimlerin sonuçlanma süresini ölçer.

Kötü çıkmasının yaygın sebepleri

• Ağır JavaScript işleri. Ana iş parçacığını uzun süre meşgul eden hesaplamalar, tarayıcının tıklamaya yanıt vermesini geciktirir.
• Üçüncü taraf betikleri. Sohbet widget'ları, ısı haritası araçları ve reklam betikleri INP'nin en sık sebebidir. Her biri tek başına küçük görünür, toplamı ağırdır.
• Aşırı büyük DOM. On binlerce öğe içeren sayfalarda her etkileşim daha pahalıdır.
• Etiket yöneticisi yığılması. Zamanla eklenmiş ama hiç kaldırılmamış etiketler sessizce birikir.

Pratik yaklaşım

Önce envanter çıkarın: sayfada kaç adet üçüncü taraf betiği çalışıyor ve her biri hangi iş için orada? Genellikle bir kısmının artık bir karşılığı olmadığı görülür. Kalanları geciktirmeli yükleme ile ilk etkileşimden sonraya bırakmak çoğu durumda yeterlidir.

CLS — Kümülatif düzen kayması

Ne ölçer

Sayfa yüklenirken içeriğin ne kadar yer değiştirdiği. Okumaya başladığınız metnin aşağı kayması ya da tam basacakken butonun yer değiştirmesi bu metriğe yansır. Birimi yoktur; kayan alanın ve kayma mesafesinin çarpımından türetilen bir puandır.

Kötü çıkmasının yaygın sebepleri

• Boyutu belirtilmemiş görseller. En yaygın sebep budur. Genişlik ve yükseklik belirtilmediğinde tarayıcı yer ayıramaz, görsel indiğinde içerik aşağı itilir.
• Sonradan eklenen bannerlar. Çerez bildirimi, duyuru şeridi ya da reklam alanı içeriğin üstüne girdiğinde her şey kayar.
• Yazı tipi değişimi. Yedek font ile asıl font arasındaki ölçü farkı, metin bloklarının yeniden akmasına yol açar.
• Ölçüsüz gömülü içerik. Harita, video ya da sosyal medya gömülerine sabit yükseklik verilmemesi.

Pratik yaklaşım

CLS, üç metrik arasında düzeltmesi en ucuz olanıdır ve genellikle birkaç saatlik iştir. Her görsele boyut niteliği eklemek, gömülü içeriklere yer ayırmak ve dinamik bannerları içeriğin üstüne değil üzerine (kaydırmadan) yerleştirmek çoğu durumda puanı iyi aralığa taşır.

Saha verisi mi, laboratuvar verisi mi

Bu ayrım, raporları yanlış okumanın bir numaralı sebebidir.

	Saha verisi	Laboratuvar verisi
Kaynak	Gerçek ziyaretçiler	Simüle edilmiş tek test
Kapsam	Son 28 gün	O anki tek ölçüm
Cihaz/ağ	Gerçek dağılım	Sabit, kısıtlanmış
INP ölçülür mü	Evet	Hayır (tahmin edilir)
Ne için kullanılır	Durum tespiti	Sorun teşhisi

Kural şudur: saha verisi neyin sorun olduğunu, laboratuvar verisi nedenini söyler. Yaptığınız iyileştirmenin saha verisine yansıması 28 günlük pencere nedeniyle haftalar alır — bu gecikme normaldir, düzeltmenin işe yaramadığı anlamına gelmez.

Puanı değil, dağılımı okuyun

Tek bir sayı yerine şu üç soruyu sorun:

1. Hangi sayfa şablonu sorunlu? Ana sayfa iyi, ürün sayfaları kötü olabilir. Örneklem sayfa bazında incelenmeli.
2. Mobil mi masaüstü mü? Neredeyse her sitede mobil belirgin şekilde geridedir ve trafiğin çoğunluğu oradadır.
3. Yüzdelik dilim ne durumda? Ortalama iyi görünürken 75. dilim eşiği aşabilir. Değerlendirme dilime göre yapılır.

Hız gerçekten sıralamayı etkiler mi

Etkiler ama abartıldığı kadar değil. Bu ölçümler, içerik uygunluğunun yanında ikincil bir sinyaldir. İçeriği zayıf ve hızlı bir sayfa, içeriği güçlü ve orta hızlı bir sayfayı geçmez.

Asıl etki dönüşüm tarafındadır. Yavaş açılan sayfada ziyaretçi beklemez; bu kayıp, sıralama etkisinden çok daha somuttur. Teknik iyileştirmelerin bütününü teknik SEO ve site optimizasyonu başlığı altında ele alıyoruz.

Öncelik sırası

Sınırlı zamanınız varsa şu sırayla ilerleyin — üstteki maddeler daha az emekle daha çok kazandırır:

1. Görsellere boyut niteliği ekleyin (CLS, birkaç saat)
2. Hero görselini optimize edin ve öncelikli yükleyin (LCP, yarım gün)
3. Kullanılmayan üçüncü taraf betiklerini kaldırın (INP, yarım gün)
4. Sunucu yanıt süresini ve önbelleği gözden geçirin (LCP, değişken)
5. Kritik CSS'i ayırın, gerisini geciktirin (LCP, 1-2 gün)
6. Yazı tipi yükleme stratejisini düzeltin (CLS ve LCP, birkaç saat)

Yardımcı metrikler: sorunun nerede olduğunu söyleyenler

Üç ana metrik bir sorunun var olduğunu söyler; nedenini bulmak için yardımcı ölçümlere bakmak gerekir. Bunlar sıralama sinyali değildir ama teşhiste vazgeçilmezdir.

Metrik	Ölçtüğü	Hedef	Hangi ana metriği açıklar
TTFB	İlk baytın gelme süresi	< 600 ms	LCP
FCP	İlk içeriğin çizilmesi	< 1.8 sn	LCP
TBT	Ana iş parçacığının bloke süresi	< 200 ms	INP
Toplam JS boyutu	İndirilen betik hacmi	< 300 KB (sıkıştırılmış)	INP
DOM öğe sayısı	Sayfadaki düğüm adedi	< 1500	INP, CLS

Teşhis mantığı şöyle işler: LCP kötüyse önce TTFB'ye bakın. TTFB de kötüyse sorun sunucu tarafındadır ve görsel optimizasyonu yapmanın anlamı yoktur. TTFB iyi ama LCP kötüyse sorun ön uçtadır — kaynak yükleme sırası, görsel boyutu veya engelleyici betikler.

Aynı mantık INP için: TBT yüksekse ağır JavaScript, DOM sayısı yüksekse yapısal şişkinlik sorumludur.

Sık karşılaşılan altı senaryo ve çözümleri

Senaryo 1 — Ana sayfa iyi, ürün sayfaları kötü

Genellikle ürün görselleri ve ürün listesindeki öğe sayısından kaynaklanır. Çözüm: görünür alanın dışındaki görsellere gecikmeli yükleme uygulamak, listeyi sayfalamak veya kademeli yüklemek.

Senaryo 2 — Masaüstü iyi, mobil kötü

En yaygın durum. Mobil cihazlar hem daha yavaş işlemciye hem daha değişken ağa sahip. Çözüm: mobilde gereksiz betikleri hiç yüklememek, görselleri cihaz genişliğine göre sunmak.

Kritik nokta: mobil için ayrı bir "hafif sürüm" yapmak yerine, masaüstüne fazladan yükleme yapmak daha sürdürülebilir bir yaklaşımdır.

Senaryo 3 — Skor iyi ama kullanıcı yavaş diyor

Laboratuvar testi iyi, saha verisi kötü olabilir. Test hızlı bir bağlantıdan yapılıyorsa gerçek kullanıcı deneyimini yansıtmaz. Saha verisine bakın; kullanıcı haklıysa oradan görünür.

Senaryo 4 — Yayın sonrası aniden bozuldu

Genellikle yeni eklenen bir üçüncü taraf betiği ya da optimize edilmemiş bir görsel. Değişiklik günlüğüne bakıp o tarihte ne eklendiğini bulmak en hızlı yoldur.

Senaryo 5 — CLS sadece bazı ziyaretlerde yüksek

Koşullu görünen öğelerden kaynaklanır: çerez bildirimi yalnızca ilk ziyarette çıkar, kampanya şeridi yalnızca belirli sayfalarda görünür. Bu öğelere baştan yer ayırmak sorunu çözer.

Senaryo 6 — INP yalnızca belirli etkileşimlerde kötü

Filtreleme, arama ya da sepete ekleme gibi ağır işlemler. Çözüm: işlemi parçalara bölmek ve arada tarayıcıya nefes aldırmak; ya da işlemi arka plana taşımak.

Görsel optimizasyonu: en yüksek getirili müdahale

LCP sorunlarının büyük çoğunluğu görsellerden kaynaklandığı için bu başlığı ayrı açmakta fayda var. Uygulanması gereken beş şey, etki sırasına göre:

1. Doğru boyutta sunun. 400 piksel genişliğinde görünecek bir görselin 2000 piksel gönderilmesi, en yaygın israftır. Cihaz genişliğine göre farklı boyutlar sunun.
2. Modern format kullanın. Aynı görsel kalitesi belirgin şekilde küçük dosyalarla elde edilir; eski formatlar yedek olarak kalabilir.
3. Sıkıştırma seviyesini ayarlayın. Fotoğraflarda %80 civarı kalite, gözle fark edilmeyen bir kayıpla dosyayı yarıya indirir.
4. LCP görselini önceliklendirin. Görünür alandaki büyük görsele gecikmeli yükleme uygulanmamalı; aksine yükleme önceliği yükseltilmelidir.
5. Boyut niteliği verin. Genişlik ve yükseklik belirtildiğinde tarayıcı yer ayırır, kayma oluşmaz.

Bu beş maddeyi uygulamak tipik bir sitede bir günlük iştir ve genellikle üç metriğin ikisini birden iyileştirir.

Üçüncü taraf betikleri: sessiz maliyet

Analitik, sohbet, ısı haritası, reklam pikselleri, sosyal gömüler, yorum sistemleri, çerez yönetimi. Her biri ayrı ayrı küçük görünür; toplamı sayfanın en ağır bileşeni haline gelir.

Envanter çıkarın

Sayfada çalışan tüm dış kaynakları listeleyin ve her biri için üç soru sorun:

• Bu betik hangi karar için veri üretiyor?
• Son üç ayda bu veriye kim baktı?
• Kaldırırsak ne kaybederiz?

Pratikte listenin belirgin bir kısmı üçüncü soruda elenir: bir zamanlar eklenmiş, artık kimsenin bakmadığı araçlar. Etiket yöneticisi kullanan sitelerde bu birikim daha da hızlı olur çünkü ekleme kolaydır, kaldırma kimsenin işi değildir.

Kalanları geciktirin

Zorunlu olmayan betikler ilk etkileşimden sonra yüklenebilir. Kullanıcı sayfayla etkileşime girene kadar sohbet widget'ının yüklenmesine gerek yoktur. Bu tek değişiklik INP üzerinde belirgin fark yaratır.

Performans bütçesi kurmak

Bir kez optimize edilen site, altı ay içinde eski haline döner — çünkü her yeni özellik biraz daha ağırlık ekler. Bunu engelleyen mekanizma performans bütçesidir.

Bütçe, sayısal ve bağlayıcı olmalı:

Kalem	Bütçe	Aşılırsa
Toplam sayfa ağırlığı	1.5 MB	Yeni özellik için eskisinden yer açılır
JavaScript	300 KB	Kullanılmayan kod temizlenir
Üçüncü taraf betik sayısı	6	Yeni ekleme için biri kaldırılır
LCP (saha, 75. dilim)	2.5 sn	Yeni özellik ertelenir

Bütçenin işe yaraması için tek bir kural yeterli: yeni bir şey eklenirken bütçe aşılıyorsa, ya optimizasyon yapılır ya da başka bir şey çıkarılır. Bu kural olmadan bütçe bir dilek listesine dönüşür.

Hız ile dönüşüm arasındaki bağ

Sıralama etkisi tartışmalı olsa da dönüşüm etkisi doğrudan ve ölçülebilir. Kendi sitenizde bu bağı görmek için basit bir analiz yapabilirsiniz: ziyaretleri sayfa yüklenme süresine göre gruplayın ve her grubun dönüşüm oranını karşılaştırın.

Neredeyse her sitede aynı eğri çıkar: yükleme süresi arttıkça dönüşüm oranı düşer ve düşüş ilk saniyelerde en dik olur. Bu eğri, hız yatırımını gerekçelendirmek için sıralama argümanından çok daha ikna edicidir.

Bu analizi yapabilmek için ölçüm altyapısının uygun kurgulanması gerekir; kurulum ayrıntılarını dönüşüm takibi ve raporlama sayfasında topladık. Reklam harcayan siteler için etki daha da somuttur: yavaş açılan bir varış sayfası, tıklama için ödenen bütçenin bir kısmını doğrudan çöpe atar. Bu ilişkiyi reklam bütçesi yazısında hesaplamalı olarak gösterdik.

Ölçüm ritmi

Performans tek seferlik bir iş değil; ancak sürekli ölçüm de gereksiz. Makul bir ritim:

Ne zaman	Ne yapılır
Aylık	Saha verisine bak, üç metriğin eğilimini kaydet
Her yayın sonrası	Değişen şablonu laboratuvar testinden geçir
Yeni üçüncü taraf betiği eklenince	INP'yi ölçüp bütçeyle karşılaştır
Çeyreklik	Betik envanterini gözden geçir, kullanılmayanları çıkar

Üçüncü satır en kritik olanı: performans bozulmalarının büyük kısmı yeni eklenen betiklerden gelir ve ekleme anında ölçülmediğinde aylar sonra fark edilir.

Sık sorulan sorular

100 puan almak gerekiyor mu?

Hayır. Üç metrikte de iyi aralıkta olmak yeterlidir; bunun ötesindeki çaba genellikle azalan getiri üretir. Aynı emeği içerik tarafına ayırmak daha yüksek karşılık verir.

Ölçümler her seferinde farklı çıkıyor, neden?

Laboratuvar testi tek bir anlık ölçümdür; ağ koşulları ve sunucu yükü sonucu etkiler. Karar verirken saha verisine bakın, laboratuvar testini yalnızca teşhis için kullanın.

Eklentiyle düzeltilebilir mi?

Önbellek eklentileri sunucu yanıt süresini iyileştirir ve bu gerçek bir kazanımdır. Ancak CLS ve INP sorunları yapısaldır; eklenti bunları maskeleyebilir ama çözmez.

Hangi sayfaları ölçmeliyim?

Trafiğin çoğunu alan üç şablonu seçin: genellikle ana sayfa, bir hizmet/ürün sayfası ve bir yazı sayfası. Tüm sayfaları tek tek ölçmek gereksizdir; sorunlar şablon düzeyinde tekrarlar.

Yeni yayına giren sitede saha verisi yoksa ne yapmalı?

Yeterli trafik birikene kadar yalnızca laboratuvar verisi görünür. Bu dönemde hedef, temel iyi uygulamaları baştan doğru kurmaktır; ölçüm birkaç hafta sonra anlam kazanır. Yeni site süreçlerinde bunun nasıl planlandığını proje takvimi yazısında anlattık.

Hız iyileştirmesi ne kadar sürer?

Görsel optimizasyonu ve düzen kayması düzeltmeleri bir günlük iştir. Sunucu ve mimari kaynaklı sorunlar günler alabilir. Saha verisine yansıması ise 28 günlük pencere nedeniyle her koşulda 3-4 hafta sürer.

Tek bir sayfa yavaşsa tüm site etkilenir mi?

Değerlendirme sayfa bazındadır, ancak sorunlar genellikle şablon düzeyinde olduğu için aynı şablonu kullanan tüm sayfalara yayılır. Bu yüzden düzeltme de şablon düzeyinde yapılmalıdır.

Özet

Üç metrik üç farklı soruya cevap verir: sayfa ne zaman göründü (LCP), dokunduğumda ne zaman tepki verdi (INP), okurken altımdan kaydı mı (CLS). Skorun kendisi değil, bu üç sorunun cevabı önemlidir.

Mevcut durumunuzu görmek için önce saha verisine bakın, sorunlu şablonu belirleyin, sonra laboratuvar testiyle nedenini bulun. Bu sırayı takip etmek, rastgele optimizasyon denemelerinden çok daha hızlı sonuç verir. Kapsamlı bir tarama isterseniz iletişim sayfasından ulaşabilirsiniz.

Bu üç metriğin bir sitede nasıl sıfıra yakın tutulduğunu merak ediyorsanız, kendi sitemizi NextLab Creative marka ve web sitesi projesinde anlattık; koyu arayüz ve görsel ölçüleri CLS hedefiyle birlikte kararlaştırıldı.