Ana Sayfa / Ücretsiz Araçlar / Core Web Vitals Analizörü
Teknik SEO & Hız

Core Web Vitals (LCP, INP, CLS) & Sayfa Hızı Simülatörü

Google sıralama faktörü olan LCP (Largest Contentful Paint), INP (Interaction to Next Paint) ve CLS (Cumulative Layout Shift) eşik değerlerini simüle edin, darboğazları ve çözüm önerilerini görün.

Web Sitesi & Simülasyon Değerleri
İyi: < 2.5s | Kötü: > 4.0s
İyi: < 200ms | Kötü: > 500ms
İyi: < 0.1 | Kötü: > 0.25
İyi: < 800ms | Kötü: > 1800ms
Google Core Web Vitals Skoru
Genel Performans Skoru
96 / 100
Google SEO Uyumu
GEÇTİ (İYİ)
En Kritik Metrik
LCP (1.8s)

Core Web Vitals Nedir ve Google Sıralamasını Nasıl Etkiler?

Google, kullanıcı deneyimini (Page Experience) web sitelerinin organik sıralamasında doğrudan ve resmi bir sıralama faktörü olarak kullanır. Core Web Vitals (Önemli Web Verileri); W3C Web Performance Çalışma Grubu ve Google Chrome ekibi tarafından geliştirilen, bir web sayfasının ne kadar hızlı yüklendiğini, kullanıcının ilk etkileşimine ne kadar çabuk yanıt verdiğini ve içerik ekrana çizilirken görsel öğelerin ne kadar kararlı durduğunu ölçen 3 temel performans metriğinden oluşur.

2024 ve 2026 algoritmalarında Google, eski FID (First Input Delay) metriğini tamamen emekliye ayırarak yerine çok daha kapsamlı olan INP (Interaction to Next Paint) metriğini resmi standart haline getirmiştir. Google algoritmaları, web sitenizi laboratuvar testlerine (Lighthouse) göre değil; son 28 gün içinde sitenizi ziyaret eden gerçek Chrome kullanıcılarının (CrUX - Chrome User Experience Report) 75. persentil verilerine göre değerlendirir. Core Web Vitals eşiklerini başarıyla geçen web siteleri organik arama sonuçlarında rakiplerinin önüne geçerken; e-ticaret sitelerinde sepet terk oranları %26 azalmakta ve dönüşüm oranları ortalama %24 artış göstermektedir.

1. Core Web Vitals Metrikleri Eşikleri ve Ağırlık Matrisi

Google'ın yeşil (İyi), sarı (Geliştirilmeli) ve kırmızı (Zayıf) olarak sınıflandırdığı 2026 güncel eşik değerleri aşağıda özetlenmiştir:

Metrik Adı Ölçtüğü Kullanıcı Deneyimi İyi (Yeşil) Geliştirilmeli (Sarı) Zayıf (Kırmızı)
LCP (Largest Contentful Paint) Görünür alandaki en büyük görsel veya metin bloğunun ekrana çizilme süresi. ≤ 2.5 sn 2.5 - 4.0 sn > 4.0 sn
INP (Interaction to Next Paint) Kullanıcının yaptığı tüm tıklama ve tuş vuruşlarına tarayıcının sonraki kareyi çizme hızı. ≤ 200 ms 200 - 500 ms > 500 ms
CLS (Cumulative Layout Shift) Sayfa yüklenirken öğelerin beklenmedik biçimde yer değiştirme puanı. ≤ 0.10 0.10 - 0.25 > 0.25
TTFB (Time to First Byte) Web sunucusunun ilk veri baytını tarayıcıya ulaştırma hızı (Sunucu performansı). ≤ 800 ms 800 - 1800 ms > 1800 ms
FCP (First Contentful Paint) Kullanıcının ekranda ilk DOM içeriğini (metin, logo, çizgi) gördüğü ilk an. ≤ 1.8 sn 1.8 - 3.0 sn > 3.0 sn

