Google, 2021 yılından itibaren sayfa deneyimini sıralama sinyali olarak resmi şekilde kullanıyor. Bu deneyimin teknik karşılığı Core Web Vitals: üç spesifik performans metriği. Sadece teknik bir kontrol listesi değil; kullanıcıların sayfanızı nasıl hissettiğinin sayısal yansıması.

Bu rehber, Core Web Vitals’ın ne olduğunu, nasıl ölçüldüğünü, hangi eşik değerlerinin hedeflenmesi gerektiğini ve her metrik için hangi optimizasyon tekniklerinin işe yaradığını baştan sona ele alıyor. Geliştirici, SEO uzmanı ya da dijital pazarlamacı olun; buradaki bilgileri doğrudan uygulayabilirsiniz.

Teknik SEO hizmetleri kapsamında bu metrikleri nasıl değerlendirdiğimize de göz atmak isteyebilirsiniz: Teknik SEO Hizmeti.

Core Web Vitals Nedir?

Core Web Vitals, Google’ın kullanıcı deneyimini ölçmek amacıyla tanımladığı üç temel metriğin ortak adıdır. Bu metrikler sayfanın:

Ne kadar hızlı yüklendiğini (LCP — Largest Contentful Paint)
Görsel olarak ne kadar kararlı göründüğünü (CLS — Cumulative Layout Shift)
Kullanıcı etkileşimlerine ne kadar duyarlı olduğunu (INP — Interaction to Next Paint)

ölçer.

Google, bu üç metriği “çekirdek” metrik olarak adlandırıyor çünkü diğer pek çok performans sinyalinin aksine bunlar gerçek kullanıcı deneyimiyle doğrudan ilişkilidir. Bir sayfanın 90 puanlık Lighthouse skoru olabilir; ama gerçek kullanıcıların deneyimlediği yavaş bir LCP varsa bu çelişki Google tarafından görülür.

Web Vitals Ailesi: Core ve Diğerleri

Google, Core Web Vitals dışında “Web Vitals” çatısı altında ek metrikler de tanımlamaktadır. Bunlar arasında TTFB (Time to First Byte), FCP (First Contentful Paint) ve INP’in öncülü olan FID (First Input Delay) yer alır. Ancak Google Arama sıralamasında doğrudan sinyal olarak kullanılan yalnızca üç çekirdek metriktir: LCP, CLS ve INP.

Mart 2024’te FID resmen emekliye ayrılmış ve yerini INP almıştır. Bu değişiklik, etkileşim ölçümünü daha gerçekçi ve kapsamlı hale getirmiştir.

Core Web Vitals ve Google Sıralaması

Google, Core Web Vitals’ı 2021 Haziran güncellemesiyle (Page Experience Update) resmi sıralama sinyaline dönüştürdü. Ancak bu metrikler bir “tiebreaker” niteliğinde: içerik kalitesi her zaman önce gelir.

Yine de pratikte bu sinyalin görmezden gelinmesi büyük bir hata olur. Rekabetçi anahtar kelimelerde benzer içerik kalitesine sahip iki sayfa arasında Core Web Vitals puanları belirleyici olabilmektedir.

Google’ın Search Console raporları ve CrUX (Chrome User Experience Report) veritabanı bu metrikleri alan adı bazında toplar. Yani sıralama etkisi yalnızca tek bir sayfa değil, tüm alan adı genelindeki ortalama deneyimi yansıtır.

Sıralama Etkisi Ne Kadar Büyük?

Google bu konuda resmi bir yüzde açıklamamıştır. Bağımsız araştırmalar şunu söylüyor:

Semrush ve Backlinko’nun 2022 analizine göre Core Web Vitals puanı “İyi” olan sayfalar, “Geliştirilmeli” veya “Kötü” kategorisindekilerden ortalama %6-12 daha iyi sıralanıyor.
Moz’un 2023 araştırması da teknik performansın özellikle mobilde sıralama korelasyonu gösterdiğini ortaya koyuyor.
Veriler sıralama faktörünü kesinleştirmese de ziyaretçi davranışı (hemen çıkma oranı, oturum süresi) üzerindeki etkisi ölçülebilir şekilde pozitif.

Üç Metriğe Genel Bakış

LCP — En Büyük İçeriksel Boyama

LCP, sayfanın görünür alanındaki en büyük içerik öğesinin — genellikle bir görsel, başlık metni ya da video küçük resmi — ekranda tam olarak görünmesi için geçen süredir.

Kullanıcının bakış açısından: “Sayfa ne zaman ‘hazır’ göründü?”

Daha ayrıntılı bilgi için: LCP Nedir? Tam Rehber

CLS — Kümülatif Düzen Kayması

CLS, sayfa yüklenirken beklenmedik öğelerin kayma miktarını ölçen bir kararlılık skorudur. Bir reklam aniden yerleştiğinde ve metnin yerini ittiğinde ya da görsel geç yüklenip düzeni bozduğunda CLS artar.

Kullanıcının bakış açısından: “Tıklamaya çalıştığımda bir şey yerinden oynadı mı?”

