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

Core Web Vitals, “sayfa hızlı mı?” sorusunu tek bir saniye değeriyle cevaplamaz. Bunun yerine kullanıcının gerçekte hissettiği üç ayrı deneyim boyutuna bakar: içerik ne kadar hızlı yükleniyor, sayfa etkileşime ne kadar hızlı yanıt veriyor ve görsel olarak ne kadar kararlı duruyor. Google 2021’den beri bu üç metriği bir sayfa deneyimi sıralama sinyali olarak kullanıyor.

Bu rehberi 12 yıllık WordPress ve SEO deneyimimle, kendi siteme uyguladığım gerçek ölçüm verileri üzerinden yazdım. Aşağıda göreceğiniz her sayı uydurma değil. Hepsi barisdayak.com’un Google PageSpeed Insights API’siyle alınmış ölçümlerinden ve Türkiye’den yaptığım bağımsız testlerden geliyor. Amacım her metriği tanımlamakla kalmayıp, hangi araçla nasıl ölçüleceğini ve en sık yapılan yorumlama hatasını da göstermek.

Core Web Vitals’ın Üç Metriği

Core Web Vitals, Google’ın 2020’de tanıttığı ve o tarihten beri kademeli olarak güncellediği bir performans metrik setidir. Amaç, sayfa deneyimini üç somut boyutta ölçmektir. Google’ın konuyla ilgili resmi teknik dokümantasyonu web.dev Web Vitals sayfasında yayınlanır ve düzenli güncellenir.

LCP: Yükleme Hızı

Largest Contentful Paint, görüntü alanındaki en büyük içerik öğesinin render edilme anını ölçer. Bu öğe genellikle hero görseli, video posteri veya büyük bir başlık bloğudur. Kullanıcının “sayfa açıldı” dediği an budur.

LCP’yi belirleyen dört ana faktör vardır: sunucu yanıt süresi (TTFB), render’ı bloklayan CSS/JS dosyaları, LCP kaynağının indirme süresi ve o kaynağın keşfedilme gecikmesi. Yaygın bir yanılgı, LCP’nin “sayfanın tamamen yüklenmesi” olduğudur. Oysa yalnızca görüntü alanındaki en büyük tek öğenin çizilmesidir. Sayfanın alt kısmındaki ağır bir görsel LCP’yi etkilemez; ilk ekrandaki hero görseli ise her şeyi belirler.

INP: Yanıt Verme Hızı

Interaction to Next Paint, 2024 Mart’ında FID (First Input Delay) metriğinin yerini aldı. FID yalnızca ilk etkileşimin gecikmesini ölçüyordu. INP ise sayfa ömrü boyunca gerçekleşen tüm etkileşimlere bakar ve en kötüye yakın olanı raporlar.

Bir menü açılırken, bir filtre uygulanırken veya form gönderilirken tarayıcının ana iş parçacığı meşgulse INP kötüleşir. WordPress’te INP’yi bozan tipik suçlu, ağır jQuery bağımlılıkları ve slider veya popup eklentilerinin uzun görevleridir.

INP’nin diğer iki metrikten farkı şudur: LCP ve CLS büyük ölçüde sayfa yüklenirken belirlenir, INP ise kullanıcı sayfayla etkileştikçe ölçülür. Bu yüzden statik bir blog yazısında INP nadiren sorun olur. Ama filtreli bir ürün listesinde veya çok adımlı bir formda kritik hale gelir.

CLS: Görsel Kararlılık

Cumulative Layout Shift, sayfa yüklenirken beklenmedik biçimde yer değiştiren öğelerin toplam etkisidir. Boyutu belirtilmemiş görseller, geç yüklenen web fontları, dinamik olarak enjekte edilen çerez bildirimleri ve reklam blokları CLS’nin ana kaynaklarıdır. Kullanıcının tıklamak istediği butonun son anda kaymasıdır bu. Hem sinir bozucu, hem de yanlış tıklamaya yol açan bir deneyimdir.

CLS diğer ikisinden farklı olarak birimsizdir. Saniye veya milisaniye değil, bir orandır ve 0’a ne kadar yakınsa o kadar iyidir. Google’ın CLS dokümantasyonu, hesaplamanın etki payı ile mesafe payı çarpımına dayandığını açıklar.

Eşik Değerleri Tablosu

