Kazım Gökay Çiftci · 6 Ekim 2026 · Güncelleme: 14 Ekim 2026

Web Sitesi Hızı E-Ticaret Dönüşümünü Nasıl Etkiler? Core Web Vitals Ölçüm ve İyileştirme Rehberi

Rakuten 24'ün Google'la paylaştığı A/B testinde, Core Web Vitals odaklı yeniden düzenlenen sürüm ziyaretçi başına geliri yüzde 53,37, dönüşüm oranını yüzde 33,13 artırdı; çıkış oranı ise yüzde 35,12 düştü. Yani hız, teknik ekibin köşedeki bir gösterge paneli değil, doğrudan ciro kalemidir. Bu yazıda Core Web Vitals'ın ne ölçtüğünü, e-ticaret dönüşümüyle bağını gerçek vaka verileriyle, sonra da bir ürün, kategori ve sepet sayfasında hangi sırayla neyi düzelteceğinizi anlatıyoruz. Baştan söyleyelim: her sitenin darboğazı farklıdır, o yüzden önce ölçeceğiz, sonra dokunacağız.

Core Web Vitals neyi ölçer ve neden üç metrik?

Core Web Vitals, Google'ın gerçek kullanıcı deneyimini üç başlıkta özetlediği metrik setidir: yükleme hızı için Largest Contentful Paint (LCP), etkileşim yanıtı için Interaction to Next Paint (INP) ve görsel kararlılık için Cumulative Layout Shift (CLS). Google'ın web.dev dokümantasyonuna göre bir sayfanın iyi sayılması için bu metriklerin 75. yüzdelik değerinin LCP için 2,5 saniye veya altında, INP için 200 milisaniye veya altında, CLS için 0,1 veya altında olması gerekir. Ölçüm mobil ve masaüstü için ayrı yapılır.

75. yüzdelik ifadesi önemli. Ortalama değil, ziyaretlerinizin dörtte üçünün eşiği geçmesi isteniyor. Yani sitenizin sizin hızlı ofis internetinizde 1,8 saniyede açılması hiçbir şey ifade etmez; asıl soru, orta seviye bir Android telefonda, kalabalık bir mobil şebekede, kampanya reklamından gelen ziyaretçinin ne gördüğüdür. E-ticaret trafiğinin büyük bölümü mobilden geldiği için kampanya döneminde gerçek ölçüm çoğunlukla sizin test ortamınızdan daha kötü çıkar.

LCP: Sayfanın en büyük görünür öğesinin (çoğu ürün sayfasında ana ürün görseli, kategori sayfasında banner) ekrana gelme süresi.
INP: Kullanıcının tıklama, dokunma ve tuşa basma gibi etkileşimlerinden sonra sayfanın görsel olarak yanıt verme süresi. Filtre açmak, varyant seçmek, sepete ekle düğmesine basmak buraya girer.
CLS: Sayfa yüklenirken öğelerin yer değiştirmesi. Kullanıcı tam düğmeye basarken bir banner yüklenip her şeyi aşağı iterse, yanlış ürüne tıklar ya da vazgeçer.

Hız dönüşümü gerçekten nasıl etkiliyor: vakalardan gelen veriler

Rakamlar Google'ın web.dev vaka çalışmalarından. Tablo şöyle:

Rakuten 24: Optimize edilmiş sürüm, bir aylık ve trafiği yarı yarıya bölen A/B testinde ziyaretçi başına geliri yüzde 53,37, dönüşüm oranını yüzde 33,13, ortalama sipariş tutarını yüzde 15,20 artırdı. Çıkış oranı yüzde 35,12 azaldı. Gerçek kullanıcı verisi analizinde ise iyi bir LCP değerinin dönüşüm oranında yüzde 61,13'e kadar artışla ilişkili olduğu görüldü.
Vodafone (İtalya): LCP yüzde 31 iyileştirildi, satışlar yüzde 8 arttı. Sunucu tarafı render, render'ı engelleyen JavaScript'in azaltılması ve görsel optimizasyonu uygulanan yöntemler arasındaydı.
Tokopedia: LCP 3,78 saniyeden 1,72 saniyeye indi (yüzde 55 iyileşme), ortalama oturum süresi yüzde 23 arttı.
Cdiscount: Kara Cuma döneminde yüzde 6 gelir artışı raporlandı.
Nykaa: LCP'de yüzde 40 iyileşme, organik trafikte yüzde 28 artışla eşleşti.
Redbus: CLS 1,65'ten 0'a indirildi, mobil dönüşüm oranı yüzde 80 ile 100 arasında arttı.

