Core Web Vitals ve INP: Site hızı satışı nasıl etkiler, ne düzeltilmeli?

Site hızı çoğu zaman bir satış sloganı olarak kullanılıyor. Oysa Google’ın yayımladığı çalışmalar ve ölçüm verileri var; hangisinin ne kadar sağlam olduğunu ayırt etmek gerekiyor. Bu yazıda Google’ın resmî Core Web Vitals dokümanlarını, hız ile satış arasındaki yayımlanmış araştırmaları ve web genelinde gerçek durumu bir araya getiriyoruz. Kaynaklarda bulamadığımız her iddiayı çıkardık, bulduğumuz her sonucun sınırını da yazdık.

Core Web Vitals neyi ölçüyor?

Core Web Vitals, Google’ın bir sayfanın gerçek kullanıcı deneyimini üç noktada ölçtüğü ölçülerdir. web.dev’deki tanıma göre: Largest Contentful Paint (LCP), yani sayfanın ana içeriğinin görünme süresi, sayfa yüklenmeye başladıktan sonra en çok 2,5 saniye olmalı. Interaction to Next Paint (INP), yani tıklama, dokunma veya tuşa basmadan sonra ekranın tepki verme süresi, 200 milisaniye veya altında olmalı. Cumulative Layout Shift (CLS), yani sayfadaki beklenmedik kaymalar, 0,1 veya altında olmalı.

Değerlendirme ortalamayla değil, sayfa yüklemelerinin 75. yüzdeliğiyle yapılıyor ve mobil ile masaüstü ayrı ayrı bakılıyor. Bir sayfa, üç ölçüde de hedefi tutturursa geçmiş sayılıyor. Yani ziyaretlerin dörtte birinden fazlası eşiği aşıyorsa, sayfa geçemiyor.

INP: FID’in yerini alan ölçü

INP, Mart 2024’te First Input Delay (FID) yerine geçerek resmen Core Web Vital oldu. INP yalnızca açılışa değil, ziyaretin tamamına bakıyor: tıklama, dokunma ve tuş vuruşlarındaki gecikmeler izleniyor ve raporlanan değer, aykırı değerler hariç, gözlenen en uzun etkileşim oluyor. Her etkileşim üç parçadan oluşuyor: giriş gecikmesi (olay işleyicilerinin başlamasına kadar geçen süre), işleme süresi ve sunum gecikmesi (bir sonraki karenin çizilmesine kadar geçen süre). Yani sepete ekle düğmesine bastıktan sonra ekran 500 milisaniye donuyorsa, açılış hızlı olsa bile INP puanınız zayıflar.

Ölçü farkı: Lighthouse gibi laboratuvar testleri kontrollü bir cihaz ve ağ ile çalışır; web.dev, önceliklendirme için gerçek kullanıcı verisini (saha verisi, CrUX) esas almanızı söylüyor. PageSpeed Insights ikisini de gösterir. Laboratuvar puanınız yüksek olsa bile saha verisi başarısız olabilir.

Hız ile satış arasındaki ilişki: ne kadar sağlam?

En çok alıntılanan çalışma, Google’ın yaptırdığı ve 55 ile Deloitte’un yürüttüğü Milliseconds Make Millions raporu. Avrupa ve Amerika’dan 37 önde gelen marka sitesinde, 30 milyondan fazla kullanıcı oturumu 2019 sonunda 30 gün boyunca saat saat izlendi. Dört mobil hız ölçüsü 0,1 saniye iyileştiğinde perakende sitelerinde dönüşüm oranı yüzde 8,4, harcama tutarı yüzde 9,2 arttı. Bu dört ölçü Core Web Vitals değil: ilk anlamlı boyama, tahmini giriş gecikmesi, gözlenen yükleme süresi ve sunucu gecikmesiydi. Raporun kendisi ilk anlamlı boyamanın artık kullanımdan kalktığını, yerine LCP’nin önerildiğini söylüyor.

Core Web Vitals’a doğrudan bağlı örnekler ise web.dev’in vaka çalışmalarında. İtalya’da Vodafone, LCP’sini yüzde 31 iyileştirdi ve satışlarda yüzde 8 artış bildirdi. Aynı sayfa 19 vaka listeliyor; çoğunda örneklem büyüklüğü, süre veya yöntem verilmiyor. Bazı rakamlar yalnızca görsel altyazısında geçiyor ve bir vakada sonuç ‘diğer ürün değişiklikleriyle birlikte’ elde edilmiş.

