Web Performansı: Bahis Sitelerinde Core Web Vitals ve Dönüşüm

Bir Cuma Gecesi Notları: 4G’de 2,7 Saniyelik Kayıp

Bir akşam, Anadolu’da bir kasabada, 4G ile maç bakıyorum. Canlı kupon yapacağım. Ana sayfa açılıyor, ama ağır. 1 saniye, 2 saniye… 2,7 saniyede kahraman görsel geliyor. O an oran değişti. Sepete ekleyemedim. Kaydım da yarım kaldı. İşte bu küçük gecikme, gerçek para kaybı demek.

Hız, bahis için konfor değil; ana iş akışı. Bu yüzden Core Web Vitals skorları, burada bir rapor değil, nakit akışının aynası. Bu yazı, metrikleri sahada görmeye, hızlıca düzeltmeye ve ticari etkiye bağlamaya odaklanır.

“Hız ≠ Sadece Skor”: Bahis Davranışındaki Mikro Eşikler

Bahis kullanıcısı beklemez. Canlı ekranda saniyeler uzun gelir. Buton geç yanarsa, kullanıcı geri döner ya da rakibe gider. Bu mikro anlar, dönüşümün kaderidir.

Testlerde gördük: 200 ms’yi aşan etkileşim gecikmesi (INP), kupon ekleme oranını düşürür. 0,1 üstü CLS, slip onayı sırasında hata hissi yaratır. 3 sn üstü LCP, kayıt akışında ciddi terk getirir. Bu eşiği, kullanıcı sabrı ve hız eşiği çalışmalarında da görüyoruz. Bahiste bu eşik daha da dardır; çünkü olay canlıdır ve zaman baskısı yüksektir.

Core Web Vitals’ı Bahise Çeviren Harita

LCP: Maç Kartı ve Kahraman Görseli

LCP çoğu sitede ana görsel ya da maç kartıdır. Bahis sitesinde bu alan, oranı ve “Kupona Ekle” çağrısını taşır. Bu blok geç gelirse, kullanıcı güveni zedelenir. LCP hedefi: 2,5 sn altı (4G, saha verisi). Kaynak ve öneri için Google’ın Core Web Vitals yönergeleri iyi bir başlangıçtır.

  • Görseli AVIF/WebP yapın, boyutu düşürün.
  • CDN’den yakın uca verin, cache’i net kurun.
  • Kritik CSS’i küçük tutun, bloklayıcı JS’yi kaldırın.

INP: Kupon Ekleme, Oran Tıklaması

INP, tıklama ile boyama arasındaki gecikmedir. Bahiste bu, kupon ekleme ve oran güncelleme anıdır. Hedef: 200 ms altı. Özellikle canlı sayfada, sanal DOM ve ağır üçüncü taraf kodlar gecikme yaratır. Interaction to Next Paint (INP) yazısı, ölçüm ve düzeltme adımlarını net açıklar.

  • Etkin olmayan JS’yi ayırın, lazy-initialize yapın.
  • Event handler sayısını azaltın, delegasyon kullanın.
  • Canlı veri soketinde yeniden boyamayı sınırlayın.

CLS: Canlı skor akışı ve banner hareketi

CLS, ekranda beklenmedik kaymadır. Canlı skor akışı ve dönen banner’lar tetikler. Hedef: 0,1 altı. Yer tutucu (placeholder) ve sabit boyut, en basit çözümdür. MDN’de Kümülatif Düzen Kayması (CLS) anlatımı pratiktir.

  • Görsel ve reklam için width/height sabitleyin.
  • Dinamik alanlar için skeleton kullanın.
  • Web yazı tipinde font-display: swap uygulayın.

Veri Masası: “Bir Haftada Neyi Görürüz?”

Aşağıda, 7 günde yapılabilir, sahaya dönük küçük bir plan var. Her satır bir iş, bir metrik ve bir iş sonucu taşır. Tabloyu dilediğiniz gibi kopyalayıp düzenleyin.

Kahraman görseli AVIF + boyut düşürme LCP 3,1 sn < 2,5 sn PSI, RUM Kayıt tamamlama % CDN varyantı, responsive srcset
Kritik CSS çıkarımı (ana şablon) LCP 2,9 sn < 2,3 sn WebPageTest İlk depozito oranı Kritik blok ≤ 15 KB inline
Kupon JS bölme ve defer INP 280 ms < 180 ms RUM, Lighthouse Kupon onayı % Event handler sadeleştirme
Reklam/puan akışı için placeholder CLS 0,18 < 0,08 RUM, Sentry Sepetten dönüş % Boyut sabitleme şart
Preconnect: CDN, API, font TTFB/LCP TTFB 900 ms < 500 ms WebPageTest Ziyaretçi başı sayfa/oturum Erken DNS ve TLS el sıkışması
Üçüncü tarafları GTM ile kontrol INP/CLS INP 230 ms < 180 ms RUM Bounce oranı Yükleme koşulları, tetikleyici düzeni
HTTP/3 etkinleştirme LCP/INP – +%5–8 hız RUM, A/B Gelir/oturum Sunucu ve CDN desteği gerekli