2. Tarayıcı İşleme Boru Hattı (Rendering Pipeline) ve Metriklerin Oluşumu

Tarayıcı bir URL'e bağlandığında şu adımları sırasıyla yürütür:

  • 1. DOM & CSSOM İnşası: HTML ve harici CSS dosyaları indirilip bellek ağacına dönüştürülür. Senkron yüklenen JavaScript dosyaları bu aşamayı bloke eder.
  • 2. Render Tree & Layout (Reflow): Hangi öğelerin ekranda nereye oturacağı ve boyutları piksel piksel hesaplanır. Boyutsuz görseller veya sonradan gelen web fontları bu aşamada CLS kaymalarına yol açar.
  • 3. Paint & Composite: Piksel renkleri katmanlara çizilir ve GPU tarafından birleştirilir. En büyük katman ekrana yansıdığı an LCP metriği kilitlenir.
  • 4. Main Thread Boşalması (INP): Kullanıcı ekrandaki bir butona veya menüye tıkladığında, eğer JavaScript ana iş parçacığını (Main Thread) 50 milisaniyeden uzun süren bir görevle (Long Task) meşgul ediyorsa arayüz donar ve INP süresi uzar.

3. Adım Adım İki Gerçek Uygulama Vakası

Vaka 1: B2B Kurumsal SaaS — 4.2s LCP ve 0.28 CLS Değerinden 1.4s LCP ve 0.02 CLS'ye Geçiş

Başlangıç Durumu: Bulut tabanlı bir proje yönetim yazılımı sunan teknoloji şirketi, ana açılış sayfasında 3.8 MB boyutunda PNG formatında bir banner görseli kullanıyordu. Ayrıca hero görseline WordPress eklentisi tarafından yanlışlıkla loading="lazy" verilmişti. Fontlar geç yüklendiği için başlıklar sonradan zıplıyor (CLS 0.28) ve mobil LCP süresi 4.2 saniyeyi buluyordu. Mobil Google PageSpeed skoru 38 puandı.

Mühendislik Müdahalesi:

  • Hero banner görseli 185 KB boyutunda yeni nesil WebP formatına sıkıştırıldı ve HTML <head> içine <link rel="preload" as="image" href="..." fetchpriority="high"> eklendi; lazy load kaldırıldı.
  • Banner görseline ve butonlara sabit aspect-ratio ve piksel alanları rezerve edildi; fontlara font-display: swap uygulandı.
  • Statik CSS ve JS varlıkları HTTP/2 multiplexing ve Cloudflare Edge CDN üzerinden dağıtıldı.
Performans Parametresi Optimizasyon Öncesi Optimizasyon Sonrası Net Sonuç
LCP (Largest Contentful Paint) 4.20 sn (Zayıf) 1.42 sn (İyi) %66 Hızlanma (Yeşil)
CLS (Cumulative Layout Shift) 0.28 (Kritik Kayma) 0.02 (Sıfır Kayma) Kusursuz Kararlılık
Google Lighthouse Skoru 38 / 100 98 / 100 +60 Puan Artış
Organik Demo Talep Dönüşümü %1.8 %4.3 2.38 Kat (+%138) Artış

Vaka 2: E-Ticaret Moda Portalı — INP (650ms -> 85ms) ve Sepet Sayfası Dönüşüm Kurtarma

Başlangıç Durumu: Giyim e-ticaret sitesinde kullanıcılar ürün varyantını (beden/renk) seçtiğinde veya "Sepete Ekle" butonuna bastığında arayüz 600-700 milisaniye boyunca kilitleniyordu. Google CrUX raporunda sitenin INP değeri 650 ms (Kırmızı) olarak işaretlenmişti. Kullanıcılar butonun çalışmadığını sanıp peş peşe basıyor, mükerrer istekler yüzünden sepet terk oranı %68'e ulaşıyordu.

