Core Web Vitals 2026: Web Sitenizin Hızı Neden Satış Kaybettiriyor?

Web sitenizin yavaş açılması yalnızca bir teknik ayrıntı değil; doğrudan ciroya yansıyan bir satış kaybıdır. Google'ın 2026 itibarıyla sıralama sinyali olarak kullandığı Core Web Vitals metrikleri, bir ziyaretçinin sayfanızı ne kadar hızlı gördüğünü, ne kadar çabuk etkileşime girebildiğini ve ekranın gözünün önünde ne kadar oynadığını ölçer. Bu yazıda üç temel metriği sade bir dille açıklıyor, hangi eşiklerin satış kaçırdığını ve ilk haftada nelerin düzeltilebileceğini gösteriyoruz.

Core Web Vitals tam olarak neyi ölçer?

Core Web Vitals, Google'ın gerçek kullanıcı deneyimini sayısallaştırmak için seçtiği üç metrikten oluşur. Laboratuvar testleri (Lighthouse) değil, sahadaki gerçek ziyaretçilerin verisi (CrUX) belirleyicidir. Yani test ortamında "yeşil" görünen bir site, gerçek kullanıcılarda kırmızıda olabilir.

• LCP (Largest Contentful Paint): Sayfadaki en büyük görsel veya metin bloğunun ne zaman göründüğü. Hedef: 2,5 saniyenin altı.
• INP (Interaction to Next Paint): Kullanıcı bir butona dokunduğunda arayüzün ne kadar sürede tepki verdiği. 2024'te FID'in yerini aldı. Hedef: 200 ms'nin altı.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken içeriğin ne kadar kaydığı. Yanlışlıkla yanlış butona basmanın baş nedeni. Hedef: 0,1'in altı.

Yavaşlık neden doğrudan satış kaybettirir?

Hız ile dönüşüm arasındaki ilişki sezgisel değil, ölçülmüş bir gerçektir. Sayfa açılış süresi 1 saniyeden 3 saniyeye çıktığında, ziyaretçinin siteyi terk etme olasılığı belirgin biçimde artar. 5 saniyeye ulaşıldığında terk oranı katlanır. Mobil ziyaretçide bu etki daha da serttir; çünkü mobil kullanıcı sabırsızdır ve çoğu zaman zayıf bir bağlantıdadır.

Bunu somutlaştıralım. Aylık 40.000 ziyaretçisi ve yüzde 2 dönüşümü olan bir e-ticaret sitesi düşünün. Ortalama sepet 600 TL olsun. LCP'yi 4,2 saniyeden 2,3 saniyeye indirmek terk oranını düşürür ve dönüşümü yüzde 2'den yüzde 2,4'e taşırsa, bu aylık 160 ek sipariş, yani yaklaşık 96.000 TL ek ciro demektir. Tek bir teknik iyileştirmenin getirisi, çoğu reklam bütçesinden yüksektir.

Mobil gerçeği: testiniz yalan söylüyor olabilir

Geliştiriciler siteyi güçlü bilgisayarlarında, hızlı internette test eder ve "gayet hızlı" sonucuna varır. Oysa gerçek kullanıcı, orta seviye bir Android telefonda, 4G'nin zayıf olduğu bir noktada sitenize girer. Saha verisi (CrUX) tam da bu gerçeği yansıtır. Bu yüzden kararlarınızı kendi cihazınızın hızına değil, Dijital Karne gibi saha verisini de okuyan araçlara dayandırın.

LCP'yi iyileştirmenin en etkili yolları

LCP genellikle hero görseli, büyük bir başlık ya da kapak videosudur. İlk haftada uygulanabilecek somut adımlar:

• Hero görselini önceliklendirin: En büyük görsele fetchpriority="high" verin ve <link rel="preload"> ile erkenden indirin.
• Modern format kullanın: JPEG/PNG yerine WebP veya AVIF. Çoğu durumda dosya boyutu yarıdan fazla düşer.
• Doğru boyutta sunun: 2000px genişliğinde bir görseli 400px'lik alana koymak ağır bir israftır. srcset ve sizes ile cihaza uygun boyutu gönderin.
• Sunucu yanıtını hızlandırın: TTFB yüksekse önbellek (cache), CDN ve veritabanı sorgu optimizasyonu LCP'yi doğrudan iyileştirir.
• Render'ı bloklayan kaynakları azaltın: Kritik CSS'i satır içine alın, kritik olmayan JS'i defer edin.

Bir sayfanın hissedilen hızı, ilk ekranda görünen içeriğin ne kadar erken çizildiğiyle ölçülür. Kullanıcı, footer'ın yüklenmesini beklemez; gözünün önündeki başlığın gelmesini bekler.

INP: tıklamadan sonraki o kritik 200 ms

INP, modern sitelerin en sinsi metriğidir; çünkü görsel olarak "hızlı" görünen bir site bile butona basıldığında takılabilir. Sebep neredeyse her zaman aynıdır: ana iş parçacığını (main thread) çok uzun süre meşgul eden JavaScript.