Daha ayrıntılı bilgi için: CLS Nedir? Tam Rehber

INP — Sonraki Boyamaya Etkileşim

INP, kullanıcının sayfayla yaptığı tüm etkileşimlerin (tıklama, dokunma, klavye girişi) tepki sürelerini izler ve kötü uç değerleri esas alarak bir genel puan üretir. Mart 2024’ten itibaren FID’in yerini almıştır.

Kullanıcının bakış açısından: “Bir şeye tıkladığımda sayfa ne kadar hızlı tepki verdi?”

Daha ayrıntılı bilgi için: INP Nedir? Tam Rehber

Eşik Değerleri: İyi, Geliştirilmeli, Kötü

Google her metrik için üç kategori tanımlamaktadır. Hedef, sayfalarınızın 75. yüzdelik dilimde “İyi” kategorisinde yer almasıdır. Yani ziyaretçilerinizin en az %75’i “İyi” deneyim yaşamalıdır.

LCP Eşik Değerleri

Kategori	Eşik Değeri
İyi	<= 2,5 saniye
Geliştirilmeli	2,5 – 4,0 saniye arası
Kötü	> 4,0 saniye

CLS Eşik Değerleri

Kategori	Eşik Değeri
İyi	<= 0,1
Geliştirilmeli	0,1 – 0,25 arası
Kötü	> 0,25

INP Eşik Değerleri

Kategori	Eşik Değeri
İyi	<= 200 milisaniye
Geliştirilmeli	200 – 500 ms arası
Kötü	> 500 milisaniye

Tüm Metriklerin Özet Tablosu

Metrik	İyi	Geliştirilmeli	Kötü	Ölçüm Birimi
LCP	<= 2,5 sn	2,5 – 4,0 sn	> 4,0 sn	Saniye
CLS	<= 0,1	0,1 – 0,25	> 0,25	Puan (birimsiz)
INP	<= 200 ms	200 – 500 ms	> 500 ms	Milisaniye

Ölçüm Araçları: Hangisini Ne Zaman Kullanmalısınız?

Core Web Vitals’ı ölçmek için birden fazla araç mevcuttur. Her birinin farklı avantajları ve kullanım senaryoları vardır. Bu araçlar iki ana kategoriye ayrılır: lab verisi üreten araçlar ve field verisi (gerçek kullanıcı verisi) üreten araçlar.

Lab Verisi vs Field Verisi

Bu ayrımı anlamak, skoru doğru yorumlamak için kritiktir.

Lab Verisi (Sentetik/Simülasyon): Lighthouse ya da WebPageTest gibi araçlar, sayfanızı kontrollü bir ortamda — sabit bir ağ bağlantısı, sabit bir cihaz profili — yükler ve ölçer. Sonuç tekrarlanabilirdir; aynı sayfayı aynı koşullarda ölçerseniz benzer sonuçlar alırsınız. Hata ayıklama ve geliştirme sürecinde son derece kullanışlıdır.

Field Verisi (Gerçek Kullanıcı / RUM): CrUX, PageSpeed Insights’ın “Alan Verileri” bölümü ve Google Search Console; gerçek kullanıcıların Chrome tarayıcısından toplanan anonim performans verilerini kullanır. Bağlantı hızı, cihaz tipi ve coğrafya gibi değişkenler gerçek hayatı yansıtır. Google’ın sıralama kararları için esas aldığı veri budur.

Özellik	Lab Verisi	Field Verisi
Kaynak	Simülasyon	Gerçek kullanıcılar
Tekrarlanabilirlik	Yüksek	Değişken
Hata ayıklamak	Kolay	Zor
Google sıralama etkisi	Dolaylı	Doğrudan
Veri gecikmesi	Anında	28 günlük pencere
Veri yoksa	Her zaman sonuç verir	Yetersiz trafik = veri yok

Önemli not: Lab verisinde “İyi” olan bir sayfa, field verisinde “Kötü” görünebilir. Örneğin yavaş 3G bağlantısı kullanan mobil kullanıcılar LCP’nizi ciddi şekilde uzatır; oysa Lighthouse masaüstü simülasyonunda bu görünmez.

PageSpeed Insights (PSI)

URL: pagespeed.web.dev

PageSpeed Insights, hem lab hem de field verisini aynı arayüzde sunan en pratik başlangıç noktasıdır.

Field verisi (Alan Verileri) bölümü: CrUX’tan çekilen gerçek kullanıcı deneyimlerini gösterir. Son 28 günün 75. yüzdelik dilimini yansıtır. Google’ın arama sıralamalarını doğrudan etkileyen veri budur.

Lab verisi (Teşhis) bölümü: Lighthouse motoru çalıştırır. Sorunları tespit etmek, “Bu sorun neden oluşuyor?” sorusunu yanıtlamak için kullanılır.

Kullanım senaryosu: Yeni bir sayfayı yayınladınız veya bir optimizasyon uyguladınız. PSI’yi açın, URL’yi girin ve hem anlık lab sonucunu hem de mevcut field verisini kontrol edin. Field verisi 28 günlük pencereyle güncellenir; bu nedenle yeni bir değişikliğin field verisine yansıması birkaç hafta sürer.

