Web Sitesi Hızının Kullanıcı Deneyimi ve Dönüşüme Etkisi

Web sitesi hızı kullanıcı deneyiminin temel parçalarından biridir. Sayfanın ana içeriğinin geç görünmesi, butonların geç tepki vermesi veya içerik yüklenirken düzenin sürekli kayması kullanıcıya yavaş ve güvensiz bir deneyim hissettirebilir.

Ancak "site hızlandı, dönüşüm kesin artar" şeklinde doğrudan bir sonuç kurulamaz. Dönüşüm aynı zamanda trafik kalitesi, teklif, fiyat, kullanıcı arayüzü ve birçok başka değişkenden etkilenir. Hız çalışması bu nedenle hem teknik metrikler hem gerçek iş sonuçlarıyla birlikte değerlendirilmelidir.

Web sitesi hızı tek bir sayı değildir

PageSpeed Insights'ta görülen tek puan bütün kullanıcı deneyimini temsil etmez.

Google'ın Core Web Vitals seti üç farklı deneyim alanına bakar:

• LCP (Largest Contentful Paint): Ana içeriğin görünme hızı
• INP (Interaction to Next Paint): Kullanıcı etkileşimlerine yanıt
• CLS (Cumulative Layout Shift): Görsel kararlılık

Google'ın güncel "iyi" eşikleri:

Metrik	İyi hedef
LCP	2,5 saniye veya daha az
INP	200 ms veya daha az
CLS	0,1 veya daha az

Google, bu eşikleri çoğu kullanıcı için değerlendirmek amacıyla sayfa yüklemelerinin 75. yüzdeliğine bakılmasını önerir. web.dev: Web Vitals

LCP kullanıcı ne zaman "sayfa geldi" hissini etkiler

LCP, görüntü alanındaki en büyük görsel veya metin bloğunun ne zaman oluşturulduğunu ölçer.

Örneğin kurumsal ana sayfada bu:

• Hero görseli
• Büyük başlık
• Video poster görseli

olabilir.

LCP sorunu yalnızca görsel sıkıştırmayla ilgili değildir. Sunucu yanıt süresi, kaynağın geç keşfedilmesi, CSS ve JavaScript gibi farklı aşamalar etkili olabilir. Google'ın LCP optimizasyon rehberi de metrik iyileştirmesinde yükleme sürecinin tamamının incelenmesi gerektiğini belirtir. web.dev: Optimize LCP

INP, kullanıcı tıkladıktan sonra ne olduğunu ölçer

Sayfa hızlı açılmış olabilir ancak menü, filtre, sepet veya form butonuna basıldığında arayüz donuyorsa kullanıcı deneyimi yine yavaştır.

INP, kullanıcı etkileşimi ile sonraki görsel güncelleme arasındaki gecikmeyi değerlendirir. Google 200 ms veya daha düşük INP değerini iyi deneyim eşiği olarak tanımlar. web.dev: INP

Özellikle ağır JavaScript kullanan sayfalarda ilk yükleme puanı iyi olsa bile etkileşim gecikmeleri görülebilir.

CLS yanlış tıklamaya bile neden olabilir

Sayfa açılırken buton, metin veya görselin konumu değişiyorsa kullanıcı yanlış alana dokunabilir.

CLS sorunlarının yaygın nedenleri arasında boyutu tanımlanmamış görseller, dinamik eklenen içerikler ve bazı font yükleme davranışları bulunur. web.dev: Optimize CLS

Özellikle:

• Sepete ekle
• Form gönder
• Menü
• Ödeme

gibi kritik alanların yükleme sırasında yer değiştirmesi dönüşüm akışını doğrudan bozabilir.

Laboratuvar verisi ile gerçek kullanıcı verisini ayırın

Lighthouse veya yerel testler sorunları teşhis etmek için değerlidir. Ancak tek cihaz ve kontrollü koşul gerçek kullanıcı kitlesinin tamamını temsil etmez.

Gerçek kullanıcı:

• Daha yavaş telefonda
• Mobil bağlantıda
• Farklı ülkede
• Önbelleksiz
• Çok sayıda tarayıcı eklentisiyle

