Caliency.
Web Geliştirme

Core Web Vitals Nedir ve Gerçekten Nasıl Düzeltilir?

Üç metrik, eşikleri, Google'ın sıralama hakkında gerçekte ne söylediği ve Lighthouse puanınızın neden Google'ın baktığı sayı olmadığı.

C

Caliency

12 dk okuma
Masa üstündeki ekranlarda yeşil skor halkalarıyla bir Lighthouse performans raporu ve ağ şelalesi; eller klavyede.

Core Web Vitals, bir sayfanın onu kullanan kişi için nasıl davrandığını ölçen üç ölçümdür: Largest Contentful Paint 2,5 saniye içinde gerçekleşmeli, Interaction to Next Paint 200 milisaniye veya altında olmalı, Cumulative Layout Shift 0,1 veya altında kalmalı. Her biri sayfa yüklemelerinin 75. yüzdeliğinde, mobil ve masaüstü için ayrı ayrı değerlendirilir (web.dev).

Kolay kısmı bu ve her rehber bunu doğru yazıyor. Çoğunun yanlış yazdığı şey bir sonraki soru: bunları düzeltmek gerçekte ne kazandırıyor ve hangi sayıya bakmanız gerekiyor.

Önemli Çıkarımlar

  • Eşikler: LCP 2,5 sn, INP 200 ms, CLS 0,1 — 75. yüzdelikte (web.dev).
  • Google, Core Web Vitals'ın sıralama sistemlerince kullanıldığını söylüyor; aynı belgede "tek bir sinyal yoktur" diyor ve iyi puanın sıralama garantisi olmadığını yazıyor (Google Search Central).
  • Lighthouse puanınız laboratuvar verisidir. Google gerçek Chrome kullanıcılarından gelen saha verisini okur (Chrome UX Report). İkisi düzenli olarak birbirini tutmaz.
  • Kendi sitemizde en büyük iki kazanç bir görsel ağırlığı sorunu ve bir önbellek başlığıydı — ikisi de kod optimizasyonu değil.
  • INP, 2024'te FID'nin yerini alarak kararlı bir Core Web Vital oldu ve geçmesi belirgin biçimde daha zor.

Üç metrik gerçekte neyi ölçüyor

Largest Contentful Paint (LCP) — görünür alandaki en büyük içerik parçasının çizilmeyi bitirdiği an. Pratikte: ziyaretçinin, henüz sayfa olmayan bir şeye kaç saniye baktığı.

Interaction to Next Paint (INP) — kullanıcının etkileşimi ile ekranın görünür biçimde yanıt vermesi arasındaki gecikme; sayfadaki yalnızca ilk etkileşim için değil, hepsi için. First Input Delay'in yerini aldı ve 2024'te kararlı bir Core Web Vital oldu (web.dev). Geçmesi daha zordur, çünkü bir sayfa ilk dokunuşu hızlı karşılayıp sonraki her dokunuşta ağırlaşabilir.

Cumulative Layout Shift (CLS) — sayfa çizilmeye başladıktan sonra okuyucunun altından ne kadar kaydığı. Kullanıcıların adını koymadan tarif ettiği şey budur: üstünde bir reklam yüklendiği için yanlış düğmeye basmak.

Core Web Vitals — "iyi" eşikleriLCPEn büyük içerik boyaması≤ 2,5snINPEtkileşimden boyamaya≤ 200msCLSKümülatif yerleşim kayması≤ 0,1İyiİyileştirme gerekliZayıf
Kaynak: web.dev, Core Web Vitals. Eşikler sayfa yüklemelerinin 75. yüzdeliğinde geçerlidir ve mobil ile masaüstü için ayrı değerlendirilir. INP, 2024'te First Input Delay'in yerini aldı.

  1. yüzdelik, sanılandan önemli. Ortalama ziyaretçinize göre değerlendirilmiyorsunuz; trafiğinizin yavaş ucuna yakın bir yerde değerlendiriliyorsunuz. Ofis wifi'ında hızlı, tren peronunda kullanılamaz olan bir site kalıyor — ve doğrusu da bu.

Google sıralama hakkında gerçekte ne diyor