Pratik ipucu: PSI’nin mobil ve masaüstü sekmeleri arasında geçiş yapmayı unutmayın. Google mobil deneyimi önceliklendirdiğinden mobil skorlar daha kritiktir.

CrUX — Chrome User Experience Report

CrUX, Google’ın Chrome tarayıcısından topladığı gerçek kullanıcı performans veritabanıdır. Bu veri:

PSI’nin “Alan Verileri” bölümünde görünür
Google Search Console’un “Temel Web Verileri” raporunu besler
BigQuery aracılığıyla ham veriyle analiz yapılmasına olanak tanır
CrUX API üzerinden programatik erişime açıktır

CrUX’un sınırlılıkları:

Yalnızca Chrome kullanıcıları kapsanır (Firefox, Safari dahil değildir)
“Yeterli veri” eşiği bulunur; az trafik alan sayfalar için veri olmayabilir
Alan adı düzeyi ve URL düzeyi olmak üzere iki granülerlikte veri mevcuttur

BigQuery ile CrUX analizi: Teknik ekipler için BigQuery üzerinden aylık ve ülke bazlı CrUX verisi çekilebilir. chrome-ux-report.country_tr tablosu Türkiye’den gelen kullanıcıların verilerini içerir.

Google Lighthouse

Lighthouse, Google’ın açık kaynak otomatik denetim aracıdır. Chrome DevTools’a entegre edilmiştir; aynı zamanda CLI üzerinden ve GitHub Actions gibi CI/CD sistemlerine entegre şekilde çalıştırılabilir.

Lighthouse performans skoru nedir? Lighthouse, bir sayfayı analiz ederek 0-100 arasında tek bir performans skoru üretir. Bu skor birden fazla metriğin ağırlıklı ortalamasıdır:

Metrik	Ağırlık
LCP	%25
TBT (Total Blocking Time)	%30
CLS	%25
FCP	%10
Speed Index	%10

INP, Lighthouse’un şu anki sürümünde doğrudan ağırlıklı skorun parçası değildir; ancak ayrı bir metrik olarak raporlanmaktadır. INP ölçümü gerçek kullanıcı etkileşimi gerektirdiğinden Lighthouse gibi sentetik araçlarda simüle edilmesi güçtür.

Lighthouse CLI kullanımı:

npx lighthouse https://example.com --output=html --output-path=./report.html

CI/CD entegrasyonu: Lighthouse CI (LHCI) ile her deploy öncesinde performans eşiği kontrolü yapılabilir. Örneğin LCP’nin 2,5 saniyeyi geçmesi durumunda deploy’u otomatik olarak başarısız sayabilirsiniz.

Web Vitals JavaScript Kütüphanesi

Google’ın resmi web-vitals npm paketi, tarayıcıda çalışan ve gerçek kullanıcıların LCP, CLS, INP, FCP ve TTFB değerlerini toplayan hafif bir JavaScript kütüphanesidir.

Kurulum:

npm install web-vitals

Temel kullanım:

import { onLCP, onCLS, onINP } from 'web-vitals';

onLCP(console.log);
onCLS(console.log);
onINP(console.log);

Toplanan verileri Google Analytics 4, bir izleme API’si ya da kendi analytics altyapınıza gönderebilirsiniz.

Neden kullanmalısınız? CrUX yalnızca Chrome kullanıcılarını kapsar ve 28 günlük gecikme içerir. web-vitals kütüphanesiyle kendi RUM (Real User Monitoring) altyapınızı kurabilir; Firefox ve Safari dahil tüm tarayıcılardaki kullanıcı deneyimini gerçek zamanlı olarak izleyebilirsiniz.

Google Search Console — Temel Web Verileri Raporu

Google Search Console’un “Temel Web Verileri” (Core Web Vitals) raporu, sitenizin tüm URL’lerini performans kategorilerine göre gruplandırır.

Raporun özellikleri:

URL’leri “İyi”, “Geliştirilmeli” ve “Kötü” olarak sınıflandırır
Sorunlu URL’leri benzer sorun tiplerine göre gruplar
”URL’ler üzerinde doğrulama” özelliğiyle bir sorunu giderip onaylamanıza olanak tanır
Mobil ve masaüstü için ayrı ayrı raporlar sunar

Nasıl yorumlanmalı? GSC raporunda bir URL grubunun “Kötü” olarak işaretlenmesi, söz konusu URL’lerde gerçek kullanıcıların kötü deneyim yaşadığı anlamına gelir. Bu, doğrudan sıralama riski taşır.

Sık yapılan hata: Lighthouse’da 90+ alan bir sayfa, GSC’de “Kötü” görünebilir. Bunun nedeni gerçek kullanıcıların yavaş bağlantı ya da eski cihazlarla sayfayı farklı deneyimlemesidir. GSC’deki “Kötü” etiketini her zaman ciddiye alın.

Chrome DevTools — Performans Paneli

Chrome DevTools’un Performance paneli, Core Web Vitals sorunlarını hata ayıklama düzeyinde incelemek için vazgeçilmezdir.