siteyi kullanabilir.

Google da LCP rehberinde laboratuvar testlerinin teşhis için yararlı olduğunu ancak gerçek kullanıcı deneyimini tek başına tam temsil etmediğini belirtir. web.dev: Optimize LCP

Bu nedenle mümkünse PageSpeed Insights içindeki alan verisi, CrUX veya kendi RUM ölçümünüz birlikte değerlendirilmelidir.

Hız ile dönüşüm ilişkisini nasıl ölçebilirsiniz?

Google web.dev, hızlı ve duyarlı sitelerin kullanıcı tutma ve dönüşüm sonuçlarıyla ilişkisini gösteren farklı vaka çalışmalarını derler. Ancak bunlar belirli şirketlerin kendi koşullarındaki sonuçlarıdır ve her sitede aynı yüzdeyi garanti etmez. web.dev: Why speed matters

Kendi sitenizde şu yaklaşımı kullanabilirsiniz:

1. Değişiklik öncesi performans verisini kaydedin.
2. Dönüşüm tanımını değiştirmeyin.
3. Büyük tasarım veya kampanya değişikliklerini ayrıca not edin.
4. Hız iyileştirmesini yayınlayın.
5. Mobil ve masaüstünü ayrı inceleyin.
6. Aynı uzunlukta dönemleri karşılaştırın.
7. Trafik kaynağı ve sezon etkisini not edin.

Bu yöntem bile kesin nedensellik kanıtlamaz, ancak değişikliğin etkisini daha kontrollü değerlendirmeye yardımcı olur.

Önceliği hangi sayfalara vermeli?

Bütün siteyi aynı anda optimize etmek yerine iş akışında kritik sayfalardan başlanabilir.

Örneğin e-ticarette:

• Ürün
• Kategori
• Sepet
• Ödeme

Hizmet sitesinde:

• Reklam landing page
• Hizmet sayfası
• Teklif formu
• İletişim

İlk olarak yüksek trafik veya yüksek ticari önem taşıyan sayfalarda gerçek kullanıcı verisine bakmak daha uygulanabilir olabilir.

Kopyalanabilir performans inceleme tablosu

Sayfa	İş hedefi	LCP	INP	CLS	Ana sorun	Dönüşüm olayı	Öncelik
Ana sayfa	Hizmet keşfi
Hizmet	Teklif
Ürün	Sepete ekleme
Form	Lead

Metrik değerlerini tek laboratuvar koşusundan değil, mümkünse gerçek kullanıcı alan verisinden alın.

Teknik kontrol sırası

Performans sorunu olduğunda rastgele optimizasyon yapmak yerine şu sırayı izleyin:

1. Problemi ölçün

Hangi sayfa ve hangi metrik sorunlu?

2. Gerçek kullanıcı ile laboratuvar verisini ayırın

Sorun sahada mı, yalnızca test ortamında mı?

3. LCP öğesini bulun

Ana içerik neden geç geliyor?

4. Uzun JavaScript görevlerini inceleyin

Etkileşim neden gecikiyor?

5. Layout shift kaynaklarını bulun

Hangi eleman sonradan yer değiştiriyor?

6. Üçüncü taraf scriptleri kontrol edin

Chat, reklam, analiz veya harici widget'lar ne kadar yük oluşturuyor?

7. Düzeltme sonrası aynı koşullarda tekrar test edin

Tek değişiklikle neyin iyileştiğini görün.

Başarı ölçütü ne olmalı?

Tek hedef "100 PageSpeed puanı" olmamalıdır.

Daha sağlıklı bir değerlendirme:

• Core Web Vitals alan verisi iyileşti mi?
• Kritik kullanıcı akışı daha hızlı mı?
• Form veya sepet etkileşim gecikmesi azaldı mı?
• Hata arttı mı?
• Dönüşüm oranında veya tamamlanan işlem sayısında anlamlı değişim var mı?

Hız optimizasyonu kullanıcı deneyiminin önemli bir parçasıdır. Fakat performansı tasarım, içerik ve dönüşüm akışından bağımsız bir teknik puan yarışına çevirmemek gerekir.