Rakuten 24 Core Web Vitals A/B testi: optimize sürümün orijinale göre farkı

Bu rakamları okurken iki uyarı gerekli. Birincisi, bunlar seçilmiş başarı vakaları; sizin sitenizde aynı oranda kazanç garanti değil. İkincisi, çoğunda hız tek değişken değildi; tasarım ve altyapı da değişti. Ama yönün tutarlı olması dikkat çekici: farklı ülkelerde, farklı sektörlerde, hız iyileştikçe iş metrikleri de iyileşiyor.

Daha eski ama hâlâ sık alıntılanan bir çalışma Google ve SOASTA'nın mobil hız araştırması. 2016 verilerine dayanan bu çalışmada, tüketicilerin yüzde 40'ının üç saniyeden uzun süren bir sayfayı terk edeceği, hız konusunda memnun kalmayan alışverişçilerin yüzde 79'unun aynı siteden tekrar alışveriş yapma olasılığının düştüğü belirtiliyor. Çalışma, dönüşüm yapan oturumların yapmayan oturumlara göre yüzde 38 daha az görsel içerdiğini de gösteriyor. Veriler eski olduğu için rakamları bugünün birebir oranı gibi değil, yönü gösteren bir işaret olarak okumak gerekir.

Hız yalnızca dönüşüm değil, reklam verimi ve SEO meselesi

Yavaş sayfa iki kez ödeme yaptırır. Önce tıklama için reklam bütçesini harcarsınız, sonra o kullanıcı sayfa açılmadan çıkar. Performans kampanyalarında bu, gerçek dönüşüm oranından bağımsız olarak reklam getirisinin düşmesi demektir. Google Ads ve Meta hesaplarını yönettiğimiz projelerde kampanya sonuçlarını incelerken ilk baktığımız yerlerden biri bu yüzden açılış sayfasının mobil hızıdır. Performans pazarlama bütçenizi büyütmeden önce sayfanın bu yükü kaldırıp kaldırmadığını ölçmek çoğu zaman en ucuz iyileştirmedir.

SEO tarafında Google'ın Search Central dokümantasyonu, Core Web Vitals'ın çekirdek sıralama sistemlerinin ödüllendirmeye çalıştığı şeyle örtüştüğünü ve iyi değerler için çabalamayı önerdiğini söylüyor. Aynı doküman, iyi skorun tek başına üst sıra garantisi vermediğini de açıkça belirtiyor. Bu, doğru beklenti: hız, alakalı içerik ve otoritenin yerine geçmez; ama eşit kalitedeki iki sayfadan birini geride bırakan bir fark olabilir. Sadece SEO için mükemmel skor kovalamak yerine, kullanıcıyı ve dönüşümü iyileştirdiği için çalışmak daha sağlıklı bir çerçevedir.

Önce ölçün: laboratuvar verisi ile saha verisi

En sık yapılan hata, tek bir hız testi aracının skorunu hedef sanmaktır. İki tür veri var ve ikisi de gerekli:

Saha verisi (gerçek kullanıcı verisi): Chrome kullanıcılarından toplanan, sayfaların gerçek performansını yansıtan veri. Google'ın değerlendirmesi bu tür veriye dayanır. Search Console'daki Core Web Vitals raporu sitenizin sayfalarını iyi, iyileştirme gerekli ve zayıf gruplarına ayırır.
Laboratuvar verisi: Kontrollü ortamda çalıştırılan testlerin çıktısı. Sorunun nedenini bulmak için idealdir çünkü tekrarlanabilir, ama gerçek kullanıcıların çeşitliliğini yansıtmaz.

