Core Web Vitals, Google’ın gerçek kullanıcı verisiyle sayfa deneyimini ölçtüğü üç metriktir: yüklenme hızı için LCP (≤ 2,5 saniye), yanıt verme hızı için INP (≤ 200 milisaniye) ve görsel kararlılık için CLS (≤ 0,1). Bir sayfa ziyaretlerin en az %75’inde bu üç eşiği birden geçtiğinde “iyi” kabul edilir.
Bu rehberde metriklerin ne ölçtüğünü, Google’ın puanlamayı tam olarak nasıl yaptığını ve her metrik için hangi düzeltmenin gerçekten işe yaradığını bulacaksınız.
Core Web Vitals nedir?
Bununla birlikte, Core Web Vitals, sayfa deneyiminin üç farklı boyutunu ölçen saha metrikleridir. Dolayısıyla, “Saha” kelimesi burada kritik: bu değerler sizin bilgisayarınızda çalıştırdığınız bir testten değil, sitenizi ziyaret eden gerçek Chrome kullanıcılarından toplanır.
| Metrik | Ölçtüğü şey | İyi | Geliştirilmeli | Kötü |
| LCP (Largest Contentful Paint) | En büyük görünür içeriğin ekrana gelme süresi | ≤ 2,5 sn | 2,5 – 4,0 sn | > 4,0 sn |
| INP (Interaction to Next Paint) | Etkileşimden sonra ekranın güncellenme gecikmesi | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Sayfa yüklenirken içeriğin kayma miktarı | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Artık INP, Mart 2024’te FID’in (First Input Delay) yerini aldı. Bununla birlikte hâlâ FID’den bahseden bir rehber okuyorsanız, o içerik güncelliğini yitirmiştir. Ayrıca, aradaki fark önemli: FID yalnızca ilk etkileşimi ölçer; INP tüm etkileşimleri değerlendirir. Yani filtre butonlarınız, açılır menüleriniz ve form doğrulamalarınız artık ölçüme dahil.
Google Core Web Vitals’ı nasıl puanlıyor?
Google, Chrome User Experience Report (CrUX) veri setindeki 75. yüzdelik değeri, 28 günlük kayan pencere üzerinden değerlendirir. Dolayısıyla bu ifadelerin her biri pratikte bir sonuç doğurur.
75. yüzdelik demek, ortalamanın işe yaramaması demek. Örneğin, Ziyaretçilerinizin ’ü sayfayı 2 saniyede açsa, ’sı 5 saniyede açsa, LCP’niz başarısızdır. Google medyanı değil, yavaş kuyruğu ölçer. Bununla birlikte, optimizasyon yaparken hedefiniz “ortalamayı düşürmek” değil, “en yavaş dörtte biri kurtarmak” olmalı.
28 günlük pencere sabır gerektirir. Yaptığınız bir düzeltme rapora yaklaşık dört hafta sonra tam olarak yansır. Genellikle ilk değişikliği 7-10 gün içinde gözlemlersiniz; ancak nihai kararı 28 gün geçmeden vermemelisiniz.
Üç metriğin de geçmesi gerekir. Ancak INP sarıysa, sayfa genel değerlendirmede başarısızdır. Dolayısıyla, kısmi puan yoktur; en zayıf halka notu belirler.
Mobil ve masaüstü ayrı ölçülür. Neredeyse her sitede mobil daha zorlu barajdır, çünkü CrUX verisi orta segment Android cihazlardan ve değişken şebeke koşullarından gelir. Ancak masaüstünde yeşil olmak sizi kurtarmaz.
Yeterli trafik yoksa gruplama devreye girer. URL bazında anlamlı veri yoksa Google, URL grubu veya origin (site geneli) verisine düşer. Bu yüzden Core Web Vitals bir “sayfa tamiri” değil, şablon tamiri işidir. Buna göre, ortak header’ınızdaki tek bir ağır script, yüzlerce URL’yi birden kırmızıda tutabilir.
Dolaşımdaki iki yanlış bilgi
Ayrıca, LCP eşiğinin 2,5 saniyeden 2,0 saniyeye indirildiği ve ‘Visual Stability Index’ adında yeni bir metriğin geldiği yazılıyor. İkisi de doğru değil. Google’ın resmî dokümantasyonu olan web.dev’de LCP eşiği 2,5 saniye olarak durmaya devam ediyor ve kararlı metrik seti hâlâ LCP, INP ve CLS’ten ibaret. Google metrik değişikliklerini önceden duyurulan bir takvimle yapar; sessiz sedasız eşik düşürmez.
LCP nasıl iyileştirilir?
LCP, görüntü alanındaki en büyük içerik öğesinin (genellikle hero görseli, video posteri veya büyük bir metin bloğu) ekrana gelme süresidir. Düzeltmeye başlamadan önce bu öğenin hangi eleman olduğunu tespit edin — PageSpeed Insights bunu doğrudan gösterir. Ayrıca, yanlış elemanı optimize etmek en sık kaybedilen zamandır.
LCP dört alt bileşenden oluşur ve düzeltme sırası bu bileşenlere göre belirlenmelidir:
| Alt bileşen | Ne demek | Tipik çözüm |
| TTFB | Sunucunun ilk baytı gönderme süresi | Önbellekleme, daha iyi hosting, CDN |
| Kaynak yükleme gecikmesi | Tarayıcının kaynağı keşfetme gecikmesi | preload, fetchpriority |
| Kaynak yükleme süresi | Dosyanın indirilme süresi | AVIF/WebP, boyut küçültme |
| Eleman render gecikmesi | İndirildikten sonra çizilme gecikmesi | Kritik CSS, render-blocking JS temizliği |
Uygulanabilir düzeltmeler
LCP görselinde loading=”lazy” kullanmayın. Pek çok kişi bu hatayı yapıyor ve sonuçta sayfanın en önemli görselinin yüklenmesi gecikiyor. Tembel yükleme yalnızca ekranın altında kalan görseller için uygundur; hero görseline uygulanırsa LCP değerini doğrudan artırır.
<!-- Yanlış --><img src="/hero.avif" loading="lazy" alt="..."><!-- Doğru --><img src="/hero.avif" fetchpriority="high" width="1200" height="630" alt="...">
Kritik kaynakları önceden bildirin. Tarayıcı önce HTML’yi ayrıştırır, ardından CSS’i indirir ve ancak bundan sonra arka plan görselini keşfeder. Bu süreç gereksiz yere zaman kaybettirir.
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high"><link rel="preload" as="font" type="font/woff2" href="/inter.woff2" crossorigin>
Modern görsel formatlarına geçin. Aynı görselin AVIF sürümü, JPEG’e kıyasla tipik olarak %40-50 daha küçüktür. WordPress kullanıyorsanız dönüştürmeyi eklenti seviyesinde değil, mümkünse sunucu veya CDN seviyesinde yapın.
Render-blocking kaynakları azaltın. Ekranın üstünü çizmek için gereken CSS’i satır içine alın, kalanını ertelemeli yükleyin. Üçüncü taraf scriptlerini (<head> içindeki chat widget’ları, ısı haritası araçları, A/B test kütüphaneleri) defer ile taşıyın veya kaldırın.
TTFB’yi 200 ms altına indirin. Sunucu yavaş yanıt verirse, diğer tüm optimizasyonlar bu gecikmenin üstüne eklenir. Bu nedenle, teknik altyapınızı iyileştirmeniz ve gerekirse hosting ya da önbellek katmanını değiştirmeniz gerekir.
INP nasıl iyileştirilir?
INP, kullanıcı bir butona tıkladığında ekranın güncellenmesine kadar geçen süredir. Yavaş INP’nin tek sebebi vardır: ana iş parçacığı meşguldür. JavaScript uzun bir görevi işlerken tarayıcı hiçbir şey çizemez, kullanıcı da donma hissi yaşar.
INP’nin üç alt bileşeni:
- Giriş gecikmesi: Etkileşim başladığında ana iş parçacığı zaten meşguldü.
- İşleme süresi: Olay dinleyicinizin kodu çalışıyor.
- Sunum gecikmesi: Kod bitti ama tarayıcı henüz yeni kareyi çizmedi.
Uygulanabilir düzeltmeler
Uzun görevleri bölün. 50 milisaniyeyi aşan her görev, potansiyel bir INP sorunudur. Kritik olan işi hemen yapın, gerisini tarayıcıya nefes aldırarak devam ettirin:
button.addEventListener('click', async () => { updateUI(); // Kullanıcının gördüğü kısım: önce bu await yieldToMain(); // Tarayıcıya kareyi çizme fırsatı ver sendAnalytics(); // Kritik olmayan iş: sonra bu recalculateFilters();});function yieldToMain() { if (globalThis.scheduler?.yield) return scheduler.yield(); return new Promise(resolve => setTimeout(resolve, 0));} Üçüncü taraf scriptlerini denetleyin. INP’yi bozan şey çoğu zaman sizin kodunuz değildir. Canlı destek widget’ları, pop-up eklentileri, çerez izin yöneticileri ve etiket yöneticisi üzerinden yüklenen izleme kodları, ana iş parçacığını sizin kontrolünüz dışında bloke eder. Chrome DevTools’un Performance sekmesinde uzun görevlerin kaynağını görebilirsiniz — sonuç genellikle şaşırtıcıdır.
DOM boyutunu küçültün. 1500 düğümü aşan sayfalarda her stil yeniden hesaplaması pahalıya mal olur. Sayfa oluşturucu (page builder) eklentileriyle kurulmuş WordPress sitelerinde bu sayı rutin olarak 3000’i aşar.
Görünmeyen içeriği ertelemeli çizin. Ekranın çok altındaki bölümler için content-visibility: auto kullanmak, ilk render maliyetini belirgin biçimde düşürür.
CLS nasıl iyileştirilir?
CLS, sayfa yüklenirken içeriğin ne kadar zıpladığını ölçer. Kullanıcı bir linke tıklamak üzereyken üstte reklam yüklenip her şeyi aşağı ittiğinde yaşanan şey budur. İyi haber: üç metrik içinde düzeltmesi en kolay olanıdır ve çözümü neredeyse tamamen “alanı önceden ayır” prensibine dayanır.
Her medya öğesine boyut verin. Görsel, video, iframe ve reklam alanları istisnasız width ve height özniteliklerine ya da CSS aspect-ratio değerine sahip olmalıdır.
.hero-image { aspect-ratio: 16 / 9; width: 100%; height: auto;}.ad-slot { min-height: 250px; /* Reklam gelmese bile alan korunur */} Yazı tipi kaymalarını yönetin. Web fontu yüklenene kadar yedek font kullanılır; iki fontun metrikleri farklıysa metin yerleşimi kayar. font-display: swap ile birlikte size-adjust ve ascent-override kullanarak yedek fontu web fontuna metrik olarak yaklaştırın.
İçeriği yukarıdan enjekte etmeyin. Duyuru çubukları, çerez bildirimleri ve kampanya banner’ları mevcut içeriğin üstüne itilerek eklendiğinde CLS’yi tek başına eşiğin üzerine çıkarabilir. Bunları ya sabit konumlandırın ya da yerlerini baştan rezerve edin.
Animasyonlarda transform kullanın. top, left, width, height değerlerini animasyonlamak yerleşimi yeniden hesaplatır ve kayma üretir. transform: translate() ve opacity ise üretmez.
Hangi araçla ölçülür?
En sık karşılaşılan kafa karışıklığı şudur: Lighthouse’ta 100 puan aldınız ama Search Console kırmızı gösteriyor. Sebebi basit — bu ikisi aynı şeyi ölçmüyor.
| Araç | Veri tipi | Ne için kullanılır |
| Search Console → Core Web Vitals | Saha (CrUX) | Google’ın sizi nasıl gördüğünü öğrenmek |
| PageSpeed Insights | Saha + laboratuvar | Tek URL için hem gerçek hem test verisi |
| CrUX Dashboard (Looker Studio) | Saha | Aylık trend takibi, rakip karşılaştırması |
| Chrome DevTools → Performance | Laboratuvar | Sorunun kök nedenini bulmak |
| web-vitals JS kütüphanesi | Saha (kendi verisi) | Kendi kullanıcılarınızdan canlı ölçüm |
| Lighthouse | Laboratuvar | Regresyon testi, CI/CD kontrolü |
Doğru iş akışı şudur: teşhisi Search Console’da koyun, kök nedeni DevTools’ta bulun, düzeltmeyi şablon seviyesinde uygulayın, doğrulamayı 28 gün sonra yine Search Console’da yapın. Laboratuvar araçları neyin bozuk olduğunu söyler; hangi sayfanın gerçekten sorunlu olduğunu yalnızca saha verisi söyler.
WordPress’te Core Web Vitals nasıl düzeltilir?
WordPress sitelerinde Core Web Vitals sorunlarının büyük çoğunluğu üç kaynaktan gelir ve hiçbirinin çözümü “yeni bir eklenti kurmak” değildir.
Tema ve sayfa oluşturucu yükü. Çok amaçlı temalar, kullanmadığınız onlarca bileşenin CSS ve JavaScript’ini de yükler. Elementor, WPBakery gibi sayfa oluşturucular DOM boyutunu iki-üç katına çıkarır. Bu, doğrudan INP maliyetidir.
Eklenti birikmesi. Her eklenti kendi CSS ve JS dosyasını her sayfaya ekler — iletişim formu eklentisi ana sayfada da yüklenir. Asset yönetimiyle eklenti kaynaklarını yalnızca gerekli sayfalarda çalıştırmak, tek başına ölçülebilir kazanç sağlar.
Önbellek ve sunucu. PHP her istekte sayfayı yeniden üretiyorsa TTFB yükselir. Sayfa önbelleği, nesne önbelleği ve OPcache’in üçü birden aktif olmalıdır.
Performans sorunlarının kaynağı çoğu zaman tema ve altyapı seçimlerinde yattığı için, kalıcı çözüm genellikle eklenti eklemek değil web tasarım katmanını yeniden ele almaktır. Yazı içeriğinizin okunabilirliğini de aynı anda gözden geçirmek isterseniz okunabilirlik indeksi aracımızı kullanabilirsiniz.
En sık yapılan 6 hata
- Tek URL’yi düzeltip bitti sanmak. Sorun şablonda olduğu için aynı şablonu kullanan tüm sayfalar kırmızıda kalır.
- Zaten yeşil olan metriği optimize etmek. Kaynağınızı kırmızı bandaki metriğe ayırın; yeşilden daha yeşil olmanın karşılığı yoktur.
- Laboratuvar puanına güvenmek. Lighthouse’taki 98, orta segment bir Android cihazdaki gerçek deneyimi temsil etmez.
- Düzeltmeden birkaç gün sonra sonuç beklemek. 28 günlük kayan pencere dolmadan yorum yapmak, yanlışlıkla işe yarayan bir düzeltmeyi geri almaya yol açar.
- Sadece masaüstüne bakmak. Barajın zoru mobilde ve trafiğinizin çoğu da orada.
- Core Web Vitals’ı sıralamanın tek anahtarı sanmak. Bu metrikler bir sayfa deneyimi sinyalidir; içerik kalitesinin ve konu otoritesinin yerini almaz. İçerik tarafında ne yapmanız gerektiğini semantic SEO ve blog yazıları rehberimizde anlattık.
Sık sorulan sorular
Core Web Vitals bir sıralama faktörü mü?
Evet. Core Web Vitals, Google’ın sayfa deneyimi sinyalleri kapsamında sıralama sistemleri tarafından kullanılır. Ancak tek başına belirleyici değildir; içerik alaka düzeyi ve otorite daha ağır basar. Eşit güçteki iki sayfa arasında farkı yaratan unsur olarak düşünün.
LCP eşiği 2 saniyeye mi düştü?
Hayır. LCP’nin “iyi” eşiği 2,5 saniye olarak devam ediyor. Aksini söyleyen kaynaklar doğrulanmamış bilgi yayıyor.
FID hâlâ ölçülüyor mu?
Hayır. FID, Mart 2024’te Core Web Vitals setinden çıkarıldı ve yerini INP aldı.
Core Web Vitals düzeltmesi ne kadar sürede sonuç verir?
Search Console’daki rapora tam yansıması 28 gün alır. İlk hareketi 7-10 gün içinde gözlemleyebilirsiniz. Sıralama etkisi ise daha uzun ve dolaylıdır.
Trafiği az bir sitede Core Web Vitals ölçülür mü?
CrUX’ta URL bazında anlamlı veri oluşması için belirli bir ziyaret hacmi gerekir. Yeterli veri yoksa Google URL grubu veya site geneli verisini kullanır. Bu durumda PageSpeed Insights’ın laboratuvar verisi ve web-vitals kütüphanesiyle kendi ölçümünüzü kurmak daha sağlıklıdır.
Hangi metriği önce düzeltmeliyim?
Kırmızı banttaki metriği. Hepsi sarıysa, ticari değeri en yüksek sayfalarınızda hangi metrik başarısızsa ondan başlayın.
Eklenti kurarak Core Web Vitals düzelir mi?
Kısmen. Önbellekleme ve görsel optimizasyonu eklentileri LCP’ye yardımcı olur. Ancak INP sorunları genellikle eklentilerin kendisinden kaynaklanır; çözüm yeni bir eklenti eklemek değil, mevcut yükü azaltmaktır.
Core Web Vitals, bir puan avı değil mühendislik disiplinidir: daha az JavaScript göndermek, alanı önceden ayırmak ve kullanıcının ilk gördüğü şeye öncelik vermek. Sitenizin hangi şablonlarının bu üç eşiği kaçırdığını ve kök nedenin ne olduğunu tespit edilmesini istiyorsanız, teknik SEO denetimi hizmetimiz üzerinden iletişime geçebilirsiniz.
Related Posts
En İyi Sıra Bulucu Araçları
mertcanugurluel SEO ve İçerik
mertcanugurluel 