Google'ın sayfa deneyimi dokümantasyonu, çoğu rehberin yalnızca yarısını alıntıladığı iki şey söylüyor:

"Core Web Vitals sıralama sistemlerimiz tarafından kullanılır. Site sahiplerinin Arama'da başarı için iyi Core Web Vitals değerlerine ulaşmasını öneriyoruz."

"Tek bir sinyal yoktur. Temel sıralama sistemlerimiz, genel sayfa deneyimiyle uyumlu çeşitli sinyallere bakar."

Ve açıkça:

"Search Console'un Core Web Vitals raporu ya da üçüncü taraf araçlar gibi raporlarda iyi sonuç almak, sayfalarınızın Google Arama sonuçlarının en üstünde sıralanacağını garanti etmez; harika sayfa deneyimi Core Web Vitals puanlarından ibaret değildir."

(Google Search Central, sayfa deneyimi, son güncelleme 10 Aralık 2025. Çeviri bize ait.)

Birlikte okuyunca: metrikler kullanılıyor ve bir kaldıraç değiller. Biri size bir Core Web Vitals projesi için sıralama kazancı rakamı veriyorsa, Google'ın kendi dokümantasyonunun vaat etmekten kaçındığı bir şeyi vaat ediyordur.

Bu işi yapmanın savunulabilir gerekçesi farklı ve daha iyi: bu metrikler bir insanın sayfanızı kullanıp kullanamadığını ölçüyor. Bu da sıralamayı etkilesin etkilemesin satın almayı etkiliyor. SEO hizmetimiz hızı bir sıralama taktiği olarak değil, teknik temelin parçası olarak ele alıyor — tam olarak bu yüzden.

Bu sinyalin Türkiye'de gerçekte nasıl göründüğünü, 200 popüler .tr sitesinin Google'ın gerçek kullanıcı verisiyle ölçtüğümüz karnesinde site hızı ve SEO yazısında anlattık.

Lighthouse puanınız Google'ın okuduğu sayı değil

Bu alanda en çok mühendislik saati bu tek yanlış anlamaya gidiyor.

Lighthouse laboratuvar verisidir. Tek makine, tek simüle edilmiş ağ, tek koşu. Bir teşhis aracıdır — nedeni bulmakta mükemmel, gerçeği tarif etmekte zayıf.

Search Console saha verisi raporlar; kaynağı Chrome User Experience Report: "gerçek dünyadaki Chrome kullanıcılarının web'deki popüler adresleri nasıl deneyimlediğini yansıtan bir veri kümesi", "dünyadaki gerçek tarayıcılardan, kullanıcı uygunluğunu belirleyen belirli tarayıcı seçeneklerine göre" toplanıyor (Chrome UX Report).

Bundan iki yaygın sonuç çıkıyor:

  • Kusursuz laboratuvar puanı, başarısız saha verisi. Test makineniz, kitlenizin kötü bağlantıdaki telefonu değil.
  • Hiç saha verisi olmaması. CrUX, "tüm kaynakların veya sayfaların veri kümesinde temsil edilmediğini" belirtiyor; sayfaların istatistiksel anlamlılık için yeterli trafiğe ihtiyacı var. Yeni ya da düşük trafikli bir sitede okunacak bir şey olmayabilir — ki bu geçmekle aynı şey değildir.

Yani: nedeni bulmak için Lighthouse, kovalanacak bir sorun olup olmadığına karar vermek için saha verisi. Tersini yapmak, ekibiniz dışında kimsenin görmediği bir sayıyı hedefleyen aylar üretiyor.

Bizimkini gerçekte ne oynattı

Bu sitenin performansını yakın zamanda yeniden kurduk ve dürüst hikâye bir kontrol listesinden daha yararlı — çünkü en çok işe yarayan iki şey beklediklerimiz değildi.

Anasayfada başlangıç ve bitiş:

  • Masaüstü: 78 → 97.
  • Mobil: 66 → 82.

En büyük iki tekil kazanç:

