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

Kısaca: Core Web Vitals, gerçek kullanıcıların sayfanızı nasıl deneyimlediğini üç metrikle ölçer: LCP (ana içeriğin yüklenme hızı, hedef ≤ 2,5 sn), INP (etkileşimlere tepki süresi, hedef ≤ 200 ms) ve CLS (görsel kararlılık, hedef ≤ 0,1). Değerlendirme, sayfa yüklemelerinin %75'inde bu hedeflerin tutturulmasına göre yapılır. Google bu metrikleri sıralama sistemlerinde dikkate aldığını söylüyor; ancak iyi skor tek başına üst sıra garantisi değildir. Asıl kazanım, ziyaretçinin siteden hızlı ve sorunsuz sonuç alması, dolayısıyla dönüşümün artmasıdır.

Son güncelleme: Eylül 2026

Core Web Vitals nedir?

Core Web Vitals, Google'ın bir sayfanın kullanıcı deneyimini ölçmek için belirlediği temel metrik kümesidir. web.dev'in tanımına göre üç metrikten oluşur:

Değerlendirme 75. yüzdelik dilimde yapılır: sayfa yüklemelerinin en az %75'i “iyi” eşiğini karşılıyorsa o metrik başarılı sayılır. INP, 2024'te tarihe karışan FID (First Input Delay) metriğinin yerini aldı; FID yalnızca ilk etkileşimin gecikmesini ölçerken INP, sayfa ömrü boyunca tüm etkileşimleri değerlendirir. Eski kaynaklarda hâlâ FID'den bahsedildiğini görürseniz, bilgi güncel değildir.

Google sıralamasını gerçekten etkiliyor mu?

Google'ın Core Web Vitals belgesi bu konuda iki şeyi birlikte söylüyor:

• Core Web Vitals, sıralama sistemlerinin ödüllendirmek istediği sayfa deneyimi unsurlarıyla uyumludur ve Google site sahiplerinin bu metriklerde başarılı olmasını önerir.
• Ama iyi bir skor, üst sıralarda yer almayı tek başına garanti etmez.

Bunu şöyle okumak gerekir: Hız ve kararlılık, sıralamada belirleyici tek etken değildir; içerik alaka düzeyi ve otorite çok daha ağır basar. Ancak aynı düzeyde iki sayfa arasında, deneyimi kötü olan geride kalabilir. Daha önemlisi, yavaş bir sayfa ziyaretçiyi kaybettirir. Google ve Deloitte'un 37 marka ve 30 milyondan fazla kullanıcı oturumunu inceleyen “Milliseconds Make Millions” çalışması, mobil hızdaki 0,1 saniyelik iyileşmenin bile perakendede harcama tutarını yaklaşık %9,2, ürün sayfasından sepete geçişi yaklaşık %9,1 artırdığını bildiriyor. Bu tür sonuçlar sektöre ve siteye göre değişir; ama yön açıktır: hız, gelirle doğrudan ilişkilidir.

Saha verisi mi, laboratuvar verisi mi?

İki tür ölçüm vardır ve karıştırılması sık yapılan bir hatadır:

• Saha verisi (field data): Gerçek kullanıcıların gerçek cihaz ve ağ koşullarında yaşadığı deneyim. Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın üstündeki “gerçek kullanıcı deneyimi” bölümü bu veriyi gösterir. Yeterli trafik yoksa bu veri görünmeyebilir.
• Laboratuvar verisi (lab data): Lighthouse gibi araçların kontrollü ortamda yaptığı simülasyon. Sorun teşhisi için çok değerlidir, ama gerçek kullanıcıyı birebir yansıtmaz.

Google'ın belgesi de saha verisini gerçek koşulları, laboratuvar verisini sorun teşhisini görmek için önerir. Next.js belgeleri de aynı yaklaşımı benimser: Lighthouse'un simüle bir test olduğunu ve Core Web Vitals gibi saha verileriyle birlikte değerlendirilmesi gerektiğini söyler. Kısacası: skoru saha verisinden takip edin, nedeni laboratuvar verisinden bulun.

LCP nasıl iyileştirilir?

web.dev, LCP'nin adaylarını görsel (<img>, SVG içindeki <image>), video posteri, CSS ile yüklenen arka plan görseli ve blok düzeyindeki metin olarak sayar. LCP süresi dört parçadan oluşur; hangisinin uzun olduğunu bulmak çözümü belirler:

1. TTFB (ilk bayt süresi): Sunucunun ilk yanıtı ne kadar sürede verdiği.
2. Kaynak yükleme gecikmesi: Tarayıcının LCP görselini indirmeye başlaması ne kadar gecikti?
3. Kaynak yükleme süresi: Dosyanın indirilmesi ne kadar sürdü?
4. Öğe render gecikmesi: İndirme bittikten sonra ekrana çizilmesi ne kadar sürdü?

Yaygın çözümler:

• Hero görseli önceliklendirin. Ekranın üstündeki ana görsel tembel yüklenmemeli, erken indirilmeli. Next.js'in Image bileşeninde bunun için preload (Next.js 16'dan itibaren priority özelliğinin yerine geçti), loading="eager" veya fetchPriority="high" kullanılır. Resmî belge, çoğu durumda loading="eager" veya fetchPriority="high"'ı önerir; yalnızca tek ve kesin LCP görseliniz varsa preload mantıklıdır.
• Görseli küçültün ve modern formata çevirin. Gerekenden büyük dosya, en yaygın LCP sorunudur. sizes özelliğini doğru verin; verilmezse tarayıcı görselin tam ekran genişliğinde olacağını varsayıp gereğinden büyük dosya indirebilir.
• Sunucu yanıtını hızlandırın. Sayfaları önceden üretmek (statik üretim), önbellek ve CDN kullanmak TTFB'yi doğrudan düşürür.
• Render'ı engelleyen kaynakları azaltın. Gereksiz CSS/JS, LCP görselinin çizilmesini geciktirir.
• LCP öğesini JavaScript'e bağımlı yapmayın. Ana içerik ilk HTML'de yer alırsa tarayıcı beklemeden çizer.

INP nasıl iyileştirilir?

INP, sayfadaki tüm tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözler; kaydırma, üzerine gelme ve yakınlaştırma sayılmaz. Zayıf INP'nin tipik nedenleri: JavaScript'te uzun görevler, ana iş parçacığının bloklanması, karmaşık render işlemleri ve düzen değişiklikleri.

Pratik adımlar:

• Gönderilen JavaScript'i azaltın. Kullanılmayan kütüphaneleri çıkarın, ağır bileşenleri ve üçüncü taraf kütüphaneleri gerektiğinde yükleyin (tembel yükleme). Next.js'te sunucu bileşenleri rota bazında otomatik kod bölmesi sağlar.
• Uzun görevleri bölün. Ana iş parçacığını yüzlerce milisaniye meşgul eden işleri küçük parçalara ayırın; tarayıcı arada kullanıcı girdisine yanıt verebilsin.
• DOM'u küçük tutun. Binlerce elemanlı sayfalar her etkileşimde daha pahalı hesaplanır. Uzun listeleri sayfalayın veya sanallaştırın.
• Etkileşim sonrası ağır işi erteleyin. Tıklamadan sonra önce görsel geri bildirimi (durum değişimi) verin, ağır hesaplamayı ardından yapın.
• Üçüncü taraf betiklere dikkat edin. Sohbet widget'ları, etiket yöneticileri ve reklam betikleri ana iş parçacığını en çok yoranlardandır. Next.js'te Script bileşeninin strategy seçenekleriyle (varsayılan afterInteractive; kritik olmayanlar için lazyOnload) yükleme zamanını denetleyebilirsiniz.

CLS nasıl iyileştirilir?

CLS, sayfa ömrü boyunca beklenmedik yerleşim kaymalarının en büyük ardışık grubunu ölçer. Nedenleri:

• Boyutu tanımlanmamış görsel ve videolar,
• Sonradan sayfaya eklenen öğeler (çerez banner'ı, bildirim şeridi),
• Boyutu sonradan değişen reklam ve gömülü içerikler,
• Yedek fonttan web fontuna geçerken oluşan metin kayması,
• Asenkron yüklenen kaynaklar.

Çözümler:

• Görsel ve videolara genişlik/yükseklik ya da CSS aspect-ratio verin. Next.js Image bileşeni bunu boyut zorunluluğuyla sağlar.
• Sonradan yüklenecek bileşenler için yer ayırın (ör. banner için sabit yükseklik).
• Font kaymasını önleyin. Next.js'in next/font kütüphanesi fontları otomatik olarak kendi sunucunuzdan servis eder ve yerleşim kayması olmadan yükler.
• Animasyonlarda konumu değiştiren özellikler yerine CSS transform kullanın.

Next.js sitelerinde ölçüm ve izleme

Next.js, useReportWebVitals kancasıyla Core Web Vitals verilerini analitik aracınıza gönderebilmenizi sağlar. Kanca, fonksiyon referansı değişmediği sürece tekrarlı veri göndermez. Böylece kendi sitenizin gerçek kullanıcı verisini toplayabilir, PageSpeed Insights'a yeterli veri düşmeyen düşük trafikli sayfaları da izleyebilirsiniz.

Örnek (basitleştirilmiş):

'use client'
import { useReportWebVitals } from 'next/web-vitals'

const report = (metric) => {
  // Analitik servisinize gönderin
  console.log(metric.name, metric.value)
}

export function WebVitals() {
  useReportWebVitals(report)
  return null
}

Hangi araç ne için?

Öncelik sırası: nereden başlamalı?

1. Önce sorunun hangi metrikte olduğunu bulun. Search Console'daki rapor size “LCP sorunu: 2,5 sn'den uzun” gibi URL grupları verir.
2. Şablon bazlı düşünün. Aynı şablonu kullanan yüzlerce sayfa varsa (blog yazıları, ürün sayfaları), bir şablonu düzeltmek hepsini düzeltir.
3. En çok trafik alan ve en çok gelir getiren sayfaları önceliklendirin.
4. Her değişiklikten sonra ölçün. Saha verisi 28 günlük bir pencerede güncellendiği için etkiyi görmek zaman alır; bu arada lab testleriyle doğrulayın.
5. Performans bütçesi koyun. Yeni bir bileşen veya betik eklenirken boyut ve etkileşim maliyeti tartılsın; sonradan düzeltmek eklenirken önlemekten pahalıdır.

Sık yapılan 7 hata

1. Yalnızca Lighthouse skoruna bakıp saha verisini görmemek.
2. Hero görselini tembel yüklemek.
3. Görsele boyut vermeyip CLS'yi bozmak.
4. Sohbet, etiket ve analitik betiklerini kontrolsüz eklemek.
5. Mobil cihazlarda test etmemek (kullanıcıların büyük kısmı mobilde).
6. Tek bir “Performans skoru 100” hedefiyle gereksiz mühendislik yapmak; hedef, “iyi” eşiğini kararlı biçimde geçmektir.
7. Hız iyileştirmesini bir kez yapıp bir daha izlememek; yeni özellikler yavaşça performansı geri düşürür.

Aktaş Digital ne yapıyor?

Web projelerimizi baştan performans odaklı, Next.js ile geliştiriyoruz: statik üretim, görsel ve font optimizasyonu, üçüncü taraf betiklerin kontrollü yüklenmesi ve gerçek kullanıcı verisiyle izleme. Var olan bir e-ticaret veya kurumsal sitenin hızını ve dönüşümünü iyileştirmek için Performans ve Dönüşüm Optimizasyonu (CRO) hizmetimize göz atabilirsiniz. Teknik SEO tarafındaki ayrıntılar için Next.js ile teknik SEO rehberimizi, altyapı seçimi için WordPress mi Next.js mi karşılaştırmamızı okuyabilirsiniz. Sitenizin durumunu birlikte değerlendirmek için teklif formundan yazın.

Sık Sorulan Sorular

Core Web Vitals'ın “iyi” olması için üç metriğin de geçmesi gerekir mi?

Google bir sayfa grubunun “iyi” sayılması için üç metriğin de 75. yüzdelikte iyi eşiğinde olmasını bekler. Bir tanesi zayıfsa o sayfa grubu genel olarak “iyi” sayılmaz. Bu nedenle en zayıf metriğe odaklanmak en hızlı kazancı verir.

FID hâlâ ölçülüyor mu?

Hayır. INP, 2024'te FID'in yerini alarak kalıcı bir Core Web Vital hâline geldi. FID yalnızca ilk etkileşimi ölçüyordu; INP ise sayfa ömrü boyunca tüm etkileşimleri değerlendirir.

PageSpeed Insights'ta skorum düşük ama Search Console'da her şey “iyi”. Hangisine güvenmeliyim?

Search Console gerçek kullanıcı verisini gösterir ve sıralama bağlamında asıl referanstır. PageSpeed Insights'taki performans skoru laboratuvar simülasyonudur. Bu ikisi farklı çıkabilir; laboratuvar skorunu sorunu teşhis etmek için, saha verisini başarıyı ölçmek için kullanın.

Search Console'da Core Web Vitals verisi görünmüyor, ne yapmalıyım?

Düşük trafikli sitelerde Google'ın saha verisi olmayabilir. Bu durumda Lighthouse ile lab ölçümü yapın ve useReportWebVitals gibi bir yöntemle kendi gerçek kullanıcı verinizi toplamaya başlayın.

Hız iyileştirmesi ne kadar sürede sıralamaya yansır?

Kesin bir süre yok. Saha verisi zaman içinde güncellenir ve sıralama pek çok başka sinyale bağlıdır. Hızın kullanıcı davranışına (çıkış oranı, dönüşüm) etkisi ise sıralamadan çok daha hızlı görülür.

WordPress sitem için de geçerli mi?

Evet, metrikler platformdan bağımsızdır. Görsel optimizasyonu, önbellek, gereksiz eklentilerin kaldırılması ve üçüncü taraf betiklerin denetimi WordPress'te de temel iyileştirmelerdir.

Sonuç

Core Web Vitals'ta amaç mükemmel bir skor değil, gerçek kullanıcıların çoğunun hızlı, tepkisel ve kararlı bir deneyim yaşamasıdır. Saha verisiyle nerede sorun olduğunu bulun, laboratuvar araçlarıyla nedenini tespit edin, şablon bazında düzeltin ve düzenli izleyin. Bugün yapabileceğiniz ilk iş: Search Console'daki Core Web Vitals raporunu açıp hangi URL grubunun hangi metrikte zayıf olduğuna bakmak.