Bir sitenin ne kadar hızlı açıldığı artık öznel bir izlenim değil, Google’ın da doğrudan ölçtüğü somut bir veri. Core Web Vitals, bu ölçümü standart hale getiren metrik setidir ve 2026 itibarıyla önemli bir eşiği geride bıraktı. Bu yazıda Core Web Vitals’ın güncel durumunu, 2026’nın en önemli gelişmesini ve üç metriği nasıl iyileştirebileceğinizi ele alıyoruz.
Core Web Vitals Nedir? (Kısa Hatırlatma)
Core Web Vitals, Google’ın bir web sayfasının kullanıcı deneyimini üç somut boyutta ölçtüğü standart bir metrik setidir: yükleme hızı, etkileşim tepkiselliği ve görsel kararlılık. Bu üç metrik, gerçek kullanıcıların tarayıcılarından toplanan veriye (alan verisi) dayanır; laboratuvar ortamında yapılan simülasyonlardan farklı olarak, sitenizin gerçek ziyaretçiler tarafından nasıl deneyimlendiğini yansıtır.
Üç Temel Metrik Nedir?
Core Web Vitals üç metrikten oluşur: LCP (sayfanın ana içeriğinin ne kadar hızlı göründüğü), INP (kullanıcı etkileşimlerine ne kadar hızlı yanıt verildiği) ve CLS (sayfa yüklenirken içeriğin ne kadar “zıpladığı”). Bir sayfanın “iyi” (good) olarak değerlendirilmesi için üçünün de eşik değerlerin altında kalması gerekir.
2026’nın En Önemli Gelişmesi: Tüm Tarayıcılarda Tam Destek
Core Web Vitals tarafında 2026’ya damgasını vuran gelişme, yeni bir metrik değil, evrensel tarayıcı desteğinin tamamlanması oldu: Aralık 2025’te Safari 26.2’nin yayınlanmasıyla birlikte, LCP ve INP metrikleri “Baseline Newly Available” statüsüne ulaştı — yani artık Chrome, Edge, Firefox ve Safari dahil tüm büyük tarayıcılar bu metrikleri ölçebilecek API desteğine sahip.
Bu Gelişme Neden Önemli?
Önceden Safari’nin bu API’leri tam desteklememesi, Safari/iOS kullanıcı tabanı yüksek sitelerde CrUX (Chrome User Experience Report) verisinin gerçek kullanıcı kitlesini eksik yansıtma riski taşıyordu. Tam tarayıcı desteğiyle birlikte, ölçülen alan verisinin tüm platformlardaki kullanıcıları daha eksiksiz temsil etmesi bekleniyor; bu da Core Web Vitals raporlarının doğruluğunu artıran, teknik ama pratik önemi yüksek bir gelişme.
LCP (Largest Contentful Paint) Nedir, Nasıl İyileştirilir?
LCP, kullanıcının ekranında görünen en büyük içerik öğesinin (genellikle bir görsel, video veya büyük metin bloğu) ne kadar sürede tamamen yüklendiğini ölçer. İyi kabul edilen eşik 2.5 saniyenin altıdır.
LCP’yi Yavaşlatan En Yaygın Nedenler Nelerdir?
Yavaş sunucu yanıt süresi, optimize edilmemiş büyük görseller, render’ı bloke eden CSS/JavaScript dosyaları ve istemci tarafında (client-side) geç render edilen içerik, LCP’yi yavaşlatan en yaygın nedenlerdir. Görselleri sıkıştırmak, kritik CSS’i satır içine almak ve sunucu/CDN performansını iyileştirmek, LCP’de en hızlı kazanımı sağlayan adımlardır.
LCP’yi Hızlandırmak İçin Hangi Teknik Adımlar Atılmalı?
Sayfanın en büyük içerik öğesi genellikle bir görselse, bu görseli preload ile önceden yükletmek, loading="lazy" özniteliğinin yanlışlıkla bu görsele uygulanmamasını sağlamak ve modern formatlara (WebP, AVIF) geçmek en somut kazanımı sağlar. Sunucu tarafında ise bir CDN kullanmak ve sunucunun ilk baytı gönderme süresini (TTFB) kısaltmak, tüm sayfa için LCP’yi doğrudan iyileştirir.
INP (Interaction to Next Paint) Nedir, Nasıl İyileştirilir?
INP, kullanıcının bir tıklama, dokunma veya tuş basımı gibi etkileşimine sayfanın ne kadar hızlı görsel bir yanıt verdiğini ölçer. İyi kabul edilen eşik 200 milisaniyenin altıdır.
INP Neden FID’in Yerini Aldı?
INP, Mart 2024’te önceki metrik olan FID (First Input Delay)‘in yerini resmi olarak aldı; çünkü FID yalnızca sayfadaki ilk etkileşimin gecikmesini ölçüyordu, INP ise sayfa ömrü boyunca gerçekleşen tüm etkileşimleri değerlendirip 75. yüzdelikteki en kötü etkileşimi raporluyor. Bu değişiklik, ölçümü daha zor “kandırılabilir” ve gerçek kullanıcı deneyimini çok daha temsili hale getirdi.
INP’yi Yükselten En Yaygın Hatalar Nelerdir?
Ana iş parçacığını (main thread) uzun süre bloke eden ağır JavaScript görevleri, gereksiz üçüncü parti betikler (analitik, reklam, chat widget’ları) ve büyük DOM boyutu, INP’yi olumsuz etkileyen en yaygın nedenlerdir. Uzun görevleri daha küçük parçalara bölmek ve üçüncü parti betikleri asenkron yüklemek, INP’yi iyileştirmenin en etkili yollarındandır.
CLS (Cumulative Layout Shift) Nedir, Nasıl İyileştirilir?
CLS, sayfa yüklenirken görsel öğelerin beklenmedik şekilde yer değiştirmesini (örneğin bir reklam yüklendiğinde altındaki metnin aşağı kaymasını) ölçer. İyi kabul edilen eşik 0.1’in altıdır.
CLS’ye Neden Olan En Yaygın Hatalar Nelerdir?
Boyutu önceden tanımlanmamış görsel ve video öğeleri, sayfa yüklendikten sonra dinamik olarak eklenen reklam/banner alanları ve geç yüklenen özel yazı tipleri (web font’lar), CLS’ye neden olan en yaygın hatalardır. Her görsele ve gömülü öğeye width/height özniteliklerini (veya CSS aspect-ratio) baştan tanımlamak, CLS sorunlarının büyük kısmını tek başına çözer.
Core Web Vitals SEO Sıralamasını Doğrudan Etkiliyor mu?
Evet, ama sınırlı bir ağırlıkla. Google, Core Web Vitals’ı “Sayfa Deneyimi” sıralama sinyallerinin bir parçası olarak kullandığını resmi olarak açıklamıştır; ancak bu sinyal, içerik kalitesi ve alaka düzeyi gibi faktörlerin önüne geçmez. İki içerik kalite açısından eşit olduğunda, daha hızlı ve daha kararlı olan sayfa küçük bir avantaj elde eder — ama zayıf bir içeriği mükemmel Core Web Vitals skorları tek başına kurtaramaz.
Bu dengeyi doğru kurmak, gereksiz bir kaygıyı da ortadan kaldırır: Core Web Vitals skorlarınız “mükemmel” değil, “iyi” eşiğinin üzerindeyse, marjinal bir iyileştirme için haftalarca geliştirici zamanı harcamak yerine, o zamanı içerik kalitesine veya E-E-A-T sinyallerine ayırmak genellikle daha yüksek getiri sağlar.
Core Web Vitals Nasıl Ölçülür?
Core Web Vitals’ı ölçmek için birkaç farklı araç kullanılabilir; her birinin sunduğu veri türü farklıdır.
Laboratuvar Verisi ile Alan Verisi Arasındaki Fark Nedir?
Laboratuvar (lab) verisi, Lighthouse gibi araçların kontrollü bir ortamda, tek bir simülasyonla ölçtüğü sonuçlardır; tutarlıdır ama gerçek kullanıcı çeşitliliğini yansıtmaz. Alan (field) verisi ise CrUX üzerinden gerçek kullanıcıların tarayıcılarından toplanan, Google’ın sıralama için asıl kullandığı veridir. Geliştirme sırasında hızlı test için lab verisi, gerçek performansı değerlendirmek için ise alan verisi esas alınmalıdır.
Core Web Vitals İyileştirmede Sık Yapılan Hatalar
Core Web Vitals’ı iyileştirirken izlenmesi gereken temel kontrol noktaları şunlardır.
En sık yapılan hata, yalnızca Lighthouse skoruna (lab verisine) bakıp gerçek kullanıcı (alan) verisini hiç kontrol etmemektir; bir sayfa laboratuvar testinde mükemmel skor alsa bile, gerçek kullanıcıların yavaş bağlantı veya eski cihazlarda farklı bir deneyim yaşaması mümkündür. Bir diğer yaygın hata, tek seferlik bir iyileştirme yapıp süreci bir daha kontrol etmemektir — yeni eklenen bir üçüncü parti betik veya güncellenmeyen bir görsel, zamanla skorları geriye götürebilir.
Astro, WordPress Gibi Modern Sitelerde Core Web Vitals Yönetimi
Modern statik/hibrit framework’ler (Astro gibi) ile geleneksel CMS’ler (WordPress gibi) arasında Core Web Vitals yönetimi farklılaşır: Astro gibi framework’ler, varsayılan olarak minimum JavaScript gönderdiği için INP açısından genellikle avantajlıdır; WordPress’te ise eklenti sayısının ve kalitesinin doğrudan etkisi büyüktür — her eklenti potansiyel olarak ek JavaScript/CSS yükü getirir. Platform ne olursa olsun, temel prensip aynıdır: görselleri optimize edin, gereksiz üçüncü parti kodu azaltın ve düzenli olarak gerçek kullanıcı verisini kontrol edin.
Core Web Vitals Bir Kerelik Bir Görev Değil
Core Web Vitals, bir kez düzeltilip unutulacak bir kontrol listesi değildir; yeni içerik, yeni eklenti veya yeni bir üçüncü parti entegrasyon eklendikçe skorlar değişebilir. Bu nedenle düzenli olarak Search Console’daki alan verisini kontrol etmek, sitenizin gerçek kullanıcı deneyimini kalıcı olarak korumanın tek güvenilir yoludur.
Sıkça Sorulan Sorular
01Core Web Vitals’ta 2026’da yeni bir metrik eklendi mi?
Hayır; 2026’nın en önemli gelişmesi yeni bir metrik değil, Aralık 2025’te Safari 26.2 ile LCP ve INP’nin tüm büyük tarayıcılarda desteklenir hale gelmesiydi.
02INP eşiği kaç milisaniyedir?
200 milisaniyenin altı “iyi” olarak kabul edilir; 200-500 milisaniye arası “iyileştirme gerekiyor”, 500 milisaniyenin üzeri ise “zayıf” olarak değerlendirilir.
03LCP eşiği kaç saniyedir?
2.5 saniyenin altı “iyi” kabul edilir; 2.5-4 saniye arası “iyileştirme gerekiyor”, 4 saniyenin üzeri ise “zayıf” olarak değerlendirilir.
04CLS puanı nasıl hesaplanır?
CLS, sayfa yüklenirken gerçekleşen tüm beklenmedik yer değiştirmelerin etki alanı ve mesafesine göre hesaplanan, boyutsuz bir puandır; 0.1’in altı iyi kabul edilir.
05Core Web Vitals kötü olan bir site cezalandırılır mı?
Doğrudan bir “ceza” söz konusu değildir; ancak sayfa deneyimi sinyali zayıf olan bir sayfa, aynı kalitede içeriğe sahip daha hızlı bir rakibe kıyasla küçük bir dezavantaj yaşayabilir.
06PageSpeed Insights ile Search Console’daki veriler neden farklı çıkabilir?
PageSpeed Insights tek bir sayfayı anlık olarak test ederken, Search Console site genelindeki sayfaları gruplandırıp son 28 günlük gerçek kullanıcı verisini raporlar; bu nedenle sonuçlar farklılaşabilir.
07Mobil ve masaüstü Core Web Vitals skorları ayrı mı değerlendirilir?
Evet; Google, mobil ve masaüstü deneyimini ayrı ayrı ölçer ve raporlar, çünkü cihaz türüne göre performans karakteristiği önemli ölçüde değişir.
08Core Web Vitals’ı iyileştirmek için mutlaka geliştirici desteği mi gerekir?
Çoğu temel iyileştirme (görsel sıkıştırma, gereksiz eklenti kaldırma) teknik bilgi gerektirmeden yapılabilir; ancak JavaScript optimizasyonu gibi ileri düzey iyileştirmeler genellikle geliştirici desteği gerektirir.
09Core Web Vitals her sayfa için ayrı mı değerlendirilir?
Evet, teorik olarak her URL ayrı ölçülür; ancak Search Console, benzer sayfaları (örneğin aynı şablonu kullanan blog yazıları) URL grupları halinde raporlar.
İlgili Araç
Bu konuyla ilgili çalışırken Web Site Hız Testi aracımızı ücretsiz kullanabilirsiniz.