LCP için Performance paneli: “Timings” bölümünde LCP olayını görebilir, hangi öğenin LCP kaynağı olduğunu ve bu öğenin yüklenme sürecini adım adım inceleyebilirsiniz.

INP için Performance paneli: “Interactions” bölümü, her etkileşimi, tetiklenen JavaScript işlemlerini ve browser’ın paint döngüsünü zaman ekseninde gösterir. Uzun görevler (Long Tasks, > 50ms) sarı çizgilerle işaretlenir; bunlar INP süresini uzatan başlıca nedenlerdir.

CLS için Layout Shift Regions: Chrome DevTools’da Layout Instability API kullanılarak hangi öğelerin kayma yaptığı kırmızı dikdörtgenlerle işaretlenebilir. Bu özellik için Performance panelinde “Layout Shifts” onay kutusunun işaretli olduğundan emin olun.

LCP Optimizasyonu: Teknikler ve Öncelikler

LCP genellikle üç temel sorun kaynağından kaynaklanır: yavaş sunucu yanıt süresi, engellenen render zinciri ve büyük / geç yüklenen kaynaklar.

LCP Öğesini Tanımlayın

İlk adım LCP öğesini doğru tespit etmektir. PSI raporunun “Teşhis” bölümü ya da Chrome DevTools bu öğeyi gösterir. Çoğu durumda LCP öğesi:

Hero görsel (büyük üst bölüm fotoğrafı)
H1 başlık metni (görsel yoksa)
Video kapak görseli
CSS background-image ile tanımlanmış büyük görsel

olur.

Sunucu Yanıt Süresini Kısaltın (TTFB)

LCP başlamadan önce sunucunun ilk baytı göndermesi gerekir. TTFB > 800ms ise LCP için iyi bir eşik değere ulaşmak güçleşir.

Çözüm yöntemleri:

CDN kullanımı (içeriği coğrafi olarak kullanıcıya yakınlaştırma)
Sunucu tarafı önbellekleme (Redis, Varnish, page cache eklentileri)
Veritabanı sorgu optimizasyonu
HTTP/2 veya HTTP/3 protokolüne geçiş

LCP Görselini Önceden Yükleyin

LCP kaynağı bir görselsse ve bu görsel CSS ya da JavaScript tarafından geç keşfediliyorsa, tarayıcı onu zamanında yükleyemez.

Çözüm: <link rel="preload"> etiketi.

&lt;link rel="preload" as="image" href="/hero.webp" fetchpriority="high"&gt;

fetchpriority="high" özelliği, tarayıcıya bu kaynağın diğerlerinden önce yüklenmesi gerektiğini söyler. Yanlış kullanılan preload etiketi bant genişliğini tüketebileceğinden yalnızca gerçek LCP öğesi için kullanın.

Görselleri Optimize Edin

Teknik	Açıklama
WebP / AVIF formatı	JPEG’e kıyasla %25-50 daha küçük boyut
Boyut belirtin	`width` ve `height` özelliği CLS’i de önler
Responsive image	`srcset` ile cihaza uygun boyut sunun
Sıkıştırma	Squoosh, Sharp veya Cloudinary ile
loading=“eager”	LCP öğesinde `loading="lazy"` kullanmayın

Render-Blocking Kaynakları Kaldırın

CSS ve senkron JavaScript, tarayıcının sayfayı boyamasını engeller. Başlıkta yer alan büyük bir CSS dosyası LCP’yi doğrudan geciktirebilir.

Çözümler:

Kritik CSS’i satır içi (inline) hale getirin
Kullanılmayan CSS’i kaldırın (PurgeCSS)
Üçüncü taraf script’leri defer veya async ile yükleyin
Google Fonts gibi harici font kaynaklarını self-host edin

Font Yüklemesini Optimize Edin

LCP öğesi metin ise web fontunun geç yüklenmesi LCP’yi geciktirir. Çözüm:

&lt;link rel="preconnect" href="https://fonts.gstatic.com" crossorigin&gt;
&lt;link rel="preload" as="font" href="/fonts/inter-v13-latin-regular.woff2" type="font/woff2" crossorigin&gt;

Font CSS’inde font-display: swap kullanarak sistemin yedek fontunu göstermesine ve asıl font yüklendiğinde değiştirmesine izin verin.

CLS Optimizasyonu: Düzen Kararlılığı Teknikleri

CLS sorunlarının büyük çoğunluğu birkaç yaygın nedenden kaynaklanır: boyutu belirtilmemiş medya, geç yüklenen reklamlar ve dinamik olarak eklenen içerik.

Görsel ve Video Boyutlarını Daima Belirtin

Tarayıcı bir görselin boyutunu önceden bilmezse, görsel yüklenene kadar sıfır piksel alan ayırır. Görsel geldiğinde sayfa kayar.

Hatalı kullanım:

&lt;img src="foto.jpg" alt="Açıklama"&gt;

Doğru kullanım:

&lt;img src="foto.jpg" alt="Açıklama" width="800" height="450"&gt;

