Core Web Vitals Nasıl Düzeltilir?

Core Web Vitals düzeltmek, üç farklı metriğe üç farklı teknikle müdahale etmek demektir. Bu üç teknik LCP (en büyük içerik boyaması) için erken kaynak keşfi, CLS (kümülatif düzen kayması) için boyut ayırma ve INP (etkileşimden sonraki boyama) için uzun görev bölmedir. Her teknik, çalışan kod örneğiyle ve tarayıcı desteğiyle birlikte verilir. TechnoRadical’ın kendi sitesinde ölçülen gerçek sonuçlar (mobilde LCP 1,20 saniye, CLS 0,00) düzeltmenin hedeflediği “iyi” durumun neye benzediğini gösterir. İyi Core Web Vitals sonucu yine de bir sıralama garantisi değildir; Google alakalı içeriği sayfa deneyiminin her zaman önünde tutar. Hangi metriğin önce ele alınacağı site tipine göre değişir ve düzeltmenin etkisi saatler değil haftalar içinde görülür.

Core Web Vitals hangi üç metrikten oluşur, iyi eşiği nedir

Core Web Vitals üç metrikten oluşur: LCP, INP ve CLS; Google her biri için ayrı bir “iyi” eşiği tanımlar. LCP (Largest Contentful Paint, en büyük içerik boyaması) sayfanın en büyük görsel öğesinin ekrana çizilme süresini ölçer. INP (Interaction to Next Paint, etkileşimden sonraki boyama) bir tıklama veya dokunmadan sonra ekranın tepki verme gecikmesini ölçer. CLS (Cumulative Layout Shift, kümülatif düzen kayması) sayfa yüklenirken içeriğin ne kadar kaydığını ölçer.

Üç eşik de web.dev’in resmi rehberlerinde, Eylül 2026 itibarıyla şu değerlerle tanımlanır.

Metrik	İyi	Geliştirilmeli	Zayıf
LCP	2,5 sn veya altı	2,5-4,0 sn	4,0 sn üstü
INP	200 ms veya altı	200-500 ms	500 ms üstü
CLS	0,1 veya altı	0,1-0,25	0,25 üstü

Bu eşikler, mobil ve masaüstü yüklemelerinin karıştığı “75. yüzdelik dilim” üzerinden değerlendirilir; yani bir sayfanın ziyaretçilerinin en az %75’i bu değeri veya daha iyisini yaşamalıdır. Bu üç eşiği zaten teknik SEO denetiminin hız katmanı ölçüp raporluyor; saha ve laboratuvar verisini ayırıp hangi sayfanın hangi bantta durduğunu gösteriyor, ama tespit edilen sorunu hangi kod satırının düzelteceğini söylemiyor.

TTFB (Time to First Byte, ilk bayta kadar geçen süre) bu üçlünün içinde değildir; sunucunun ilk baytı gönderme süresini ölçen tanı sinyali olarak kalır, LCP/CLS/INP’nin ölçtüğü görsel ve etkileşimsel deneyimin yerini tutmaz.

LCP (en büyük içerik boyaması) nasıl düşürülür

LCP’yi düşürmenin ilk adımı sayfanın LCP elemanını bulup o elemanın indirmesini erken başlatmaktır; en yaygın çözüm hero görselde fetchpriority="high" ve gerektiğinde rel="preload" kullanmaktır.

LCP elemanı, PageSpeed Insights veya Lighthouse raporunun tanı bölümünde doğrudan adıyla listelenir (“Largest Contentful Paint element”); genellikle sayfanın üstünde görünen hero görsel, büyük bir başlık metni veya video kapak karesidir. Eleman belirlendikten sonra tarayıcının bu kaynağı ne kadar geç keşfettiği önem kazanır.

Bir hero görselde erken keşif ve yüksek öncelik şöyle kurulur.

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" alt="Ürün görseli" fetchpriority="high" width="1200" height="630">

fetchpriority="high" tarayıcıya bu kaynağı diğer görsellerden önce indirmesini söyler; rel="preload" ise kaynağı HTML ayrıştırıcısı elemana ulaşmadan önce keşfettirir. web.dev’in fetchpriority rehberi, bu ikisinin birlikte kullanıldığında en büyük kazancı hero görsellerde verdiğini yazar.