Kritik nokta: Google bu eşikleri 75. yüzdelik dilim üzerinden değerlendirir. Yani ziyaretçilerinizin %75’i eşiği geçiyorsa metrik “iyi” sayılır. Ortalama değil, yüzdelik dilim.

Bu ayrım önemli, çünkü ortalamalar yavaş cihazlardaki kötü deneyimi gizler. Diyelim ki kullanıcılarınızın %70’i çok hızlı, %30’u çok yavaş bir deneyim yaşıyor. Ortalama “iyi” görünebilir ama 75. yüzdelik dilim eşiği geçmediği için metrik “kötü” raporlanır.

Destekleyici Metrikler

Üç çekirdek metrik dışında, tanı koyarken baktığım yardımcı metrikler var. Bunlar doğrudan sıralama sinyali değildir ama sorunun kaynağını gösterir:

Core Web Vitals Nasıl Ölçülür?

Optimizasyona başlamadan önce mevcut durumu sayıyla kaydetmek şart. “Sitem yavaş hissettiriyor” bir veri değildir. İzlediğim ölçüm sırası şu:

1. PageSpeed Insights ile Başlayın

Google’ın PageSpeed Insights aracına sitenizin URL’sini girin. Rapor iki bölüm halinde gelir: üstte gerçek kullanıcı verisi (varsa), altta Lighthouse laboratuvar analizi.

Önce Mobil sekmesine bakın. Google’ın indeksleme önceliği mobildir; masaüstü skoru güzel görünse bile karar mobilde verilir. “En büyük içerikli boyama öğesi” satırını genişletin; LCP’nin hangi öğe olduğunu tam olarak söyler. Optimizasyonun ilk hedefi odur.

2. Search Console’da Core Web Vitals Raporunu Açın

Google Search Console‘daki Deneyim > Core Web Vitals raporu, PageSpeed’den farklı bir şey gösterir. Tek bir URL’yi değil, sitenizin tamamını gerçek kullanıcı verisiyle gruplar halinde raporlar. URL’ler “benzer sayfalar” olarak gruplanır; bir blog şablonundaki sorun tüm blog yazılarını aynı anda etkiler.

Bir düzeltme yayınladıktan sonra “Doğrulamayı başlat” butonuna basın; Google 28 günlük veri penceresiyle yeniden değerlendirir. Bu pencere kritik: bugün yaptığınız iyileştirmenin rapora yansıması haftalar sürer, panik yapıp geri almayın.

3. Sunucu Yanıt Süresini Bağımsız Ölçün

Lighthouse’un TTFB değeri Google’ın test sunucusundan alınır. Hedef kitleniz Türkiye’deyse gerçek durumu kendi bağlantınızdan ölçmelisiniz. Terminalden:

curl -o /dev/null -s -w "DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nToplam: %{time_total}\n" https://siteniz.com/

Bu komutu 5-10 kez çalıştırıp ortalama alın. Tek ölçüm yanıltıcıdır çünkü ilk istek önbelleği ısıtır.

4. Gerçek Kullanıcı Ölçümü (RUM) Kurun

Alan veriniz yoksa (bunu aşağıda açıklıyorum), kendi gerçek kullanıcı ölçümünüzü kurmak en sağlıklı yoldur. Google’ın açık kaynaklı web-vitals JavaScript kütüphanesi, LCP, INP ve CLS değerlerini tarayıcıdan okuyup istediğiniz uç noktaya gönderir. Yaklaşık 2 KB’lık bir script, CrUX eşiğine takılmadan gerçek kullanıcı verisi verir. Bu, düşük trafikli siteler için tek güvenilir alan verisi kaynağıdır.

Laboratuvar Verisi ile Alan Verisi (CrUX) Farkı

Bu bölüm rehberin en önemli kısmı ve çoğu Türkçe kaynakta ya hiç yok ya da tek cümleyle geçiştirilmiş. Oysa hız optimizasyonunda alınan yanlış kararların büyük kısmı bu iki veri tipinin karıştırılmasından doğuyor.

Laboratuvar verisi (lab data), Lighthouse’un kontrollü bir ortamda yaptığı simülasyondur. Sabit bir cihaz profili (orta seviye Android benzeri), sabit bir ağ kısıtlaması (yavaşlatılmış 4G) ve tek bir sayfa yüklemesi kullanır. Cevapladığı soru şudur: “Bu sayfa, standart koşullarda ve şu anki kodla nasıl davranıyor?”