• Uzun görevleri bölün: 50 ms'den uzun süren JS işlemlerini parçalara ayırın; tarayıcının araya kullanıcı girdisini alabileceği boşluklar bırakın.
• Gereksiz üçüncü taraf script'lerini temizleyin: Beş ayrı analitik, üç ısı haritası ve iki sohbet aracı INP'yi sessizce öldürür.
• Ağır işi geciktirin: Sayfa açılışında gerekmeyen kodu kullanıcı etkileşime girene kadar yüklemeyin.

CLS: ekranın zıplamasını durdurun

CLS, kullanıcı bir bağlantıya basmak üzereyken üstte bir reklam yüklenip içeriği aşağı itmesidir. Sinir bozucu olduğu kadar dönüşüm de kaçırır. Çözümü çoğu zaman basittir:

• Tüm <img>, <video> ve <iframe> öğelerine açık width ve height verin; tarayıcı yeri önceden ayırsın.
• Web fontlarında font-display: swap kullanın ve yazı tipi yüklenince oluşan kaymaları en aza indirin.
• Dinamik içeriği (banner, bildirim) mevcut içeriğin üstüne itecek şekilde değil, ayrılmış bir alana yerleştirin.

Saha verisi mi, laboratuvar verisi mi?

Core Web Vitals'ı doğru yorumlamanın anahtarı, iki farklı veri türünü karıştırmamaktır. Laboratuvar verisi (Lighthouse, WebPageTest) tek bir cihazda, sabit bir ağ koşulunda alınan kontrollü bir ölçümdür; hata ayıklamak için harikadır ama gerçek kullanıcıyı temsil etmez. Saha verisi (Chrome User Experience Report — CrUX) ise sitenize giren gerçek Chrome kullanıcılarından toplanan, son 28 günün gerçek deneyimidir. Google sıralamada saha verisini dikkate alır.

Pratikte bu şu demektir: Lighthouse'ta 98 puan alıp "işim bitti" demek yanıltıcıdır. Asıl bakmanız gereken yer Google Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın üst kısmındaki saha verisidir. Saha verisi yetersizse, kararlarınızı laboratuvar verisiyle yön bulup saha verisiyle doğrulayarak alın.

Çekirdek dışı ama kritik: TTFB ve FCP

Üç ana metrik dışında iki yardımcı metrik, sorunun kaynağını bulmanıza yardım eder. TTFB (Time to First Byte) sunucunuzun ilk yanıt süresidir; yüksekse barındırma, önbellek veya veritabanı sorunu var demektir ve bu doğrudan LCP'yi şişirir. FCP (First Contentful Paint) ise ilk herhangi bir içeriğin çizildiği andır. TTFB iyi ama LCP kötüyse sorun görsel/render tarafındadır; TTFB kötüyse sorun sunucu tarafındadır. Bu ayrım, hangi ekibin neye odaklanacağını netleştirir.

Performansı sessizce öldüren 5 yaygın hata

Yüzlerce sitede tekrar tekrar gördüğümüz, çoğu zaman fark edilmeyen hatalar şunlardır:

• Devasa, optimize edilmemiş hero görseli: 3-4 MB'lık bir kapak fotoğrafı tek başına mobil LCP'yi saniyelerce geciktirir. Tek bir görseli sıkıştırmak çoğu zaman en hızlı kazançtır.
• Kontrolsüz üçüncü taraf script'leri: Her yeni analitik, sohbet aracı ve piksel, ana iş parçacığına yük bindirir. Gerçekten gerekli olanları tutun, gerisini kaldırın veya geciktirin.
• Web fontu kaynaklı kayma: font-display tanımlamadan yüklenen fontlar hem metni geç gösterir hem CLS üretir.
• Boyutsuz medya: width/height verilmeyen görsel ve reklamlar, yüklendikçe içeriği aşağı iter.
• Tek dev JavaScript paketi: Her şeyi tek dosyada yüklemek, kullanıcı daha hiçbir şey yapmadan tarayıcıyı meşgul eder ve INP'yi bozar.

Mobil öncelikli düşünmek neden her şeyi değiştirir?

Google, sıralamada uzun süredir mobil öncelikli indeksleme kullanır; yani sitenizin mobil sürümü, masaüstü değil, asıl değerlendirilen sürümdür. Buna rağmen birçok ekip optimizasyonu güçlü bir bilgisayarda yapar ve mobil deneyimi ihmal eder. Oysa mobil cihaz hem daha zayıf işlemciye hem de daha değişken bir ağa sahiptir; aynı JavaScript paketi masaüstünde 0,3 saniyede çalışırken orta seviye bir telefonda 1,5 saniye sürebilir.