CSS arka plan görselleri bu tekniğin dışında kalan bir tuzaktır. fetchpriority bir HTML niteliğidir ve CSS background-image üzerinde doğrudan çalışmaz; bir öğeye CSS’ten arka plan olarak verilen görsel, önce ayrı bir <link rel="preload"> etiketiyle keşfettirilip ardından fetchpriority="high" o preload etiketine eklenmelidir.

<link rel="preload" as="image" href="/hero-bg.webp" fetchpriority="high">

.hero {
  background-image: url("/hero-bg.webp");
}

Preload etiketi olmadan yalnızca CSS’e güvenmek, tarayıcının görseli CSS dosyası tamamen ayrıştırılana kadar keşfetmemesi anlamına gelir; bu gecikme LCP’yi doğrudan büyütür. Son bir kural: LCP elemanına loading="lazy" verilmez, çünkü lazy loading elemanın indirmesini tam olarak geciktirilmemesi gereken anda geciktirir.

CLS (kümülatif düzen kayması) nasıl önlenir

CLS’i önlemenin çekirdek kuralı, tarayıcının içerik gelmeden önce onun için yer ayırabilmesidir; görsel ve videolara boyut bilgisi vermek ve web fontlarını fallback fontla aynı ölçüye getirmek bu yer ayırmayı sağlar. web.dev’in CLS rehberi, boyut niteliği verilmeyen görsel ve videoların en yaygın kayma nedeni olduğunu, web fontu geçişlerinin ise ikinci sırada geldiğini yazar.

Bir görsel veya videoya width ve height nitelikleri verildiğinde tarayıcı, dosya henüz inmeden en boy oranını hesaplayıp yerini önceden ayırır.

<img src="/urun.webp" alt="Ürün görseli" width="800" height="600">

img, video {
  height: auto;
  max-width: 100%;
}

Genişlik yüksekliğin dışarıdan değişken olduğu durumlarda CSS aspect-ratio özelliği aynı işi görür.

.video-cerceve {
  aspect-ratio: 16 / 9;
}

Web fontu kayması farklı bir mekanizmadan kaynaklanır: tarayıcı önce sistem fontuyla (fallback) metni çizer, özel font indikten sonra metni değiştirir; iki fontun karakter genişliği farklıysa satırlar kayar. Çözüm, fallback fontun ölçülerini özel fonta size-adjust, ascent-override ve descent-override ile yaklaştırmaktır.

@font-face {
  font-family: "Ozel Fallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
}

body {
  font-family: "Ozel Font", "Ozel Fallback", sans-serif;
}

Alternatif bir çözüm font-display: optional kullanmaktır.

@font-face {
  font-family: "Ozel Font";
  src: url("/fonts/ozel-font.woff2") format("woff2");
  font-display: optional;
}

font-display: optional, tarayıcıya özel fontu yaklaşık 100 milisaniye içinde yükleyebilirse kullanmasını, yükleyemezse sayfanın geri kalanında fallback fontta kalmasını söyler; sonradan font değişip metni kaydırmaz. Bedeli, yavaş bağlantılarda özel fontun o oturumda hiç görünmemesidir.

INP (etkileşimden sonraki boyama) nasıl iyileştirilir

INP’yi iyileştirmenin çekirdek tekniği, ana iş parçacığını bloke eden uzun görevleri küçük parçalara bölmektir; “uzun görev” ana iş parçacığını 50 milisaniyeden uzun süre meşgul eden herhangi bir JavaScript çalıştırmasıdır.

Ana iş parçacığı bir uzun görevle meşgulken tarayıcı, kullanıcının tıklamasına veya dokunmasına tepki veremez; INP bu gecikmeyi ölçer. scheduler.yield(), tarayıcıya ana iş parçacığını görevler arasında serbest bırakmasını söyleyen yerleşik bir API’dir. Chrome’un geliştirici blogu, bu API’nin ana iş parçacığını görevler arasında serbest bıraktığını ve bunun INP’yi doğrudan iyileştirdiğini yazar.

async function buyukListeyiIsle(ogeler) {
  for (const oge of ogeler) {
    isleOgeyi(oge);
    await scheduler.yield();
  }
}

Her await scheduler.yield() çağrısı, döngü devam etmeden önce tarayıcıya kontrolü kısa süreliğine geri verir; bu sırada bekleyen bir tıklama varsa tarayıcı önce onu işler.