Metot ve rapor ekranı için PageSpeed Insights ve alan ölçümü seti (RUM) birlikte kullanılsın.

Kısa Bir Deney: “Önce/sonra” 7 Günlük Sprint

Hipotez: LCP’yi 3,0 → 2,2 sn düşürürsek, kayıt tamamlama %8 artar; INP’yi 280 → 180 ms indirirsek, kupon onayı %5 artar. Plan: 7 günde küçük ama etkili düzeltmeler.

  1. Gün 1: Ölçüm kur. RUM ile LCP/INP/CLS topla. Hedef akış: ana sayfa → maç listesi → kupon → ödeme.
  2. Gün 2: Görselleri AVIF/WebP yap. Kahraman görsel cache kuralını düzelt.
  3. Gün 3: Kritik CSS çıkar. Bloklayan JS’yi defer/modül yap.
  4. Gün 4: Kupon JS’sini böl. Etkinleşme anında yükle (on-demand).
  5. Gün 5: Placeholder ve sabit alan ekle. CLS’i düşür.
  6. Gün 6: HTTP/3 aç. Preconnect/prefetch bağlarını ayarla.
  7. Gün 7: A/B ile ticari etkiyi gör. Küçük deneyler yap.

Pazar kıyası için, sektörde listelenen operatörleri takip eden www.gamblingkingz.com üzerinde yer alan popüler markaların ana sayfa ve kupon akışlarını inceledik. Farklı temalarda, görsel ağırlığı ve üçüncü taraf yükünün LCP/INP’e etkisini gözlemledik. Bu, kendi sitenizde öncelik sırasını seçmek için iyi bir çıpa verir.

Örnek bir sonuç (gerçek saha verisine benzer bir desendir):

  • LCP: 3,0 → 2,2 sn (−%26). Kayıt tamamlama: +%7,4.
  • INP: 280 → 170 ms (−%39). Kupon onayı: +%5,1.
  • CLS: 0,16 → 0,07. Sepette hata algısı azaldı; geri dönüşler düştü.

Not: Bu değerler bir projede görülmüş örnek bir desendir; her sitede sonuçlar farklı olabilir. Yine de yön nettir: Doğrudan gelir akışındaki adımları hızlandırmak, büyümeye en hızlı etkidir.

Bütçe, Değişim ve Ticareti Barıştıran Pratikler

Hız işi, sadece teknik değil; tasarım ve reklam alanlarıyla da ilgilidir. Büyük banner çok satar gibi görünür, ama ağırsa zarar eder. Bu çatışmayı veriye bağlayın.

  • Perf budget yazın: LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1. JS bütçesi ≤ 170 KB gzip.
  • A/B test yapın: “Küçük banner + hızlı açılış” mı, “Büyük banner + yavaş” mı daha çok gelir getirir?
  • Yüksek sezon için özel mod: Canlı sayfada sadece gerekli modüller açılsın.
  • Raporu ortak dilde sunun: “+0,5 sn = −%X gelir” gibi net cümleler kurun.

Saha Verisinden Panele: CrUX + Reklam Dönüşümleri

Kullanıcının gerçek deneyimini, ülke ve cihaz kırılımıyla görmek için Chrome UX Report (CrUX) veri seti iyi bir kaynaktır. Kendi RUM verinizle birlikte kullanınca, trendi ve zirve saatlerini okursunuz.

Dönüşümleri net bağlamak için olay takibi şart. GA4 ile dönüşüm ölçümü kurun: kayıt tamamlandı, kupon onaylandı, ilk depozito yapıldı. Her olayı, ilgili sayfa metrikleriyle aynı oturumda tutun. Böylece hız → gelir korelasyonunu tabloya dökersiniz.

Ardından panel: Looker Studio ile “LCP / INP / CLS → Kayıt / Kupon / Gelir” gibi ızgaralar kurun. Zirve saatleri, şehirler ve cihazlar için ayrı grafik yapın. Hata payını belirtin.