Pratik sonuç: optimizasyon kararlarınızı mobil senaryoya göre alın. PageSpeed Insights'ta "Mobil" sekmesini esas alın, görselleri mobil ekran boyutuna göre sunun ve mobilde gerçekten gerekmeyen ağır bileşenleri (büyük animasyonlar, otomatik oynayan videolar) koşullu yükleyin. Mobilde hızlı olan bir site, masaüstünde de neredeyse her zaman hızlıdır; tersi geçerli değildir.

INP için pratik kod stratejileri

INP'yi iyileştirmek çoğu zaman daha az kod yazmak değil, kodu daha akıllı zamanlamaktır. Birkaç somut teknik:

• Görevi parçalara bölün: Uzun bir döngüyü requestIdleCallback veya küçük zaman dilimlerine yayarak tarayıcının araya kullanıcı girdisini almasına izin verin.
• Gereksiz yeniden çizimleri azaltın: Her tuş vuruşunda tüm arayüzü yeniden hesaplayan kod, INP'nin baş düşmanıdır; değişimleri gruplayın.
• Ağır işi web worker'a taşıyın: Veri işleme gibi yoğun görevleri ana iş parçacığından çıkarın; arayüz akıcı kalsın.
• Etkileşime anında görsel geri bildirim verin: Sonuç gecikse bile butonun "basıldı" hâlini hemen gösterin; algılanan hız yükselir.

Küçük bir vaka: 4,1 saniyeden 2,2 saniyeye

Yakın zamanda çalıştığımız orta ölçekli bir hizmet sitesinin mobil LCP'si 4,1 saniyeydi ve ziyaretçilerin yalnızca yüzde 48'i "iyi" deneyim yaşıyordu. Üç adımda müdahale ettik: hero görselini AVIF'e çevirip preload ettik, üç gereksiz takip script'ini kaldırıp kalanları defer ettik, ve render'ı bloklayan harici CSS'in kritik kısmını satır içine aldık. Sonuç: dört hafta sonra saha LCP'si 2,2 saniyeye indi, "iyi" deneyim oranı yüzde 81'e çıktı. Aynı dönemde form gönderimleri ölçülebilir biçimde arttı. Tek bir kod yeniden yazımı değil; doğru üç müdahale yeterliydi.

Hangi araçlarla ölçmelisiniz?

Doğru araç seti, tahminle değil veriyle ilerlemenizi sağlar:

• PageSpeed Insights: Hem saha hem laboratuvar verisini tek ekranda gösterir; başlangıç için ideal.
• Search Console — Core Web Vitals raporu: Tüm sitenizdeki URL gruplarının saha durumunu toplu gösterir; önceliklendirme için en değerli kaynak.
• WebPageTest: Şelale (waterfall) görünümüyle hangi kaynağın neyi geciktirdiğini ayrıntılı analiz eder.
• Navdion Dijital Karne: Hız, SEO, güven ve dönüşümü tek skorda toplayıp önceliklendirilmiş bir yol haritası çıkarır.

Tek seferlik değil, sürekli bir disiplin

Core Web Vitals'ı bir kez yeşile çevirmek bitiş çizgisi değildir. Her yeni özellik, her eklenen üçüncü taraf script'i, her büyük görsel performansı yeniden bozabilir. Bu yüzden performansı bir "proje" değil, sürekli bir disiplin olarak kurgulayın. Pratik bir yaklaşım, performans bütçeleri belirlemektir: örneğin "ana sayfanın toplam JavaScript boyutu şu sınırı aşmayacak" ya da "hiçbir görsel şu boyutu geçmeyecek" gibi net kurallar koyun. Yeni bir geliştirme bu bütçeyi zorluyorsa, daha canlıya çıkmadan fark edilir.

Düzenli olarak Search Console'un Core Web Vitals raporuna bakın, ayda bir saha verinizi gözden geçirin ve büyük bir yayın öncesi mutlaka mobil performans testi yapın. Bu küçük alışkanlıklar, sitenizin zamanla yavaşça bozulmasını — yani çoğu sitenin sessizce yaşadığı "performans çürümesini" — önler ve kazandığınız hızı kalıcı kılar.

Nereden başlamalı?

Her şeyi aynı anda düzeltmeye çalışmayın. Önce ölçün, en büyük kaybı bulun, oradan başlayın. Pratik bir sıra: (1) saha verinizi okuyun, (2) en kötü performans gösteren sayfa şablonunu seçin, (3) LCP'yi düzeltin, (4) CLS'i sıfırlayın, (5) INP için script diyeti yapın. Bu döngü genelde birkaç hafta içinde yeşil metriklere ulaştırır.

Sitenizin bugünkü durumunu görmek için ücretsiz Dijital Karne aracımızı çalıştırabilir; hız, SEO, güvenlik ve dönüşüm tarafındaki ilk tabloyu 60 saniyede alabilirsiniz. Daha kapsamlı bir teknik iyileştirme için web geliştirme hizmetimize göz atın. Otomasyon tarafını merak ediyorsanız yapay zekâ destekli otomasyon yazımız iyi bir devam noktasıdır.