Modern tarayıcılar width ve height özelliklerini okuyarak görsel yüklenmeden önce doğru alanı rezerve eder.

CSS aspect-ratio alternatifi:

img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Reklam Alanlarını Önceden Rezerve Edin

Reklamlar, içerik yüklendikten sonra eklenen ve CLS’i en fazla artıran öğelerdir.

Çözüm: Reklam alanı için minimum boyutta bir placeholder kutusu tanımlayın.

.reklam-alani {
  min-height: 250px;
  min-width: 300px;
}

Bu placeholder, reklam script’i yüklenene kadar alanı rezerve eder ve düzenin kaymasını önler.

Geç Yüklenen İçerik ve Banner’lar

Üstte beliren “Çerez kabul” veya “Uygulamamızı indirin” banner’ları CLS puanını ciddi şekilde artırabilir. Önerilen yaklaşımlar:

Banner’ı sayfanın en altına (fixed bottom) konumlandırın
Üstten gelen banner’lar için içeriği aşağı itmek yerine position: fixed kullanın
Banner’ın boyutunu baştan belirleyin ve bu alanı layout içinde rezerve edin

Animasyon ve Geçiş Efektleri

CSS transform ve opacity özelliklerini kullanan animasyonlar CLS oluşturmaz; ancak top, left, margin, padding gibi layout özelliklerini değiştiren animasyonlar CLS’e neden olabilir.

CLS oluşturmayan animasyon:

.element {
  transition: transform 0.3s ease;
}
.element:hover {
  transform: translateY(-4px);
}

INP Optimizasyonu: Etkileşim Yanıt Süresi

INP, Core Web Vitals ailesiyle gelen en yeni ve birçok site için en zorlayıcı metriktir. FID yalnızca ilk etkileşimi ölçerken INP, sayfadaki tüm etkileşimlerin yanıt süresini izler ve kötü uçtaki deneyimi puanlar.

INP Nasıl Hesaplanır?

Bir etkileşim şu üç aşamadan oluşur:

Input Delay: Kullanıcı tıkladı, ancak browser hazır değildi (başka bir görev çalışıyordu). Gecikme süresi.
Processing Time: Olay işleyicileri (event handler) çalıştı. JavaScript işleme süresi.
Presentation Delay: Tarayıcı DOM değişikliğini hesaplayıp ekrana boyamak için harcadığı süre.

INP = Input Delay + Processing Time + Presentation Delay

Uzun Görevleri (Long Tasks) Parçalayın

Ana thread’i 50ms’den uzun süre meşgul eden JavaScript görevleri hem INP Input Delay’ini hem de Processing Time’ı artırır.

Çözüm — scheduler.yield() veya setTimeout() ile görev bölme:

async function uzunGorev() {
  // İlk 1000 öğeyi işle
  for (let i = 0; i < 1000; i++) {
    islem(i);
    // Her 100 öğede bir ana thread'e söz ver
    if (i % 100 === 0) {
      await scheduler.yield();
    }
  }
}

Olay İşleyicilerini Optimize Edin

Bir butona tıklandığında tetiklenen olay işleyicisi ağır hesaplama yapıyorsa INP artar. İpuçları:

Ağır işlemleri Web Worker’a taşıyın
Hesaplamayı olay dışına çıkarın ve sonucu önbelleğe alın
Gereksiz DOM sorgularını (querySelectorAll, offsetTop gibi) olay işleyicisi içinde yapmaktan kaçının

isInputPending() ile Öncelikli İşleme

Tarayıcının deneysel navigator.scheduling.isInputPending() API’si, uzun bir döngü sırasında kullanıcı girişi bekleniyor mu diye kontrol etmeye yarar.

while (gorevler.length > 0) {
  if (navigator.scheduling.isInputPending()) {
    setTimeout(devamEt, 0);
    break;
  }
  gorevler.shift()();
}

Üçüncü Taraf Script’lerini Denetleyin

Analitik, chat widget’ı, A/B test araçları ve reklam script’leri ana thread’i meşgul ederek INP’i olumsuz etkiler.

Denetim adımları:

Chrome DevTools Performance panelini açın
Bir tıklama etkileşimini kaydedin
”Bottom-Up” görünümünde hangi script’in en fazla süre harcadığını bulun
Üçüncü taraf script’leri defer veya Web Worker’a taşıyın ya da gerekli olmayanları kaldırın

Lab ve Field Verisi Arasındaki Farkı Yönetmek

Neden Lab ve Field Verisi Uyuşmayabilir?

Bu durum son derece yaygındır. Temel nedenler:

Cihaz farkı: Lighthouse varsayılan olarak Moto G Power profilini simüle eder (4x CPU yavaşlama). Gerçek kullanıcılarınızın büyük kısmı daha hızlı cihaz kullanıyorsa field verisi lab verisinden iyi görünür; tersi de doğrudur.

Ağ farkı: Lighthouse, 3G yavaş bağlantısını simüle eder. Şehirde 5G kullanan kullanıcılarınız varsa field verisi daha iyidir. Ancak kırsal kullanıcılar veya 3G bağlantılı ziyaretçiler fazlaysa field verisi daha kötü çıkabilir.