Bunlar içinde en kontrollü olanı Rakuten 24. Bir yoğun trafikli açılış sayfasını optimize edip özgün sürümle bir ay boyunca yüzde 50-yüzde 50 trafik bölerek karşılaştırdılar; yazıya göre iki sürüm arasında başka işlevsel ya da görsel fark yoktu. Optimize sürümde ziyaretçi başına gelir yüzde 53,37, dönüşüm oranı yüzde 33,13, ortalama sipariş tutarı yüzde 15,20 arttı; çıkış oranı yüzde 35,12 düştü. Şaşırtıcı ayrıntı: bu sonuç, mobil yük testinde yalnızca 0,4 saniye daha erken yüklenen bir sürümden geldi. Sınırlar da net: tek bir sayfa, kendi bildirimi, örneklem büyüklüğü ve anlamlılık düzeyi paylaşılmamış.

Renault ise farklı bir yöntem kullandı: 33 ülkede, Aralık 2020 ile Mart 2021 arasında 10 milyondan fazla ziyaretin LCP’sini iş ölçüleriyle karşılaştırdı. Doğrusal regresyona göre LCP’de 1 saniyelik iyileşme, hemen çıkma oranında 14 puan düşüş ve dönüşümlerde yüzde 13 artışla ilişkili. Yazı bunun ilişkilendirme olduğunu, nedensellik kanıtı olmadığını söylüyor. Yine de çalışma tek başına bir ders içeriyor: fark, sürenin 1,6 saniyenin altına inmesiyle daha belirgin hale geliyor.

Bu çalışmaların ortak mesajı net ama bir sınır var: oranlar sektöre, trafiğe ve başlangıç hızına göre çok değişir. Başka bir şirketin yüzde 8’i sizin vaadiniz değil. Google’ın kendi arama dokümanı da iyi Core Web Vitals’ı ‘Arama’da başarı için’ şiddetle tavsiye ediyor ve ölçülerin çekirdek sıralama sistemlerinin ödüllendirmek istediği şeyle örtüştüğünü söylüyor; ancak hedefi tutturmanın sıralama getireceği vaadi sayfada yok.

Webin genelinde gerçek tablo (HTTP Archive 2025)

HTTP Archive’ın 2025 Web Almanac performans bölümü, Temmuz 2025 ölçümlerine dayanıyor. Sonuç: iyi Core Web Vitals’a sahip web sitelerinin oranı mobilde yüzde 48 (2024’te yüzde 44), masaüstünde yüzde 56. Yani mobilde sitelerin yarıdan fazlası hâlâ en az bir ölçüde geride.

İlginç olan INP ayrımı. Masaüstünde iyi INP oranı yüzde 97 iken telefonlarda yüzde 77. Yani yavaş etkileşim sorunu neredeyse tamamen mobil bir sorun. LCP’de de benzer fark var: iyi oran masaüstünde yüzde 74, mobilde yüzde 62. Siteyi yalnızca masaüstünde test etmek, sorunları gözden kaçırmanıza yol açar.

Almanac’ın en dikkat çekici bulgusu kendi kendine yaratılan bir sorun. Mobil sayfaların yüzde 76’sında LCP öğesi bir görsel; buna rağmen sayfaların yaklaşık yüzde 16 ila 17’si LCP görselini tembel yüklüyor (lazy load). web.dev ise bunun tersini söylüyor: LCP görselini asla tembel yüklemeyin. Yine de mobil sayfaların yalnızca yaklaşık yüzde 17’si bu görselde fetchpriority yüksek ayarını kullanıyor. Bunlar küçük kod değişiklikleri; bu veriler dünya geneli, Türkiye kırılımını bulamadık.

KOBİ sitesi için uygulanabilir düzeltmeler

LCP: ana görseli ve sunucuyu düzeltin

• web.dev’in kılavuzuna göre LCP süresinin yaklaşık yüzde 40’ı ilk bayt süresi, yaklaşık yüzde 40’ı kaynağın indirilme süresi olmalı; kaynak yükleme gecikmesi ve öğenin çizilme gecikmesi yüzde 10’un altında kalmalı. Yani iki gecikme sıfıra yakın olmalı.
• Ana görsel gibi LCP olması muhtemel görselde fetchpriority yüksek kullanın, ancak bunu bir ya da iki görselden fazlasında yapmayın.
• Ana görseli asla tembel yüklemeyin. Görsel yalnızca CSS ya da JavaScript içinden çağrılıyorsa HTML’de önceden yükleme (preload) ekleyin.
• Mümkünse görselleri bir CDN, tercihen görsel CDN’i üzerinden sunun.

