Core Web Vitals, Google’ın bir web sayfasının kullanıcı deneyimini ölçmek için tanımladığı üç temel performans metriğinden oluşan ölçüm setidir. Bu üç metrik LCP (Largest Contentful Paint), INP (Interaction to Next Paint) ve CLS (Cumulative Layout Shift) adlarını taşır. Her biri sayfanın farklı bir yönünü ölçer: içeriğin yüklenme hızı, etkileşimlere verilen tepki süresi ve düzenin görsel kararlılığı.
Bu rehberde üç metriğin eşik değerlerini, ölçüm araçlarını ve iyileştirme adımlarını bulacaksınız. Ayrıca sunucu altyapısının bu değerlere etkisini, TTFB ile LCP arasındaki bağı ve metriklerin sıralamadaki ağırlığını ele alıyoruz.
Core Web Vitals ne demek?
Core Web Vitals, sayfa deneyimini ölçülebilir hale getiren metrik setinin adıdır. Google bu seti Mayıs 2020’de duyurdu ve 2021 yazında arama sıralaması sinyalleri arasına dahil etti. Setin bugünkü hali üç metrikten oluşur:
| Metrik | Ölçtüğü şey | İyi | İyileştirilmeli | Zayıf |
|---|---|---|---|---|
| LCP | Yükleme hızı | 2,5 sn ve altı | 2,5 – 4,0 sn | 4,0 sn üzeri |
| INP | Etkileşim tepkisi | 200 ms ve altı | 200 – 500 ms | 500 ms üzeri |
| CLS | Görsel kararlılık | 0,1 ve altı | 0,1 – 0,25 | 0,25 üzeri |
Mart 2024’te setin bileşimi değişti. O tarihe kadar üçüncü metrik olan FID (First Input Delay) kaldırıldı ve yerini INP aldı. FID artık kullanılmıyor; eski raporlarda görebilirsiniz ama Google bu metriği veri setlerinden tamamen çıkardı.
Core Web Vitals değerlendirmesinde ölçüm mantığı da önemlidir. Google ortalama almaz, 75. persentili kullanır: sayfa görüntülemelerinizin en az %75’i iyi aralıkta kalmalıdır. Mobil ve masaüstü trafiği ayrı değerlendirilir; masaüstünde iyi görünen bir site mobilde zayıf çıkabilir.
LCP (Largest Contentful Paint) nedir ve kaç saniye olmalı?
LCP, görüntü alanı içindeki en büyük içerik öğesinin ekrana çizilmesine kadar geçen süredir. İyi kabul edilen değer 2,5 saniye ve altıdır; 4 saniyeyi aşan LCP zayıf sayılır.
LCP öğesi çoğu sayfada kapak görseli, video poster karesi, CSS arka plan görseliyle yüklenen bir blok ya da büyük bir metin bloğudur. Hangi öğenin LCP olduğunu tahmin etmeyin; Chrome DevTools’un Performance paneli bunu doğrudan işaretler.
LCP tek parça bir süre değildir, dört alt bölüme ayrılır:
- TTFB — sunucudan ilk baytın gelmesi
- Kaynak yükleme gecikmesi — tarayıcının LCP kaynağını keşfedip indirmeye başlaması arasındaki boşluk
- Kaynak yükleme süresi — dosyanın indirilmesi
- Öğe render gecikmesi — indirilen kaynağın ekrana çizilmesi
Google’ın önerdiği dağılım, sürenin yaklaşık %40’ının TTFB’ye, %40’ının kaynak yükleme süresine ve kalan %20’sinin iki gecikme kalemine ayrılmasıdır. Böylece hangi adımın anormal olduğunu ayırt edebilirsiniz. WordPress kullanıyorsanız bu adımların çoğu tema, eklenti ve önbellek katmanında çözülür; ayrıntılar için WordPress sitenizi hızlandırma yöntemleri yazımıza bakabilirsiniz. Core Web Vitals çalışmasında LCP genellikle ilk ele alınacak metriktir; diğer ikisine göre daha çok sayfada zayıf çıkar.
INP (Interaction to Next Paint) nedir?
INP, kullanıcının sayfayla kurduğu etkileşimlerin görsel yanıt üretme süresini ölçen metriktir. İyi kabul edilen değer 200 milisaniye ve altıdır; 500 ms üzeri zayıf sayılır.
INP tıklama, dokunma ve klavye girişlerini kapsar; fare hareketi ve sayfa kaydırma hesaba katılmaz. Metrik, sayfa ömrü boyunca gerçekleşen etkileşimler arasından en uzun süreni raporlar. Çok etkileşim alan sayfalarda uç değerleri elemek için 98. persentile yakın bir örnek seçilir.
Bir etkileşimin INP süresi üç parçadan oluşur:
- Giriş gecikmesi (input delay): Ana iş parçacığı meşgulken tarayıcının olayı işlemeye başlayamadığı süre.
- İşleme süresi (processing duration): Olay dinleyicilerinin çalıştığı süre.
- Sunum gecikmesi (presentation delay): Sonucun bir sonraki karede ekrana çizilmesi.
Eski FID metriğinden farkı burada netleşir. FID yalnızca ilk etkileşimin giriş gecikmesini ölçüyor, işleme ve çizim sürelerini görmezden geliyordu. Ağır JavaScript çalıştıran sayfalar bu yüzden FID’de iyi görünürken kullanıcıya yavaş hissettiriyordu. INP bu boşluğu kapatır ve Core Web Vitals setini gerçek kullanım deneyimine yaklaştırır.
INP sorunlarının kaynağı neredeyse her zaman JavaScript’tir: 50 ms’yi aşan uzun görevler, ağır olay dinleyicileri, üçüncü taraf betikleri ve tek seferde yapılan büyük DOM güncellemeleri. Uzun görevleri küçük parçalara bölüp ana iş parçacığını serbest bırakmak en etkili yöntemdir.
CLS (Cumulative Layout Shift) nedir?
CLS, sayfa yüklenirken görsel öğelerin beklenmedik biçimde yer değiştirmesini ölçen birimsiz bir puandır. İyi kabul edilen değer 0,1 ve altıdır; 0,25 üzeri zayıf sayılır.
Puan, her kaymanın etki kesri (ekranın ne kadarının etkilendiği) ile mesafe kesrinin (öğelerin ne kadar uzağa gittiği) çarpımıdır. Google bu kaymaları oturum penceresi mantığıyla gruplar: ardışık kaymalar arasında 1 saniyeden az boşluk varsa aynı pencerede sayılır ve bir pencere en fazla 5 saniye sürer. Sayfanın CLS değeri, en yüksek puanlı pencerenin puanıdır. Kullanıcı etkileşiminden sonraki 500 ms içindeki kaymalar sayılmaz; menü açılışı gibi beklenen değişiklikler puanı bozmaz.
Core Web Vitals içinde CLS genellikle en kolay düzeltilen metriktir. Yaygın nedenler ve çözümleri şunlardır:
- Boyutsuz görseller: Görsel etiketlerine width ve height özniteliği ya da CSS’te aspect-ratio verin.
- Geç yüklenen reklam, iframe ve embed alanları: Konteynere sabit minimum yükseklik tanımlayın.
- Web fontu değişimi: font-display: optional kullanın veya kritik fontu preload ile erken çekin.
- Sonradan eklenen bildirim çubukları: Alan rezerve edin veya öğeyi akışın dışına alın.
- Animasyonlar: top, left, height yerine transform üzerinden animasyon yapın.
Core Web Vitals değerleri nasıl ölçülür?
Core Web Vitals iki farklı veri türüyle ölçülür: gerçek kullanıcılardan toplanan saha verisi ve kontrollü ortamda üretilen laboratuvar verisi. Sıralama tarafında yalnızca saha verisi dikkate alınır.
Saha verisinin kaynağı CrUX’tur (Chrome User Experience Report). CrUX, veri paylaşımına izin vermiş Chrome kullanıcılarından ölçüm toplar ve 28 günlük kayan pencere üzerinden raporlar. Bu yüzden bugünkü bir iyileştirmenin rapora tam yansıması yaklaşık dört hafta sürer. Yeterli trafik almayan sayfalarda Google, kaynak (origin) seviyesindeki toplu veriyi gösterir.
Pratikte kullanacağınız araçlar şunlardır:
- Search Console → Temel Web Verileri raporu: Siteyi benzer URL gruplarına ayırır; öncelik belirlemek için en uygun araçtır.
- PageSpeed Insights: Tek URL için CrUX saha verisi ile Lighthouse laboratuvar verisini yan yana verir.
- Chrome DevTools Performance paneli: LCP öğesini ve uzun görevleri tek tek gösterir.
- web-vitals JavaScript kütüphanesi: Kendi analitiğinize gerçek kullanıcı ölçümü (RUM) gönderir.
Bir uyarı: laboratuvar araçları INP ve CLS’i tam ölçemez, çünkü bu metrikler gerçek kullanıcı etkileşimi gerektirir. Lighthouse, INP yerine TBT (Total Blocking Time) değerini vekil metrik olarak raporlar. Lighthouse’ta 100 puan almanız, sahada Core Web Vitals’ı geçtiğiniz anlamına gelmez.
Hosting ve sunucu performansı Core Web Vitals’ı nasıl etkiler?
Hosting altyapısı Core Web Vitals’ı en çok LCP üzerinden etkiler, çünkü sayfanın ilk baytı sunucudan gelir ve bu süre LCP’nin zorunlu parçasıdır. INP ve CLS ise ağırlıklı olarak ön yüz kodunun sorumluluğundadır.
Sunucu tarafında sonucu belirleyen başlıca faktörler:
- Sunucu konumu: Ziyaretçileriniz Türkiye’deyse yurt içi lokasyon, uzak veri merkezlerine kıyasla gidiş-dönüş süresini (RTT) belirgin biçimde düşürür.
- Disk ve işlemci: NVMe SSD ve güncel işlemci, veritabanı ağırlıklı sayfalarda üretim süresini kısaltır.
- Kaynak paylaşımı: Yoğun paylaşımlı ortamlarda komşu hesapların yükü yanıt sürenizi dalgalandırır; kaynak garantili paketler bunu azaltır.
- PHP sürümü ve OPcache: Güncel sürüm ve açık OPcache, dinamik sayfa üretimini hızlandırır.
- Protokol desteği: HTTP/2 veya HTTP/3 ve TLS 1.3, bağlantı kurulum maliyetini düşürür.
- Sunucu tarafı önbellek: Sayfa ve Redis nesne önbelleği, veritabanı sorgularını atlayarak TTFB’yi milisaniyeler seviyesine indirir.
Bu kalemlerin çoğu paket seviyesinde belirlenir; kaynak garantisi ve altyapı tercihleri için Verimin kurumsal hosting paketlerini inceleyebilirsiniz. Yazılım tarafında ne kadar optimizasyon yaparsanız yapın, yavaş bir sunucu Core Web Vitals’ta tavan oluşturur.
TTFB ile LCP arasındaki ilişki nedir?
TTFB (Time to First Byte), LCP’nin ilk bileşenidir ve LCP değeri matematiksel olarak TTFB’nin altına inemez. Bu yüzden Core Web Vitals çalışmasında TTFB, LCP bütçesinin taban çizgisidir.
Google’ın TTFB için verdiği referans eşikler şöyledir: 800 ms ve altı iyi, 800-1800 ms arası iyileştirilmeli, 1800 ms üzeri zayıf. LCP’nin iyi eşiği 2,5 saniye olduğuna göre 800 ms’lik bir TTFB, bütçenin yaklaşık üçte birini tüketir. TTFB 1,5 saniyeye çıktığında geriye indirme ve çizim için 1 saniyeden az kalır; kapak görselinin zamanında yüklenmesi artık mümkün değildir.
TTFB’nin kendisi de birkaç adımdan oluşur: yönlendirmeler, DNS çözümlemesi, TCP bağlantısı, TLS anlaşması ve sunucunun yanıtı üretmesi. Gereksiz bir 301 zinciri tek başına 200-400 ms ekleyebilir. Hangi adımın uzadığını DevTools’un Network sekmesinden ayrıştırabilirsiniz.
LCP nasıl iyileştirilir?
LCP iyileştirmesi, metriğin dört alt bölümünü sırayla ele alarak yapılır. Core Web Vitals raporunda LCP zayıf çıkıyorsa aşağıdaki adımları bu sırayla uygulayın.
1. TTFB’yi düşürün. Sunucu tarafı sayfa önbelleği açın, veritabanı sorgularını azaltın, gereksiz yönlendirmeleri kaldırın ve statik varlıklar için CDN kullanın. Bu adım atlanırsa sonrakilerin etkisi sınırlı kalır.
2. LCP öğesini erken keşfettirin. LCP görselini asla lazy loading ile işaretlemeyin; bunun yerine fetchpriority high verin. CSS arka planı olarak yükleniyorsa preload ile HTML’in başında ilan edin. Kaynağın geç keşfedilmesi en sık görülen gecikme nedenidir.
3. Kaynak boyutunu küçültün. Kapak görselini WebP veya AVIF formatında sunun, srcset ile cihaza uygun boyutu gönderin. 1200 piksellik bir alana 3000 piksellik görsel koymak yaygın bir hatadır.
4. Render engelleyen kaynakları azaltın. Kritik CSS’i satır içine alın, geri kalanını asenkron yükleyin. Head’deki senkron JavaScript dosyalarını defer veya async ile işaretleyin, üçüncü taraf betiklerini kritik yoldan çıkarın.
5. Fontları kontrol altına alın. LCP öğesi metin bloğuysa font dosyası inene kadar metin çizilmeyebilir. font-display swap ve kritik fontun preload edilmesi bu beklemeyi ortadan kaldırır.
Her değişiklikten sonra saha verisinin güncellenmesi 28 günlük CrUX penceresinin dolmasını gerektirir. Ara kontrolleri laboratuvar ölçümleriyle veya kendi RUM verinizle yapın.
Core Web Vitals arama sıralamasını etkiler mi?
Evet, Core Web Vitals Google’ın sıralama sinyalleri arasında yer alır; ancak etkisi içerik kalitesine kıyasla sınırlıdır. Google bu sinyalleri, benzer alaka düzeyine sahip sayfalar arasında ayrım yapan bir faktör olarak tanımlar.
Pratik karşılığı şudur: zayıf Core Web Vitals değerleri, konuya birebir uyan güçlü bir içeriği ilk sayfadan düşürmez. Ama rekabetin yoğun olduğu bir sorguda benzer kalitedeki iki sayfa arasında dengeyi belirleyebilir. Google, sayfa deneyimini 2023 sonunda ayrı bir güncelleme olarak listelemeyi bıraktı; sinyaller sıralama sistemlerinin içinde kalmaya devam ediyor.
Metriklerin dolaylı etkisi ise doğrudan etkisinden büyüktür. Yavaş yüklenen ve geç tepki veren sayfalar terk oranını yükseltir, dönüşümü düşürür. Core Web Vitals’ı bir sıralama kalemi olarak değil, ölçülebilir bir kullanıcı deneyimi göstergesi olarak ele almak daha doğru bir yaklaşımdır.
Özet
- Core Web Vitals üç metrikten oluşur: LCP (yükleme, iyi 2,5 sn ve altı), INP (etkileşim, iyi 200 ms ve altı) ve CLS (görsel kararlılık, iyi 0,1 ve altı).
- FID artık kullanılmıyor. Mart 2024’te setten çıkarıldı ve yerine, tüm etkileşimleri uçtan uca ölçen INP geldi.
- Değerlendirme 75. persentil üzerinden yapılır; saha verisi CrUX’un 28 günlük penceresinden gelir, laboratuvar skorları sıralamada kullanılmaz.
- TTFB, LCP’nin tabanıdır. 800 ms’yi aşan bir TTFB, 2,5 saniyelik LCP hedefini zorlaştırır; iyileştirme bu yüzden sunucudan başlar.
- Sıralama etkisi bir eşitlik bozucu düzeyindedir. İçerik kalitesinin yerini tutmaz; dolaylı etkisi ise dönüşüm oranında görülür.