Uygulanan Strateji: Chrome DevTools Performance paneli ile Long Task (Uzun Görev) analizi yapıldı. Sepete ekleme anında çalışan 14 farklı pazarlama pikselinin (Meta, TikTok, Criteo vb.) ana iş parçacığını kilitlediği saptandı. Tüm üçüncü taraf takip etiketleri Web Worker mimarisine (Partytown) taşındı ve ürün varyant değişimi scheduler.yield() fonksiyonu ile asenkron mikro görevlere bölündü.

Elde Edilen Sonuç: INP süresi 650 ms'den 85 ms'ye geriledi (7.6 kat duyarlılık artışı). Sayfa anında tepki verdiği için sepet terk oranı %68'den %42'ye düştü; mobil cihazlardan gelen net sipariş cirosu %48 arttı.

4. Web Geliştiricilerinin En Sık Yaptığı 6 Kritik Core Web Vitals Hatası

1. LCP Görseline "loading=lazy" Vermek (En Ölümcül CWV Hatası):

Ekranın en üstünde yer alan ana banner veya logo görseline lazy load uygulamak, tarayıcının indirme işlemini başlatmak için tüm CSS ve DOM render'ını beklemesine neden olur. Bu durum LCP süresini doğrudan 2-3 saniye geciktirir. LCP görseline kesinlikle lazy load verilmemeli; tam tersine fetchpriority="high" ve preload verilmelidir.

2. Görsel ve Video Etiketlerinde Boyut (width/height) Belirtmemek:

HTML içinde width ve height veya CSS'te aspect-ratio tanımlanmadığında tarayıcı görsel inene kadar 0 piksel yer ayırır. Görsel indiğinde altındaki tüm metinleri aşağı iter ve devasa bir CLS (düzen kayması) cezası yaratır.

3. Ağır Üçüncü Taraf (Third-Party) Script'leri Kontrolsüz Yüklemek:

Google Tag Manager, canlı sohbet (chat) kutuları ve analiz araçlarının ana iş parçacığında aynı anda çalıştırılması, kullanıcının tıklama etkileşimlerini bloke ederek INP skorunu kırmızıya düşürür.

4. Web Fontlarında FOUT/FOIT Önlemi Almamak:

Google Fonts veya özel font dosyaları yüklenirken font-display: swap kullanılmadığında sayfa yazıları önce kaybolur (FOIT), font yüklendiğinde ise satırlar yeniden kırılarak CLS kaymasına neden olur.

5. Sunucu Yanıt Süresini (TTFB) İhmal Edip Yalnızca Ön Yüze Odaklanmak:

Ön yüzü ne kadar optimize ederseniz edin; veritabanı sorguları veya yavaş bir sunucu nedeniyle ilk bayt süresi (TTFB) 1.5 saniye sürüyorsa, LCP süresinin 2.5 saniyenin altında kalması matematiksel olarak imkansızdır.

6. Laboratuvar Skoru (Lighthouse) ile Saha Verisini (CrUX) Karıştırmak:

Kendi hızlı bilgisayarınızda Lighthouse'tan 100 almak sitenizin Google testini geçtiği anlamına gelmez. Google sıralama algoritması, düşük segment telefon kullanan gerçek kullanıcıların oluşturduğu CrUX saha verilerini esas alır.

Core Web Vitals Hakkında Sıkça Sorulan Sorular