scheduler.yield(), 2026 ortası itibarıyla Chrome ve Edge’in 129. sürümünden, Firefox’un 142. sürümünden itibaren destekleniyor; Safari’de karşılığı yok. Desteklenmeyen tarayıcılarda aynı davranış setTimeout ile taklit edilir.

function anaIsParcasiniSerbestBirak() {
  if (typeof scheduler !== "undefined" && "yield" in scheduler) {
    return scheduler.yield();
  }
  return new Promise((cozum) => setTimeout(cozum, 0));
}

Üçüncü taraf betikler (canlı sohbet widget’ı, reklam yükleyici, analiz aracı) genellikle bu uzun görevlerin en büyük kaynağıdır, çünkü sitenin kendi kod tabanının dışında çalışırlar ve ne zaman ağır iş yapacakları kontrol edilemez. web.dev’in uzun görevleri optimize etme rehberi, üçüncü taraf kodun ana iş parçacığını meşgul eden en yaygın kaynaklardan biri olduğunu belirtir; pratik önlem bu betikleri defer veya async ile yüklemek, mümkünse kullanıcı etkileşiminden sonra devreye almaktır.

LCP, CLS ve INP’den hangisi önce düzeltilir

Üç metrik arasında önce hangisinin ele alınacağı bir Google kuralına değil, düzeltme maliyetine ve yaygın hata örüntüsüne dayanan bir gözleme dayanır; bu bir çıkarımdır, kaynaklı bir olgu değildir. Genel eğilim CLS’in en ucuz, INP’nin en pahalı düzeltme olduğu yönündedir.

Metrik	Yaygın neden	Düzeltme maliyeti (gözlem)	Hangi site tipinde daha kritik (çıkarım)
CLS	Boyutsuz görsel/video, web fontu kayması	Düşük: CSS ve markup düzeltmesi, kod mimarisi değişmez	Görsel yoğun e-ticaret ürün sayfaları
LCP	Optimize edilmemiş hero görsel, geç keşfedilen kaynak	Orta: görsel format ve preload değişikliği, bazen sunucu yanıt süresiyle birlikte ele alınır	İçerik ve blog siteleri, görsel ağırlıklı açılış sayfaları
INP	Ana iş parçacığını bloke eden uzun JavaScript görevleri, üçüncü taraf betikler	Yüksek: kod mimarisi ve üçüncü taraf betik yönetimi değişir	Sepet, filtre ve form gibi etkileşim yoğun işlemsel siteler

Pratikte karar kuralı basittir: CLS bulgusu varsa önce onu kapatın, çünkü düzeltmesi ucuzdur ve yan etkisi yoktur; ardından LCP’yi hedef görsel üzerinden ele alın; INP’yi yalnızca kullanıcı gerçekten sepet, filtre veya form gibi etkileşimli bir akışta gecikme yaşıyorsa önceliklendirin.

Saha verisi mi laboratuvar verisi mi ölçülmeli

Düzeltme öncesi ve sonrası hız hemen laboratuvar verisiyle (Lighthouse) ölçülür; saha verisi (CrUX, Chrome User Experience Report) yalnızca yeterli ziyaretçi trafiği olan sitelerde birkaç hafta içinde birikir, bu yüzden küçük bir sitede laboratuvar ölçümü tek erişilebilir referans olabilir.

Saha verisi, siteyi son 28 günde ziyaret eden gerçek Chrome kullanıcılarının deneyiminden gelir ve Search Console’daki Core Web Vitals raporunda kullanılan veridir. Laboratuvar verisi tek bir sanal cihazda yapılan tek seferlik bir ölçümdür; yol gösterir ama gerçek kullanıcı davranışını temsil etmez ve sıralamada doğrudan kullanılmaz.

TechnoRadical’ın kendi sitesinde 19 Eylül 2026’da ölçülen sonuçlar bu ikisi arasındaki farkı somutlaştırır, ama bir düzeltme örneği değildir. Ana sayfa mobilde laboratuvar ölçümünde LCP 1,20 saniye, CLS 0,00 ve toplam engelleme süresi 0 milisaniye ile “iyi” bandın tamamında çıktı, laboratuvar performans skoru 100/100 oldu; yayındaki bir blog yazısı aynı koşullarda LCP 1,65 saniye ve CLS 0,00 ile yine “iyi” bantta, skoru 98/100 oldu. İki sayfada da saha verisi oluşmadı; PageSpeed Insights API’sinin bildirdiği neden düşük performans değil, ziyaretçi sayısının Google’ın anonimlik eşiğinin altında kalmasıydı. Bu ölçüm bir önce/sonra düzeltme vakası değildir, çünkü PageSpeed’in “fırsatlar” listesi boş döndü; gösterdiği şey, düzeltme sonrasında hedeflenen “iyi” durumun neye benzediğidir. Aynı ölçümü kendi sitenizde tekrarlamak için PageSpeed Insights API’sini elle çağırmaya gerek yok; kendi sitenizin saha ve laboratuvar hız verisi aracı ikisini ayırıp aynı formatta gösteriyor, düzeltmeden önce ve düzeltmeden birkaç hafta sonra tekrar çalıştırıldığında saha verisinin oluşup oluşmadığını da ortaya koyuyor.