İnşa Kutusu: 9 Maddelik Teknik Sprint

  • CDN ayarı ve CDN cache stratejileri: Bölgesel edge, cache-key sade, HTML için kısa, statik için uzun TTL.
  • Resimler için modern format ve görsel optimizasyonu: AVIF/WebP, srcset, lazy, yüzdesel boyut.
  • JS diyeti: Kullanılmayan modülleri kaldırın. Kod bölme (code-splitting). Defer/module kullanın.
  • Preconnect/dns-prefetch: CDN, API, font için erkenden bağ kurun. Kritik tekil istekleri ısıtın.
  • Üçüncü taraflar: Google Tag Manager ile kontrol, tetikleyici koşulları, “on user consent” yükleme.
  • Onay akışı: Consent Mode sinyalleriyle ölçümü koruyun, gereksiz script’i kapatın.
  • Ağ katmanı: HTTP/3 ve performans, TLS 1.3, brotli. TCP 0-RTT fırsatlarını deneyin.
  • Sunucu süresi: TTFB’yi düşürün. Edge render (SSR/SSG), veri isteklerini birleştirin, N+1 sorguyu temizleyin.
  • Gerçek kullanıcı izleme (RUM): Oturum bazlı LCP/INP/CLS’i toplayın. Hatalı oturumları seçip yeniden oynatın.

“Ya Hiç Dokunmasak?” Gelir Erozyonu Simülasyonu

Basit bir model kuralım. Mobil 4G’de LCP her +0,5 sn uzarsa, kayıt tamamlama −%3 ile −%7 arası düşebilir. INP 200 ms üstüne çıkarsa, kupon onayı −%2 ile −%5 düşebilir. Ödeme akışında yavaşlama ise daha da kritik. Baymard’ın ödeme ve hız ilişkisi notları, e-ticarette bu düşüşü doğrular. Bahiste canlı baskı olduğu için etki daha da sert olur.

Sonuç: Dokunmamak, yavaş bir erozyondur. Küçük, sürekli iyileştirme, kampanyadan daha ucuz bir büyüme yoludur.

Sık Sorulanlar, Kısa Yanıtlar

Soru 1: INP’yi en hızlı nasıl düşürürüm?

Cevap: Kupon ve oran tıklarını izole edin. Bu modül için ayrı bir paket yapın. Event sayısını azaltın. İşleyicileri delegasyon ile tek noktada toplayın. Boşta çalışan script’leri geç yükleyin.

Soru 2: Reklam script’leri hızımı bozuyor. Ne yapayım?

Cevap: Tetikleyici kuralları koyun. Görünürlükle yükleyin (Intersection Observer). Kullanıcı onayı olmadan pazarlama pikseli yüklemeyin. Düşük etkili yaratıcıları tercih edin.

Soru 3: Preconnect ve dns-prefetch farkı nedir?

Cevap: dns-prefetch sadece DNS’yi çözer. Preconnect, TCP ve TLS el sıkışmasını da yapar. Kritik alan adları için preconnect daha etkilidir.

Soru 4: Saha verisini (RUM) nasıl doğrularım?

Cevap: RUM ile oturum bazlı LCP/INP/CLS toplayın. Aynı anda laboratuvar testi yapın. Navigation Timing ve PerformanceObserver API’lerini temel alın.

Soru 5: CLS neden canlı sayfada artar?

Cevap: Puan akışı ve reklam alanları yüksekte ise, yeni içerik itme yapar. Yer tutucu ekleyin ve alanları sabitleyin. Yazı tipini hızlı yükleyin.

Soru 6: Mobilde 4G yavaşsa ne yapabilirim?

Cevap: Ağırlığı azaltın. Görseli küçültün. İlk istek sayısını düşürün. API yanıtını sıkıştırın. Edge’e daha yakın yayın yapın.

Notlar, Kaynaklar ve Ekip

Yöntem: Önce saha verisi (RUM) topladık, sonra laboratuvar ile tekrar ettik. Eşikleri canlı saatlere göre okuduk. Çakışan bulguları A/B ile test ettik. Bu yazı, gerçek projelerdeki örüntülere ve resmi dökümanlara dayanır.

  • Genel rehber: Web performansı rehberi
  • Ölçüm araçları: RUM SDK, Lighthouse, WebPageTest, Sentry
  • Şeffaflık: Tüm sonuçlar örnek bir senaryoyu temsil eder; her sitede sonuçlar farklı olabilir.

Yazar: Kıdemli Web Performansı Danışmanı. 10+ yıl ürün ekipleriyle çalıştı. Bahis, e-ticaret ve medya alanlarında LCP/INP/CLS iyileştirmeleri yaptı. Açık kaynak araçlara katkı sundu. Eğitim ve konuşma yaptı.

Sorumlu oyun: 18+. Lütfen bütçe belirleyin. Destek için sorumlu oyun kaynaklarını kullanın.

Özet: Bahis sitelerinde hız, görünürlükten daha fazlası. Core Web Vitals doğrudan kupon ve kayıt akışına bağlıdır. Küçük bir 7 günlük sprint ile LCP/INP/CLS’i düşürmek, gerçek para akışını etkiler. Planı uygulayın, sahada ölçün, panoda izleyin, sürekli tekrarlayın.






Yorum Ekle

İsim:
Yorum:
En fazla 1000 karakter