CLS: boşlukları önceden ayırın

web.dev, CLS’nin yaygın nedenleri olarak boyutu belirtilmemiş görselleri ve videoları, yedek fontla farklı boyutta çizilen yazı tiplerini, sonradan boyutu değişen üçüncü taraf reklam ve araçlarını, mevcut içeriğin üstüne eklenen içeriği sayıyor. web.dev, kullanıcı eylemiyle yavaş yüklenen içerikte yer ayırıp yükleme göstergesi kullanmayı ve animasyonlarda yükseklik ya da genişlik değiştirmek yerine transform tercih etmeyi öneriyor. Görsel ve video boyutlarını tanımlamak ile reklam ve widget alanlarına yer ayırmak, sayılan nedenlerin doğal karşılığıdır; ayrıntılar web.dev’in ayrı CLS kılavuzunda.

INP: ana iş parçacığını rahatlatın

• Uzun görevleri bölün; kullanıcı arayüzünü güncelleyen koddan hemen sonra ana iş parçacığına söz hakkı verin, böylece ekran daha erken çizilebilir.
• Açılışta çalışan komut dosyalarını azaltın; web.dev bunların ayrıştırma, derleme ve çalıştırma süresinin girişi geciktirebileceğini belirtiyor.
• DOM boyutunu küçültün: çizim işi DOM büyüdükçe artıyor. Çok büyük HTML bloklarını JavaScript ile istemcide üretmekten kaçının.
• Stil okuyup hemen ardından değiştirerek zorunlu düzen hesaplatan kod kalıplarından kaçının (layout thrashing).

Renault vaka çalışması, büyük bir sitenin neler yaptığını gösteriyor: sunucu tarafı oluşturma, kod bölme, güçlü önbellekli bir CDN, Brotli sıkıştırma, HTTP/2, duyarlı WebP görseller, tembel yükleme (ana görsel dışında), font-display swap, daha az web fontu, ana görseli önceden yükleme ve daha küçük bir Google Tag Manager kapsayıcısı. Bu liste bir KOBİ için de kontrol listesi olarak okunabilir: gereksiz font, etiket ve ağır görselleri ayıklayın.

Ne yapmalı? Beş adımlık sıra

1. PageSpeed Insights’ta sitenizi mobil için çalıştırın ve önce saha verisi bölümüne bakın. Saha verisi görünmüyorsa laboratuvar sonucunu yalnızca yön göstermek için kullanın.
2. Google Search Console’daki Core Web Vitals raporunu açın ve hangi ölçünün başarısız olduğunu görün: LCP, INP veya CLS.
3. Tek bir ölçüye odaklanın. Çoğu sitede ilk hamle ana görselin tembel yüklenmemesi, görsel boyutları ve gereksiz komut dosyalarının temizlenmesi olur.
4. Her değişiklikten önce ve sonra ölçün; mümkünse tek bir yüksek trafikli sayfada A/B testi yapın. Rakuten 24 etkisini bu yöntemle ölçtü.
5. Skoru amaç yapmayın: Lighthouse’ta yüksek puan, saha verisinde başarı demek değil. Hedef; ziyaretçinin sepeti ve formu sorunsuz kullanması.

Kaynaklar

Aşağıdaki bağlantılar yazıdaki rakam ve iddiaların dayandığı kaynaklardır; yazı 28 Ekim 2026 itibarıyla hazırlanmıştır. Resmî düzenlemeler ve platform politikaları değişebilir; karar vermeden önce güncel hâlini kaynağından kontrol edin.

1. web.dev: Web Vitals ve eşikler
2. web.dev: Interaction to Next Paint (INP)
3. web.dev: INP resmen Core Web Vital oldu
4. Google Search Central: Core Web Vitals ve Arama
5. web.dev: Milliseconds Make Millions (Deloitte ve 55)
6. web.dev: Core Web Vitals’ın iş etkisi vaka listesi
7. web.dev: Rakuten 24 vaka çalışması
8. web.dev: Renault LCP vaka çalışması
9. HTTP Archive Web Almanac 2025: Performans
10. web.dev: LCP’yi optimize etme
11. web.dev: INP’yi optimize etme
12. web.dev: Cumulative Layout Shift (CLS)
13. web.dev: Laboratuvar ve saha verisi farkları