Önbellek durumu: Lighthouse genellikle cold cache (boş önbellek) ile test eder. Dönen kullanıcıların önbellekli kaynakları kullandığı düşünülürse, field verisi daha hızlı çıkabilir.

JavaScript etkileşimi: INP gerçek tıklama gerektirdiğinden Lighthouse bu metriği simüle edemez; yalnızca TBT (Total Blocking Time) üzerinden tahmin eder.

Pratik Strateji: İki Veriyi Birlikte Kullanın

En etkili yaklaşım şudur:

GSC ve PSI field verisiyle hangi sayfaların sorunlu olduğunu tespit edin.
Lighthouse ve DevTools lab verisiyle sorunun kaynağını hata ayıklayın ve çözüm geliştirin.
Çözümü canlıya alın ve 28 günlük CrUX güncellemesini bekleyin.
GSC raporunda değişikliği onaylayın.

A/B Test ve Skor Takibi

Core Web Vitals İyileştirmesini A/B Test ile Doğrulayın

Bir optimizasyonun gerçekten işe yaradığını anlamanın tek yolu kontrollü deney yapmaktır. Performans iyileştirmelerini test etmek için şu yaklaşımı kullanabilirsiniz:

Yöntem 1: Trafik bölme (Split URL test) Aynı içeriği iki farklı URL üzerinden sunun. URL A mevcut versiyonu, URL B optimize edilmiş versiyonu göstersin. Trafiği eşit bölerek web-vitals kütüphanesiyle her iki gruptan gerçek kullanıcı metriklerini toplayın.

Yöntem 2: Cookie tabanlı bölme Kullanıcıları A/B grubuna atayan bir cookie belirleyin. Aynı URL üzerinden iki farklı deneyim sunun. Performans metriklerini grup bilgisiyle birlikte analitik altyapısına gönderin.

Periyodik Skor Takibi

Tek seferlik iyileştirme yetmez; performans sürekli izlenmeden gerileyebilir.

İzleme önerileri:

Araç	Sıklık	Amaç
GSC Temel Web Verileri	Haftalık	Genel tablo görüntüsü
PSI API	Günlük (otomatik)	Kritik sayfa skoru takibi
Lighthouse CI	Her deploy	Regresyon önleme
web-vitals + GA4	Sürekli	Gerçek kullanıcı trendi
CrUX BigQuery	Aylık	Detaylı segment analizi

PSI API ile Otomatik İzleme

PSI’nin API’si ücretsiz ve API key gerektirmez (kota sınırlıdır). Bir cron job ile kritik sayfalarınızı günlük olarak ölçebilirsiniz:

https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile

Sonuçları bir veritabanına yazıp trend grafiği çizerek performans düşüşlerini erken yakalayabilirsiniz.

Skor Gerilemelerinde Alarm Kurma

Üçüncü taraf bir betik eklendi mi, yeni bir kampanya banner’ı canlıya alındı mı? Bu değişiklikler Core Web Vitals skorlarını sessizce düşürebilir. Çözüm:

Lighthouse CI ile eşik değer alarmları kurun (LCP > 2,5s olursa uyar)
Google Analytics 4’te özel olay olarak gönderilen web-vitals verilerinden alarm oluşturun
Search Console E-posta uyarılarını etkinleştirin

Sektör Bazında Gerçekçi Hedefler

Her sektörün Core Web Vitals ortalamaları farklıdır. E-ticaret siteleri genellikle büyük görseller ve karmaşık JavaScript nedeniyle daha zor performans elde ederken içerik odaklı bloglar daha iyi skorlar gösterir.

Sektör	Tipik LCP Zorluğu	Tipik CLS Zorluğu	Tipik INP Zorluğu
Haber / Blog	Düşük	Orta (reklam)	Düşük
E-ticaret	Yüksek	Yüksek	Orta
SaaS / B2B	Orta	Düşük	Orta
Yerel işletme	Düşük	Düşük	Düşük
Finans / Sigorta	Orta	Orta	Yüksek

Bu tablonun değerlendirmesi şöyledir: E-ticaret sitesiyseniz LCP ve CLS’e öncelik verin. Karmaşık web uygulaması geliştiriyorsanız INP kritik önem taşıır. Reklam geliriyle yaşayan bir haber sitesiyseniz reklam bantlarının CLS’e etkisini yönetmek zorlu ama çözülebilir bir problemdir.

CrUX’ta Veri Yoksa Ne Yapmalısınız?

Bazı sayfalarda CrUX verisi bulunmaz. Bu durumda PSI yalnızca lab verisi gösterir; GSC’de ilgili URL grubu görünmez.

Veri yokluğunun nedenleri:

Sayfa son 28 günde yetersiz Chrome kullanıcısı trafiği almış
Sayfa indekslenmiş ama çok az ziyaret edilmiş (uzun kuyruk içerikler)

Ne yapmalısınız?