Alan verisi (field data / CrUX), Chrome User Experience Report‘un gerçek Chrome kullanıcılarından anonim olarak topladığı verilerdir. Farklı cihazlar, farklı ağlar, farklı coğrafyalar, farklı önbellek durumları söz konusudur. Cevapladığı soru şudur: “Gerçek ziyaretçilerim son 28 günde ne yaşadı?”

Temel Farklar Tablosu

Kritik Ayrım: INP Laboratuvarda Ölçülemez

Lighthouse size INP değeri vermez. Veremez, çünkü INP kullanıcının tıklamasını gerektirir ve laboratuvar testinde tıklayan kimse yoktur. Lighthouse bunun yerine TBT (Total Blocking Time) raporlar; ana iş parçacığının 50 ms’yi aşan görevlerle ne kadar bloke olduğunu ölçer.

TBT düşükse INP’nin de büyük ihtimalle iyi olacağını varsayarız, ama bu bir korelasyondur, garanti değil. Pratik sonuç şudur: Lighthouse’da 100 alıp sahada INP’den kalabilirsiniz. Özellikle ağır etkileşim içeren sayfalarda (filtreli ürün listeleri, çok adımlı formlar, canlı arama) bu sık görülür.

Hangi Veriye Ne Zaman Bakılır

Kullandığım basit kural şu:

• Sorunu bulmak için laboratuvar verisi. Hangi dosya render’ı blokluyor, hangi görsel LCP, hangi script uzun görev üretiyor? Bunları yalnızca Lighthouse söyler.
• Sorunun gerçekten var olup olmadığına karar vermek için alan verisi. Lighthouse “şu 340 KB’lık CSS’i küçült” der; alan verisinde LCP zaten 1,8 saniyedeyse bu iş öncelikli değildir.
• Alan verisi yoksa laboratuvar ölçümünü sabit koşullarda tekrarlayın (aynı saat, aynı ağ, üç ölçümün medyanı) ve kendi RUM’ınızı kurun.

Alan verisi olmayan bir sitede tek bir Lighthouse skoruna bakıp “sorun yok” demek, alan verisi olan bir sitede Lighthouse skorunu kovalamak kadar hatalıdır.

Her Metrik Nasıl İyileştirilir?

Ölçümü yaptınız, hangi metriğin sorunlu olduğunu buldunuz. Şimdi metrik bazında ne yapılacağına bakalım. Her metriğin kök nedeni farklıdır; bu yüzden “siteyi hızlandırma” diye genel bir müdahale yerine, sorunlu metriğe özel çalışmak gerekir.

LCP’yi İyileştirmek

LCP çoğu zaman bir görseldir. Sıralı yaklaşım şu: önce sunucu yanıt süresini (TTFB) düşürün. Bunun için önbellek, iyi hosting ve CDN kullanılır. Ardından LCP görselini WebP veya AVIF ile sıkıştırın, fetchpriority="high" ile önceliklendirin ve lazy loading’i mutlaka kaldırın. İlk ekrandaki görsele lazy loading uygulamak LCP’yi doğrudan geciktirir.

Son olarak render’ı bloklayan CSS/JS’i erteleyin ve LCP kaynağını preload ile erken keşfedilir yapın. Görsel tarafının tüm detaylarını görsel optimizasyonu: WebP ve AVIF rehberinde ele aldım.

INP’yi İyileştirmek

INP sorununun kaynağı neredeyse her zaman JavaScript’tir. Uzun görevleri (long tasks) parçalayın, kullanılmayan JS’i kaldırın, üçüncü taraf scriptleri (canlı destek, harita gömme, analitik) etkileşimle tetiklenecek şekilde geciktirin.

WordPress’te ağır slider ve popup eklentileri en sık suçludur; bunları hafif alternatiflerle değiştirmek genelde tek başına INP’yi kurtarır. Ana iş parçacığını meşgul eden her şey INP’yi bozar. Hedef, kullanıcı tıkladığında tarayıcının boşta olmasıdır.

CLS’yi İyileştirmek

Her <img> etiketine width ve height özniteliği ekleyin. Tarayıcı bu iki değerden oranı hesaplar ve görsel gelmeden yer ayırır. Web fontlarını font-display: swap ile yükleyin. Dinamik olarak enjekte edilen öğeler (çerez bildirimi, reklam, banner) için sabit alan (min-height veya aspect-ratio) rezerve edin.