Sağlıklı yöntem şu: Search Console'da hangi sayfa grubunun (örneğin tüm ürün sayfaları) sorunlu olduğunu saha verisinden bul, sonra laboratuvar aracıyla o gruptan tek bir temsilci sayfayı ayrıştır ve nedenini incele. Rakuten ekibi de web-vitals JavaScript kütüphanesiyle gerçek kullanıcı ölçümü yapıp bir panelde takip etmişti; yani ölçümü sürekli hale getirmek, tek seferlik denetimden daha değerlidir. Bunu analitik ve ölçüm altyapısı kurarken hız metriklerini de panele eklemek olarak düşünebilirsiniz.

Ölçeceğiniz sayfa tipleri de önemli. Ana sayfa genellikle en çok özen gören sayfadır ama satışın gerçekleştiği yer değildir. En az şu üçünü ayrı ayrı izleyin: kategori (listeleme) sayfası, ürün detay sayfası ve sepet ile ödeme adımları. Her birinin darboğazı farklı çıkar.

LCP: ürün ve kategori sayfasında asıl kayıp nerede?

Web.dev, LCP süresini dört alt parçaya bölüyor: sunucudan ilk baytın gelmesi (TTFB), LCP kaynağının yüklenmeye başlamasındaki gecikme, kaynağın yüklenme süresi ve öğenin ekrana çizilme gecikmesi. Önerilen dağılım kabaca TTFB için yüzde 40, kaynak yüklenme süresi için yüzde 40, yükleme gecikmesi ve çizim gecikmesi için ayrı ayrı yüzde 10'un altıdır. Bu bölüm, hangi kalemin şişkin olduğunu görmek için çok işe yarar; çünkü çoğu ekip yalnızca görseli küçültmeye odaklanır, oysa kayıp bazen sunucuda ya da tarayıcının görseli geç keşfetmesindedir.

Sunucu yanıtı (TTFB)

Web.dev'in ifadesiyle, arka uç ilk baytı teslim etmeden ön yüzde hiçbir şey başlayamaz. Sepet ve fiyat hesaplayan ağır sorgular, önbelleksiz kategori sayfaları ve paylaşımlı, kaynağı sıkışık hosting bu aşamada zaman yer. Kategori ve ürün sayfaları için sunucu tarafı önbellek ve içerik dağıtım ağı (CDN) kullanımı çoğu zaman ilk müdahaledir. Kişiselleştirilmiş kısımları (sepet ikonu, kullanıcıya özel fiyat) sayfanın geri kalanını beklemeden sonradan yüklemek, sayfanın önbelleğe alınabilmesini sağlar.

Ana görselin keşfi

Web.dev'in en net uyarılarından biri şu: LCP görselini asla tembel yükleme (lazy loading) ile yüklemeyin, çünkü bu her zaman gereksiz bir yükleme gecikmesi yaratır. E-ticaret temalarında sayfadaki tüm görsellere toptan lazy loading uygulanması yaygın bir hatadır; ilk ekrandaki ana ürün görseli bunun dışında tutulmalıdır. Ayrıca LCP görseline fetchpriority="high" vermek ve görsel yalnızca CSS ya da JavaScript içinden çağrılıyorsa preload kullanmak, tarayıcının görseli daha erken keşfetmesini sağlar.

Görselin boyutu ve biçimi

Ürün fotoğrafları e-ticaretin özüdür, dolayısıyla tamamen küçültmek çözüm değil. Doğru yöntem, ekran boyutuna uygun ölçüler sunmak (responsive görseller), WebP gibi modern biçimlere geçmek ve mobilde masaüstü boyutunda görsel indirtmemektir. Rakuten 24 ekibi de görsel optimizasyonunda tembel yükleme ve WebP biçimini kullandı. Ürün galerisinde ilk görsel dışındakileri sonradan yüklemek, ilk yüklemeyi hafifletirken deneyimi bozmaz.

INP: filtre, varyant ve sepete ekle etkileşimleri

INP, First Input Delay'in yerini alan ve sayfadaki tüm etkileşimleri kapsayan metriktir. Web.dev, INP'yi üç aşamaya ayırır: giriş gecikmesi, işleme süresi ve sunum gecikmesi. Hedef, 75. yüzdelikte 200 milisaniye veya altıdır. E-ticarette risk taşıyan etkileşimler bellidir: kategori sayfasında filtre uygulamak, bedende veya renkte varyant seçmek, sepete ekle düğmesine basmak, mini sepeti açmak.