Lab verisine güvenerek optimize edin; Lighthouse skorunu “İyi” aralığına çekin.
web-vitals kütüphanesiyle kendi RUM altyapınızı kurun; bu şekilde tüm kullanıcıların verisini kendiniz toplarsınız.
CrUX verisini alan adı düzeyinde kontrol edin: URL bazında veri olmayabilir, ancak alan adı genelinde veri mevcuttur.

Core Web Vitals Kontrol Listesi

Bir sayfayı baştan optimize etmek için aşağıdaki listeyi sırasıyla uygulayın.

LCP için:

LCP öğesini tanımlayın (PSI veya DevTools ile)
TTFB’yi ölçün; > 800ms ise sunucu/CDN iyileştirmesi yapın
LCP görselini preload + fetchpriority="high" ile önceden yükleyin
Görseli WebP/AVIF formatına dönüştürün ve sıkıştırın
Render-blocking CSS ve JS’yi kaldırın veya erteleyin
Web fontlarını self-host edin ve font-display: swap kullanın

CLS için:

Tüm görsel ve videolara width ve height özelliği ekleyin
Reklam alanları için minimum boyut placeholder kurun
Sayfa üstüne dinamik içerik veya banner ekleniyorsa position: fixed kullanın
Layout değiştiren CSS animasyonları transform tabanlı olanlara dönüştürün

INP için:

Long Tasks’ı Performance panelinde tespit edin
Ağır olay işleyicilerini scheduler.yield() ile bölün
Üçüncü taraf script’lerin INP etkisini ölçün ve minimize edin
Ağır işlemleri Web Worker’a taşıyın

Ölçüm ve takip için:

PSI ile mobil ve masaüstü skorları kontrol edin
GSC Temel Web Verileri raporunu haftalık inceleyin
Lighthouse CI’yı deploy sürecine ekleyin
web-vitals kütüphanesiyle RUM altyapısı kurun

Framework ve CMS’e Göre Core Web Vitals İpuçları

WordPress Siteleri

WordPress, dünya genelinde en yaygın CMS’tir ve aynı zamanda Core Web Vitals sorunlarının en sık görüldüğü platformlardan biridir. En yaygın sorunlar:

LCP sorunları: Büyük tema görselleri, preload edilmeyen hero görselleri, onlarca CSS ve JS dosyası yükleyen ağır sayfa yapıcılar (Elementor, Divi).

CLS sorunları: Boyutu tanımlanmamış görseller, reklam widget’ları, dinamik yüklenen içerikler.

INP sorunları: Çok sayıda jQuery eklentisi, ağır checkout süreçleri (WooCommerce).

Çözümler:

WP Rocket, FlyingPress veya NitroPack gibi performans eklentileri LCP ve CLS’te belirgin iyileştirme sağlar.
EWWW Image Optimizer ya da Imagify ile otomatik WebP dönüşümü yapın.
Eklenti sayısını minimize edin; her aktif eklenti potansiyel bir INP riski taşır.
Liteweight tema kullanın: GeneratePress, Kadence veya Blocksy iyi başlangıç seçenekleridir.

Next.js ve React Uygulamaları

Modern JavaScript çerçeveleri büyük JavaScript bundle’ları nedeniyle INP ve LCP açısından risklidir.

LCP için: Next.js’in next/image bileşeni otomatik olarak WebP formatı, lazy loading ve boyut optimizasyonu sağlar. Hero görsel için priority prop’u ekleyerek preload davranışını etkinleştirin.

INP için: React’te gereksiz re-render’lar INP’i artırır. React.memo, useMemo ve useCallback ile bileşen re-render’larını kontrol edin. Ağır hesaplamaları useTransition ile arka plana alın.

CLS için: Server-side rendering (SSR) veya static generation (SSG) ile içeriği hydration öncesinde boyayın. CSR (client-side rendering) sayfalarında hydration sırasında layout kayması yaygındır.

Shopify ve E-ticaret Platformları

E-ticaret siteleri için Core Web Vitals optimizasyonu özellikle kritiktir. Aberdeen Group araştırmasına göre 1 saniyelik sayfa yavaşlaması dönüşüm oranını %7 düşürür.

Shopify’da LCP: Ürün ana görseli genellikle LCP öğesidir. Shopify’ın {% render 'image', preload: true %} özelliği ile hero görsel preload edilebilir.

Shopify’da CLS: Fiyat, stok ve varyant bilgileri JavaScript ile gecikmeli yüklendiğinde düzen kaymasına neden olur. Bu içeriklerin yüksekliğini CSS ile rezerve edin.

Shopify’da INP: Sepete ekleme butonları ve filtre etkileşimleri INP kritik noktalardır. Theme’de kullanılan özel JavaScript’i denetleyin.

Yaygın Core Web Vitals Hataları

Hata 1: Yalnızca Masaüstü Testine Güvenmek

Google mobil deneyimi önceliklendirmektedir. PSI’de masaüstü skoru 90+ iken mobil skor 45 olabilir. Her zaman mobil skorla başlayın.

Hata 2: Lighthouse Skorunu Field Verisiyle Karıştırmak