CLS, üç metrik içinde genellikle en kolay düzeltilenidir; çünkü kaynağı görünür ve çözümü mekaniktir.

Önbelleğin Rolü

Önbellekleme öncelikle TTFB’yi düşürür, dolayısıyla LCP’yi dolaylı iyileştirir. Ama hangi eklentinin sunucunuza uygun olduğu ve nasıl yapılandırılacağı ayrı bir konudur. Altı popüler seçeneği WordPress önbellek eklentileri karşılaştırmasında yan yana koydum.

Core Web Vitals’ta En Sık Yapılan 5 Hata

Devraldığım sitelerde tekrar tekrar gördüğüm, ölçümü ve optimizasyonu boşa çıkaran hatalar:

1. Skoru hedef sanmak. PageSpeed 100 bir amaç değil, tanı aracıdır. 92 puanla üç metriği de yeşil olan site, 100 puanla sahada INP’den kalan siteden iyidir.
2. Sadece ana sayfayı ölçmek. Ana sayfa genellikle en iyi optimize edilmiş sayfadır. Asıl trafiği alan kategori, ürün ve blog şablonlarını ayrı ölçmek gerekir.
3. Yönetici olarak giriş yapıp ölçmek. Giriş yaptığınızda admin bar yüklenir, önbellek devre dışı kalabilir ve sonuç tamamen yanıltıcı olur. Her zaman gizli sekmede, oturum kapalı ölçün.
4. Lab ve alan verisini karıştırmak. Yukarıda uzun uzun anlattığım bu ayrım, yanlış kararların bir numaralı sebebidir.
5. Düzeltme sonrası hemen sonuç beklemek. Alan verisi 28 günlük kayan pencereyle güncellenir. Bugünkü düzeltmeyi yarın Search Console’da görmeyi beklemeyin.

Gerçek Vaka: Bu Sitede Ölçülen Değerler

Yukarıdaki her maddeyi kendi siteme uyguladım. Google PageSpeed Insights API’siyle aldığım ölçüm sonuçları şöyle:

Lighthouse’un TTFB değeri Google’ın test altyapısından geliyor. Gerçek durumu görmek için Türkiye’den curl ile ölçtüm; ortalama 229 ms çıktı. Dökümü şöyle:

Bu dökümün bana söylediği şey şudur: sunucunun HTML üretme süresi yalnızca 64 ms. Yani PHP tarafı zaten optimize. Kalan 165 ms’nin tamamı ağ katmanında; DNS, TCP ve TLS aşamalarında.

Bu noktadan sonra eklenti temizliği veya veritabanı optimizasyonu yapmanın hiçbir anlamı yok. Kazanç ancak bağlantı katmanından gelir: HTTP/3, oturum yeniden kullanımı ve coğrafi yakınlık. Bu ayrımı yapmadan optimizasyona girişmek, en yaygın zaman kaybıdır.

Bir not daha: PageSpeed raporunda CrUX alan verisi bölümü boştu. Sitenin Chrome trafiği, Google’ın anonimlik eşiğini geçmiyor. Bu, çoğu KOBİ ve freelance sitesinin durumudur ve bir kusur değildir. Böyle bir durumda kendi RUM ölçümünüzü kurmak, tek Lighthouse skoruna güvenmekten daha sağlıklıdır.

Core Web Vitals, WordPress hızının yalnızca ölçüm ayağıdır. Önbellekleme, görsel optimizasyonu, sunucu sıkılaştırması ve e-ticaret hızı dahil tüm katmanların özetini WordPress site hızı ana rehberinde bir arada topladım. E-ticaret mağazanız varsa, WooCommerce’in kendine özgü hız sorunlarını WooCommerce hız optimizasyonu rehberinde ayrı ele aldım.

Sıkça Sorulan Sorular

Bu yazıları da okumak isteyebilirsiniz ...

Sağlık Turizmi Web Sitesi: Yetki, Hasta Akışı ve Ülke Stratejisi

Diş Kliniği Web Sitesi: Yerel Görünürlük ve Randevu Kurulumu

Estetik Klinik Web Sitesi: Galeri, İşlem Sayfaları ve Güven Kurulumu

Saç Ekimi Kliniği Web Sitesi: Çok Dilli ve Mevzuata Uygun Kurulum

Yazar Hakkında

Barış Dayak

2014'ten bu yana web tasarım, WordPress ve SEO & AI görünürlük alanlarında 500'den fazla işletmeye hizmet veriyorum.