Bu etkileşimlerin yavaşlamasının en yaygın nedeni ana iş parçacığını (main thread) uzun süre meşgul eden JavaScript'tir. Web.dev, 50 milisaniyeyi aşan senkron işlere uzun görev diyor; bir uzun görev çalışırken tarayıcı kullanıcının dokunuşunu işleyemiyor. Pazarlama ekiplerinin eklediği izleme etiketleri, canlı destek widget'ları, popup araçları ve A/B test betikleri burada suçlu çıkar. Kontrol listesi şöyle:

Üçüncü taraf betikleri listeleyin, her birinin hangi iş hedefine hizmet ettiğini yazın ve hedefi olmayanları kaldırın.
Kritik olmayan betikleri sayfa etkileşime hazır olduktan sonra yükleyin.
Olay dinleyicilerinde yalnızca görsel güncellemeyi hemen yapın; ağır hesaplamayı parçalara bölerek ana iş parçacığına nefes aldırın (web.dev bunun için görevleri yield ederek bölmeyi öneriyor).
DOM boyutunu makul tutun; binlerce ürün kartını tek seferde çizmek sunum gecikmesini büyütür. Ekran dışı içerik için content-visibility kullanılabilir.

Web.dev'in bir uyarısı da sabır gerektirir: bir yavaş etkileşimi düzelttiğinizde bir sonraki ortaya çıkar. INP iyileştirmesi tek seferlik bir işlem değil, tekrarlayan bir döngüdür.

CLS: kaydırılan düğme, kaybolan sipariş

Layout kayması, e-ticarette hem güven hem doğrudan dönüşüm problemidir. Redbus'ta CLS'in 1,65'ten 0'a indirilmesiyle mobil dönüşüm oranının belirgin arttığını yukarıda gördük. Tipik nedenler bellidir: boyutu tanımlanmamış görseller, sonradan yüklenip içeriği iten kampanya bantları, çerez onay çubukları, geç yüklenen fontlar ve dinamik olarak eklenen yorum ya da öneri modülleri.

Çözümler basit ama disiplin ister. Görsellere genişlik ve yükseklik (ya da CSS aspect-ratio) tanımlayın; Rakuten 24 de yerleşimi sabitlemek için aspect-ratio ve min-height kullandı. Reklam, banner ve çerez çubuğu gibi sonradan gelen öğeler için yer ayırın, içeriği aşağı itmek yerine önceden ayrılmış alana yerleştirin. Yazı tipi yüklenirken oluşan kaymayı, yedek font ile asıl fontun ölçülerini yaklaştırarak azaltın.

Bir e-ticaret için öncelik sırası

Her şeye aynı anda dokunmak yerine, dönüşüme en yakın sayfadan başlayan bir sıra izleyin:

1. Reklamdan gelen açılış sayfaları: Ücretli trafiğin indiği ürün ve kategori sayfaları. Her yavaşlama doğrudan bütçe kaybıdır.
2. Ürün detay sayfası: LCP görseli, galeri ve varyant seçimi (INP).
3. Sepet ve ödeme: Form etkileşimleri, ödeme sağlayıcı betikleri, kayma. Baymard'ın araştırmasında alışverişçilerin yüzde 18'i ödeme sürecini fazla zor bulduğu için sepeti terk ediyor; bu adımda yavaşlık, zaten kırılgan olan bir yere ek yük bindirir.
4. Ana sayfa ve blog: Marka görünürlüğü açısından önemli ama satışa mesafeli.

Her iyileştirmeden sonra aynı sayfa grubunu aynı yöntemle yeniden ölçün. Saha verisi 28 günlük bir pencerede güncellendiği için etkisi hemen yansımaz; laboratuvar ölçümüyle hemen doğrulayıp saha verisinin yakalamasını bekleyin. Mümkünse Rakuten'in yaptığı gibi trafiği yarı yarıya bölen bir A/B testiyle hızın dönüşüme etkisini kendi verinizde kanıtlayın; ilerideki yatırım kararlarını bu veri kolaylaştırır.