Lighthouse’da 95 alan bir sayfa, GSC’de “Kötü” olarak görünebilir. Bu çelişki değil, iki farklı ölçüm metodolojisinin sonucudur. Sıralama etkisi için GSC field verisine bakın; hata ayıklama için Lighthouse’u kullanın.

Hata 3: Tek Seferlik Optimizasyon Yapmak

Bir CMS güncellemesi, yeni bir reklam kodu veya eklenen bir script, tüm emekleri geri alabilir. Lighthouse CI ile deploy sürecinde performans eşiği kontrolü kalıcı bir çözümdür.

Hata 4: LCP Görselini Lazy Load Etmek

loading="lazy" özelliği, tarayıcıya görseli ekranda görünene kadar yüklememesini söyler. LCP görselinde bu özellik kullanılırsa LCP ciddi şekilde uzar. LCP öğesi olan görsel için loading="eager" (ya da özelliği hiç eklememek) ve fetchpriority="high" kullanın.

Hata 5: CLS’yi Yalnızca Mobilde Test Etmemek

Bazı CLS sorunları yalnızca belirli ekran genişliklerinde görünür. Duyarlı (responsive) tasarım hatalarından kaynaklanan düzen kaymaları farklı cihazlarda farklı puanlar üretir. Test sırasında mobil, tablet ve masaüstü genişliklerini kontrol edin.

Sık Sorulan Sorular

Core Web Vitals’ı geçmek zor mu?

Sıfırdan optimize edilmemiş bir site için zorlu olabilir; ancak her metrikteki sorunların büyük çoğunluğu birkaç temel düzeltmeyle giderilir. LCP sorunlarının %80’inden fazlası görsel optimizasyonu ve preload etiketiyle çözülür. CLS sorunlarının büyük kısmı boyutsuz görseller ve geç yüklenen reklamlardan kaynaklanır. INP ise genellikle yoğun JavaScript kullanan uygulamalarda sorun yaratır.

Core Web Vitals skoru ne kadar sürede düzelir?

Lab skoru (Lighthouse) değişikliğin hemen ardından ölçülebilir. GSC ve PSI field verisinin güncellenmesi için 28 günlük CrUX penceresi geçmelidir. Yani bir iyileştirme yaptıysanız, sonucunu field verisinde görmeniz yaklaşık 4 hafta sürer.

Yüksek Lighthouse skoru GSC’deki kötü sonucu düzeltir mi?

Hayır. Google’ın sıralama sinyali field verisine (gerçek kullanıcılar) dayanır, Lighthouse lab skoru değil. Lighthouse iyi bir hata ayıklama aracıdır; ancak GSC raporundaki “Kötü” kategorisi gerçek kullanıcı deneyiminden beslenir.

INP, FID’den nasıl farklıdır?

FID yalnızca sayfadaki ilk etkileşimi ölçüyordu ve yalnızca Input Delay’i hesaba katıyordu. INP ise sayfanın tüm yaşam döngüsünde gerçekleşen etkileşimleri izler; Input Delay, Processing Time ve Presentation Delay’in tamamını kapsar. Bu nedenle INP daha temsil edici ama daha zorlu bir metriktir.

Her sayfanın ayrı ayrı optimize edilmesi gerekiyor mu?

Evet ve hayır. CLS ve INP sorunları genellikle site genelinde tekrarlayan bileşenlerden kaynaklanır (header reklamları, aynı JavaScript kütüphanesi), bu nedenle ortak düzeltmeler birçok sayfayı aynı anda iyileştirir. Ancak LCP öğesi sayfadan sayfaya değişeceğinden kritik sayfalar (ana sayfa, ürün sayfaları) ayrı ayrı incelenmelidir.

Core Web Vitals sadece Google için mi önemli?

Hayır. Bu metrikler kullanıcı deneyiminin objektif ölçütleridir. CLS düşürüldüğünde dönüşüm oranı artar; INP iyileştiğinde form doldurma ve ödeme adımlarında terk oranı düşer. LCP optimize edildiğinde hemen çıkma oranı azalır. Etkisi sıralama ötesinde, doğrudan gelir etkisine sahiptir.

Sonuç: Core Web Vitals Bir Teknik SEO Zorunluluğudur

Core Web Vitals, sadece Google’ın bir algoritma güncellemesi değil; kullanıcıların web’de hak ettiği deneyimin teknik standardıdır. LCP, CLS ve INP üçgeni bir sitenin ne kadar “hissettirdiğini” sayılara döker.

Bir sayfanın organik trafiği artırmak için güçlü içeriğe ihtiyacı vardır; bu tartışmasızdır. Ancak bu içeriği taşıyan teknik altyapı kötü deneyim üretiyorsa içerik potansiyelinin önemli bir kısmı boşa gider.

2026 itibarıyla Core Web Vitals optimizasyonu artık “ileri düzey teknik SEO” değil, rekabetçi herhangi bir sitede temel beklentidir. Bu metriklerin analizi, iyileştirilmesi ve sürekli takibi için kapsamlı teknik SEO desteği alabilirsiniz.

Detaylı metrik rehberlerine ulaşmak için: