CoreWebVitalsNedir?WebSitesiHızınızSEO'yuNasılEtkiler

Core Web Vitals üç metrikten oluşur: LCP, INP ve CLS. Google bunları kendi lab testiyle değil, gerçek Chrome kullanıcılarının verisiyle ölçüyor — bu veri setine Chrome Kullanıcı Deneyimi Raporu (CrUX) deniyor. Bir sitenin bir metriği 'geçmesi' için ziyaretlerin en az %75'inin iyi eşiğin altında kalması gerekiyor; bu hesap 28 günlük hareketli bir pencerede yapılıyor. Yani tek seferlik bir hız testi sitenizin gerçek skorunu göstermez — Google aylarca biriken gerçek ziyaretçi deneyimine bakıyor.

Resmi eşikler şöyle: LCP için 2,5 saniyenin altı iyi, INP için 200 milisaniyenin altı iyi, CLS için 0,1'in altı iyi kabul ediliyor. İnternette bu eşiklerin 2026'da değiştiğine dair iddialar dolaşıyor; biz bu yazıda sadece Google'ın kendi web.dev sayfalarındaki (Eylül 2025 güncel) resmi rakamları kullanıyoruz, doğrulanamayan iddiaları değil.

INP (Interaction to Next Paint), 12 Mart 2024'te FID'in (First Input Delay) yerini tamamen aldı. FID sadece sayfadaki ilk tıklamayı ölçüyordu; INP ise ziyaretçinin sayfada yaptığı her tıklama, dokunma ve tuş basımını izliyor, en kötü gecikmeyi raporluyor. Bir ziyaretçi rezervasyon formunuzun 5. alanına tıkladığında sayfa yavaş tepki veriyorsa bu artık ölçülüyor — eskiden sadece ilk tıklama sayıldığı için bu tür kusurlar gizlenebiliyordu.

Teknik neden basit: tarayıcının ana iş parçacığı aynı anda tek bir işi yürütebiliyor. 50 milisaniyeden uzun süren herhangi bir JavaScript görevi 'uzun görev' sayılıyor ve o sırada gelen bir tıklama kuyrukta bekliyor. Google'ın önerisi bu görevleri küçük parçalara bölmek. DebugBear'ın bir vaka analizinde, ziyaretçi bir form alanına yazmaya başladığı anda devreye giren bir canlı destek widget'ı klavye etkileşimlerini bloke etmiş; Lighthouse bunu 390 milisaniyelik bir gecikme olarak ölçmüş — rezervasyon veya iletişim formu olan her site için tanıdık bir risk.

Search Engine Journal'ın Haziran 2025'te 8 milyondan fazla siteyi taradığı bir analiz, hazır platformlar arasında net bir sıralama ortaya koydu. Duda ve Shopify gibi kapalı/barındırılan sistemler en üstte; WordPress ise üç metriği birden geçme oranında son sırada. Nedeni yapısal: WordPress her hosting seviyesinde çalışıyor, 3 dolarlık paylaşımlı barındırmadan kurumsal sunuculara kadar. Doğru kurulduğunda tavanı en yüksek platform WordPress, ama varsayılan/optimize edilmemiş bir kurulumla en düşük geçme oranına sahip platform da o.

Son rakam özellikle önemli: PageSpeedMatters'ın Mayıs 2026'da 11 milyondan fazla siteyi incelediği çalışmada, en popüler 1.000 site mobilde %64,7 geçerken, 'kuyruktaki' — yani çoğu küçük işletme ve yerel sitenin bulunduğu — grup sadece %39,2'de kalıyor. Bodrum'daki bir otel ya da restoran sitesi büyük olasılıkla bu ikinci grupta yer alıyor.

İlk hata: kapak (hero) görsele 'lazy loading' (geciktirilmiş yükleme) uygulamak. Mantıken doğru gibi görünüyor — 'görseli sonra yükle, sayfa hızlansın' — ama tam tersi oluyor. Tarayıcı, HTML'i okurken görselleri önceden indirmeye başlayan bir mekanizma kullanıyor (preload scanner); lazy loading bu mekanizmayı devre dışı bırakıyor ve genelde LCP adayı olan en büyük görsel daha geç yükleniyor. Google'ın kendi web.dev sitesi bile bir dönem bu hataya düşmüştü.

İkinci hata, tam tersi bir çözümle giderilebiliyor: fetchpriority='high' özniteliği. Google'ın Flights uygulamasında hero görsele bu öznitelik eklendiğinde LCP 2,6 saniyeden 1,9 saniyeye düştü — 700 milisaniyelik somut bir iyileşme. Oodle uygulamasında ise carousel'in ilk görseline yüksek, ekran dışındaki diğerlerine düşük öncelik verilerek toplam sayfa yükleme süresi 2 saniye kısaldı. Tek bir HTML özniteliğinin getirdiği fark bu kadar büyük olabiliyor.

Üçüncü mesele üçüncü parti kod: rezervasyon widget'ı, canlı destek, analitik etiketleri. Web Almanac 2025 verisine göre sayfaların %90'ından fazlasında en az bir üçüncü parti kaynak var. Bu kod parçaları hem LCP'yi geciktiriyor hem ana iş parçacığını işgal ederek INP'yi kötüleştiriyor. Otel ve restoran sitelerinde sık görülen rezervasyon ve menü widget'ları bu yüzden özellikle dikkat gerektiriyor — kurulumu kolay ama performans faturası ağır olabiliyor.

• →Kapak görselinize lazy loading uygulamayın; gerekiyorsa fetchpriority='high' ekleyin.
• →Tüm görsellere width/height (veya CSS aspect-ratio) tanımlayın — CLS'nin en sık nedeni budur.
• →Rezervasyon, canlı destek ve analitik widget'larını sayfa yüklendikten sonra çalışacak şekilde geciktirin (async/defer).
• →Hazır platform kullanıyorsanız varsayılan temayı değil performans odaklı bir tema seçin; kullanmadığınız eklentiyi kaldırın.
• →PageSpeed Insights'ta sadece lab skoruna değil, gerçek kullanıcı verisine (Field Data/CrUX) bakın — 28 günlük veri asıl gerçeği gösterir.

Google, Core Web Vitals'ı 'tek bir sinyal' olarak tanımlamıyor; resmi açıklamasında sıralama sistemlerinin sayfa deneyimiyle uyumlu birçok sinyale birlikte baktığını söylüyor. Ama gözlemlenen bir örüntü var: arama sonuçlarında 1. sıradaki sayfaların Core Web Vitals eşiklerini geçme olasılığı, 9. sıradakilere göre %10 daha yüksek. Hız tek başına sıralamayı garanti etmiyor ama eşit içerikte kazandıran taraf oluyor. Sitenizin gerçek skorunu bilmiyorsanız, BodrumSocial ekibiyle konuşup birlikte bakabiliriz.