Core Web Vitals düzeltmek ne zaman öncelik değildir

İyi Core Web Vitals sonucu sıralamayı garanti etmez; Google alakalı ve kaliteli içeriği sayfa deneyiminin her zaman önünde tutar, bu yüzden zaten “iyi” banttaki bir sitede ek hız optimizasyonuna zaman ayırmak düşük getirili bir çalışmadır.

Google Search Central’ın sayfa deneyimi rehberi bunu doğrudan yazar: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” Aynı rehber, Search Console’un Core Web Vitals raporunda veya üçüncü taraf araçlarda alınan iyi sonuçların, sayfaların Google aramasında üst sıralarda çıkacağını garanti etmediğini de ekler. Sinyal tekil değildir; Google’ın çekirdek sıralama sistemleri sayfa deneyimiyle uyumlu, sayısı açıklanmayan bir dizi sinyale birlikte bakar.

TechnoRadical’ın kendi sitesi bu sınırı doğrudan yaşıyor: ana sayfa ve ölçülen blog sayfası zaten LCP, CLS ve toplam engelleme süresinde “iyi” bantta, laboratuvar skorları 100 ve 98. Bu durumda kalan hız optimizasyonuna daha fazla zaman ayırmanın marjinal getirisi düşüktür; kazanılacak saniyeler sıralamayı değil, yalnızca kullanıcı deneyimini biraz daha iyileştirir. Google’ın kendi ayrımı, sayfa deneyiminin yalnızca benzer kalitede içerikler yarışırken belirleyici hale geldiğini de ekliyor; yani hız zaten iyiyken önceliği içerik kalitesine veya alakaya kaydırmak daha yüksek getiri sağlar.

Düzeltmenin etkisi de anında görünmez. Google Search Central’ın SEO Starter Guide’ı, yapılan değişikliklerin etkisinin birkaç saatten birkaç aya kadar sürebileceğini ve sonucu değerlendirmek için birkaç hafta beklenmesi gerektiğini yazar. Bir hız düzeltmesinden hemen ertesi gün sıralama değişikliği beklemek, bu zaman çizelgesini görmezden gelmektir.

TTFB Core Web Vitals’ın bir parçası mı?

Hayır, TTFB (Time to First Byte, ilk bayta kadar geçen süre) resmi Core Web Vitals üçlüsüne dahil değildir; LCP, INP ve CLS’in tanı amaçlı destekleyicisidir. Türkçe kaynaklardan bazıları TTFB’yi dördüncü bir Core Web Vitals gibi sayar; web.dev’in resmi eşik sayfaları bu ayrımı yapmaz ve yalnız üç metriği sayar.

Core Web Vitals raporu Search Console’da neden veri yok gösteriyor?

Veri yok görünmesinin nedeni genellikle düşük performans değil, sitenin ziyaretçi trafiğinin Google’ın saha verisi oluşturmak için gereken anonimlik eşiğinin altında kalmasıdır. TechnoRadical’ın kendi ölçümünde de aynı durum çıktı: iki sayfa da laboratuvar verisinde “iyi” bantta olmasına rağmen saha verisi hiç oluşmadı, çünkü API bunun nedenini düşük trafik olarak bildirdi.

Core Web Vitals düzelttikten sonra sıralama ne kadar sürede değişir?

Google, yapılan değişikliklerin etkisinin birkaç saatten birkaç aya kadar sürebileceğini yazar ve etkiyi değerlendirmek için birkaç hafta beklenmesini önerir. Bu süre belirli bir düzeltme türüne (örneğin yalnızca bir CSS değişikliğine) özel bir taahhüt değildir; Google kasıtlı olarak geniş bir aralık verir.