Altyapı kararı: platform mu, özel geliştirme mi?

Bir noktadan sonra betik ve görsel temizliği yetmez, sorun mimaridir. Şişkin bir tema, gereksiz eklentiler, önbellek katmanı olmayan bir sunucu ya da tüm sayfayı tarayıcıda oluşturan ağır bir ön yüz, Core Web Vitals hedeflerini kalıcı biçimde zorlaştırır. Vodafone örneğinde sunucu tarafı render ve render'ı engelleyen JavaScript'in azaltılması sonuç verdi. Sıfırdan bir e-ticaret sitesi kurulumu ya da mevcut sitenin yeniden yapılandırılması planlanıyorsa, performans bütçesini tasarım aşamasında belirlemek, sonradan yama yapmaktan çok daha ucuzdur: sayfa başına izin verilen görsel ağırlığı, betik sayısını ve LCP hedefini baştan yazın.

Upjen olarak e-ticaret projelerinde sık gördüğümüz tablo şu: hız sorunu tek bir büyük hata değil, yıllar içinde biriken küçük eklerin toplamıdır. Bu yüzden yeni bir betik, eklenti ya da banner eklenmeden önce hız etkisini ölçen basit bir onay kuralı koymak, en sürdürülebilir çözümdür.

Sık Sorulan Sorular

Core Web Vitals doğrudan Google sıralamasını etkiler mi?

Google'ın Search Central dokümantasyonu, Core Web Vitals'ın çekirdek sıralama sistemlerinin ödüllendirmeye çalıştığı şeyle uyumlu olduğunu belirtir ve iyi değerler için çabalamayı önerir. Aynı doküman, iyi skorun üst sıra garantisi vermediğini de söyler. Yani bir sıralama faktörü olarak görün ama tek başına belirleyici sanmayın; dönüşüm tarafındaki kazanç çoğu e-ticaret için asıl gerekçedir.

Hız testi aracımda yüksek skor alıyorum ama Search Console'da sorun görünüyor, neden?

Laboratuvar testi tek bir cihaz ve ağ koşulunda çalışır; Search Console ise gerçek kullanıcıların ölçümlerini 75. yüzdelik üzerinden gösterir. Gerçek kullanıcılar daha yavaş cihaz ve şebekelerde olabilir, ayrıca giriş yapmış kullanıcılar, kampanya trafiği ve farklı sayfa tipleri testte görünmez. Saha verisi belirleyici kabul edilmeli, laboratuvar verisi nedeni bulmak için kullanılmalıdır.

Küçük bir mağaza için hız optimizasyonu değer mi?

Reklam harcaması yapan her mağaza için değer. Ziyaretçi sayısı düşükse kazancın mutlak tutarı da küçük olur, ama reklamla getirdiğiniz her ziyaretçinin yavaş sayfada kaybolması oranı sabit tutar. Önce en çok trafik alan ürün ve kategori sayfalarında, en az maliyetli işlerle (görsel boyutu, tembel yükleme hatası, gereksiz betikler) başlamak makul bir ilk adımdır.

Hangi metriği önce düzeltmeliyim?

Search Console raporunda hangisi zayıf ya da iyileştirme gerekli görünüyorsa ondan başlayın. Belirli bir işaret yoksa e-ticarette çoğu zaman LCP en görünür kayıptır, çünkü ürün görseli sayfanın en önemli öğesidir; onu INP ve CLS takip eder.

Sonuç

Core Web Vitals'ı bir SEO kontrol kutusu olarak değil, dönüşüm hunisinin en üstündeki sızıntı olarak düşünün. Rakuten 24, Vodafone, Tokopedia gibi örnekler hızın satışa çevrilebildiğini gösteriyor; ama size düşen iş, kendi sitenizde nerede kayıp olduğunu saha verisiyle bulmak. LCP için sunucu yanıtını ve ana görselin keşfini, INP için üçüncü taraf betikleri ve ağır olay dinleyicilerini, CLS için yer ayrılmamış öğeleri kontrol edin. Sırayı reklam açılış sayfalarından sepete doğru izleyin, her değişikliği ölçün ve performansı bir defalık proje değil, yeni özellik eklerken sürekli işleyen bir kural haline getirin.