Sessizce yanlış olan bir önbellek başlığı. Medya dosyaları immutable ile sunuluyordu; bu, tarayıcıya dosyayı bir daha hiç kontrol etmesi gerekmediğini söyler. Yalnızca dosya adları içerik özeti taşıdığında doğrudur. Bizimkiler taşımıyordu. Her ziyaretçi bir yıl boyunca eski görselleri tutacaktı ve bunu ancak güncellenen görseller görünmediği için fark ettik. Düzeltmesi hiçbir şeye mal olmadı ve hiçbir performans aracı bunu performans sorunu olarak işaretlemiyor.

Kimsenin tartmadığı görseller. On bir avatar fotoğrafı, tam çözünürlükte JPEG olarak 1.788 KB ediyordu. Doğru boyutta WebP olarak 44 KB. Bir sıra küçük yuvarlak portrede %97 azalma — ve fark etmesi düzeltmesinden uzun sürdü.

Ve LCP hakkında bize en çok şeyi öğreten: bir açılış animasyonu hero'nun üstüne tam genişlikte opak bir perde çiziyordu ve JavaScript yüklenip hidrasyon bitene kadar opak kalıyordu. Arkasındaki hiçbir şey çizilmiş sayılamıyordu. Dolayısıyla LCP, içerikle ilgili herhangi bir şeye değil hidrasyon süresine bağlanmıştı. Animasyonu CSS'e taşımak — aynı animasyon, paket yerine stil sayfasıyla — ikisini birbirinden ayırdı.

Üçünden hiçbiri zekice bir optimizasyon değil. Sırasıyla: bir başlık, bir dosya boyutu ve gereksiz yere JavaScript bekleyen bir animasyon.

Bizim çalışma sıramız

Kontrol listesi değil, sıra — çünkü zamanı kazandıran şey sıranın kendisi.

  1. Önce saha verisini okuyun. Search Console ya da doğrudan CrUX. Saha verisi geçiyorsa, Lighthouse ne derse desin bir Core Web Vitals sorununuz yok.
  2. LCP öğesini belirleyin. Lighthouse adını veriyor. On seferin dokuzunda çözüm, onun ne olduğunu bilmekten doğrudan çıkıyor: aşırı büyük bir hero görseli, bir web fontu ya da JavaScript'in arkasına saklanmış bir şey.
  3. Gönderdiğinizi tartın. Görselleri gösterildikleri boyutta WebP ya da AVIF'e çevirin. Gösterişsiz iş ve genellikle mevcut en büyük kazanç.
  4. Ekranın üstündeki hiçbir şeyin JavaScript beklemediğini doğrulayın. Hidrasyona kadar görünmeyen içerik çizilmiş sayılmaz.
  5. Geç yüklenen her şeye yer ayırın. Kendi boyutu tanımlı görseller, sabit yükseklikli reklam alanları. CLS'in neredeyse tamamı ayrılmamış yerdir.
  6. INP'yi en sona bırakın. Genellikle ana iş parçacığında çalışan fazla JavaScript'in belirtisidir ve üçü içinde ucuza düzeltilmesi en zor olandır.

Onarmak yerine yeniden kuruyorsanız, bir web sitesinin gerçekte neyi kapsadığı hız kararlarının nerede verildiğini anlatıyor — çoğu ekibin sandığından daha erken.

Kısaca

Core Web Vitals'ı düzeltin, ama birileri size sıralama vaat ettiği için değil — Google'ın kendi ifadesi o vaadi desteklemiyor. Düzeltin çünkü bu metrikler insanların sitenizi kullanıp kullanamadığını ölçüyor. Sorununuz olup olmadığına karar vermek için saha verisini, nedenini bulmak için laboratuvar verisini okuyun. Ve nasıl çalıştığını optimize etmeden önce ne gönderdiğinizi tartın; en büyük kazançlar genellikle utandıracak kadar sıradan.

Siteniz yavaşsa ve tahmin etmek yerine teşhis edilmesini istiyorsanız, neyle çalıştığınızı anlatın.

Büyük kurumsal sitelerin teknik temellerde nerede durduğunu merak ediyorsanız, BIST 100 web sitesi araştırmamız 85 ana sayfanın ölçümünü veriyor.

Bir fikriniz mi var?

Kısa bir görüşmede kapsamlandırıp sabit fiyat verelim.

Proje başlat →