Core Web Vitals nedir ve Google sıralamasını nasıl etkiler?
Core Web Vitals (Önemli Web Verileri); Google'ın web sitelerinin gerçek kullanıcı deneyimini ölçtüğü 3 ana metriktir: LCP (yükleme hızı), INP (etkileşim duyarlılığı) ve CLS (görsel kararlılık). Google bu metrikleri resmi 'Page Experience' (Sayfa Deneyimi) sıralama faktörü olarak kullanır. 75. persentilde yeşil eşikleri geçen siteler arama sonuçlarında belirgin sıralama avantajı kazanır ve hemen çıkma oranları düşer.
LCP (Largest Contentful Paint) nasıl 2.5 saniyenin altına indirilir?
LCP'yi 2.5 saniyenin altına çekmek için ilk ekrandaki en büyük görsel veya banner öğesini WebP/AVIF formatına dönüştürmek, fetchpriority="high" niteliği ve <link rel="preload"> ile önceden yüklemek gerekir. Ayrıca sunucu yanıt süresini (TTFB) 500 ms altına düşürmek, statik varlıkları CDN üzerinden sunmak ve LCP görseline kesinlikle loading="lazy" eklememek şarttır.
FID yerine gelen INP (Interaction to Next Paint) nedir ve nasıl optimize edilir?
INP, Google'ın 2024 Mart ayında eski FID metriğinin yerine getirdiği yeni nesil duyarlılık metriğidir. Kullanıcının sayfa boyunca gerçekleştirdiği tüm tıklama ve klavye etkileşimlerinin tarayıcı tarafından işlenip ekranda bir sonraki karenin çizilmesine kadar geçen süreyi ölçer. 200 ms altı 'İyi' kabul edilir. Ana iş parçacığını (main thread) kilitleyen 50 ms üzeri uzun görevleri (Long Tasks) parçalamak ve kod bölme (code-splitting) yapmak INP'yi doğrudan iyileştirir.
CLS (Cumulative Layout Shift) kayması neden olur ve nasıl sıfırlanır?
CLS, sayfa yüklenirken metin, buton veya görsellerin beklenmedik şekilde yer değiştirmesidir. Başlıca nedenleri; görsellere ve reklam kutularına width ve height boyutlarının CSS/HTML'de önceden rezerve edilmemesi, dinamik enjekte edilen banner'lar ve geç yüklenen web fontlarıdır. Tüm medya öğelerine sabit en-boy oranı (aspect-ratio) tanımlamak ve font-display: swap kullanmak CLS'yi 0.05 altına indirir.
LCP görseline lazy loading (gecikmeli yükleme) vermek neden büyük bir hatadır?
loading="lazy" özniteliği, ekranın altında kalan (below the fold) görsellerin kullanıcı sayfayı aşağı kaydırana kadar indirilmesini ertelemek için tasarlanmıştır. Eğer sayfanın en üstündeki hero banner veya öne çıkan görsele lazy loading verirseniz, tarayıcı görseli indirmeye başlamadan önce tüm DOM'un hesaplanmasını bekler; bu da LCP süresine fazladan 1.5 - 3 saniye gecikme ekleyerek Core Web Vitals testinde başarısız olmanıza neden olur.
Laboratuvar Verisi (Lighthouse) ile Saha Verisi (CrUX) arasındaki fark nedir?
Lighthouse (Lab Data), kontrollü bir sunucu ortamında simüle edilmiş bir cihaz ve ağ bağlantısıyla anlık test yapar. Chrome User Experience Report (CrUX / Field Data) ise son 28 gün içinde gerçek kullanıcıların Chrome tarayıcılarında yaşadığı gerçek dünya deneyimlerinin 75. persentilini yansıtır. Google sıralama algoritması laboratuvar skorlarına değil, doğrudan CrUX saha verilerine göre karar verir.

İşinizi Dijitalde Büyütmeye Hazır mısınız?

Kurumsal web tasarım, özel yazılım çözümleri ve doğrudan dönüşüm odaklı performans pazarlama stratejilerimizle markanızı zirveye taşıyalım.

Teklif Alın

Projenizi Anlatın

Fikirlerinizi gerçeğe dönüştürmek için ilk adımı atın. Uzman ekibimiz hemen dönüş yapsın.

Talebiniz başarıyla alındı.
Size en kısa sürede ulaşacağız.
Hemen Ara WhatsApp Teklif Al