Adım Adım E‑Ticaret: Hız & Güvenlik (Güncel)

Adım Adım E-Ticaret: Hız ve Güvenlik​

E-ticarette hız ve güvenlik aynı müşteri yolculuğunu korur. Ürün sayfası geç açılırsa kullanıcı ayrılır; ödeme veya hesap akışı güven vermiyorsa alışveriş tamamlanmaz. Sağlam sistem, katalogdan iadeye kadar kritik adımları hızlı tutarken kişisel veri, kart işlemi, yetki ve kayıt sorumluluklarını da açık biçimde yönetir.

---

En hızlı sayfa değil, yoğunluk ve hata anında da güvenli kalan alışveriş akışı hedeflenir.

Kritik Müşteri Yolculuğunu Çıkarın​

Ana sayfa ölçümü tek başına yeterli değildir. Arama, kategori, ürün, sepete ekleme, sepet, giriş, adres, ödeme, sipariş onayı ve iade adımlarını tek bir haritada gösterin. Her adım için kullanıcı hedefi, dış bağımlılık, hata mesajı ve sorumlu ekip belli olsun.

• Keşif: Arama sonucu, filtre ve kategori sayfaları doğru ve hızlı yanıt veriyor mu?
• Karar: Fiyat, stok, teslimat ve iade bilgisi ürün sayfasında tutarlı mı?
• Sepet: Kampanya ve kargo hesabı gecikmeden, yinelenmeden çalışıyor mu?
• Ödeme: Kullanıcı aynı siparişi iki kez oluşturmadan güvenle tekrar deneyebiliyor mu?
• Sonrası: Onay, fatura, kargo, iade ve destek kayıtları aynı sipariş kimliğiyle izlenebiliyor mu?

1. Performans Bütçesi Belirleyin​

Core Web Vitals için “iyi” alan veri eşikleri LCP 2,5 saniye, INP 200 milisaniye ve CLS 0,1 olarak kullanılabilir. Ancak e-ticaret için teknik metrikleri iş sonucu ile eşleyin: ürün görüntüleme, sepete ekleme, checkout başlatma, ödeme denemesi ve sipariş başarı oranı.

Performans bütçesi = sayfa ağırlığı + kritik istek sayısı + ana iş parçacığı süresi + dış servis gecikmesi

Her şablon için mobil 75. yüzdelik hedefi, hata oranı ve kabul edilen üçüncü taraf sayısı belirleyin. Kampanya öncesi yapılan değişiklik bu bütçeyi aşıyorsa yayın kapısı durmalıdır.

2. Katalog ve Görsel Yükünü Azaltın​

Ürün listeleme ekranında bütün varyant ve görselleri ilk istekte taşımayın. Görünen kartları önceliklendirin, altında kalan görselleri tembel yükleyin ve görsel alanı için boyut ayırın. Filtre sonuçlarında gereksiz tam sayfa yenileme yerine ölçülmüş, erişilebilir bir etkileşim tasarlayın.

• Görseli kartta gösterildiği boyuta yakın üretin; biçim ve kaliteyi cihaz desteğine göre seçin.
• Ana ürün görselini geç keşfettiren CSS arka planından kaçının veya yükleme önceliğini açıkça yönetin.
• Stok ve fiyatı farklı cache katmanlarında çelişmeyecek şekilde tek kaynakla ilişkilendirin.
• Arama sonuçsuzluğu, filtre gecikmesi ve API timeout oranını izleyin.

3. Cache ile Kişisel Veriyi Ayırın​

Kategori ve ürün içeriği çoğunlukla genel önbelleğe uygundur; sepet, hesap, adres ve ödeme kullanıcıya özeldir. Cache anahtarında oturum, dil, para birimi ve ülke gibi gerçekten gerekli varyasyonları belirleyin. “Sepet boş” veya başka kullanıcının fiyatı gibi veri sızıntıları, yanlış cache kuralının ciddi sonucudur.

CDN kullanılıyorsa origin yalnız güvenilir ağdan erişilebilir olmalı; gizli yönetim yolları ve API uçları genel cache kuralına girmemelidir. Cache temizleme işlemini bütün siteyi gereksiz yere boşaltmak yerine ürün veya kategori anahtarıyla sınırlandırın.

4. Checkout'ta JavaScript ve Form Sürtünmesini Azaltın​

Ödeme sayfasında reklam, sohbet, ısı haritası ve kişiselleştirme betikleri ana görevle yarışmamalıdır. Zorunlu olmayan kodları geciktirin; adres, kargo ve ödeme alanlarında her tuşta ağır doğrulama çalıştırmayın. Form hatasını alanın yanında, neyin düzeltileceğini söyleyen metinle gösterin ve kullanıcı girdisini gereksiz yere sıfırlamayın.

• Zorunlu alanları gerçekten gerekenlerle sınırlayın.
• Buton tıklamasından sonra görünür bekleme durumu sağlayın; tekrar tıklamayı güvenli biçimde yönetin.
• Klavye odağı, form etiketi, otomatik tamamlama ve hata özetini sınayın.
• Ödeme sağlayıcı dönüşünde sipariş durumunu tarayıcıya değil sunucu kaydına göre gösterin.

5. Ödeme İsteklerini Yinelenmeye Dayanıklı Kurun​

Ağ timeout'u, ödemenin başarısız olduğu anlamına gelmez. Sağlayıcı işlemi tamamlamış fakat yanıt mağazaya ulaşmamış olabilir. Her ödeme denemesine benzersiz bir işlem anahtarı verin; aynı anahtarla yapılan güvenli tekrarın ikinci tahsilat üretmemesini sağlayın. Sipariş, ödeme ve iade için açık durum makinesi kullanın.


Tarayıcıdaki başarı ekranını tek doğruluk kaynağı saymayın. Webhook imzasını doğrulayın, ham gövde gereksinimini koruyun, olayı kalıcı kayda alın ve işlemeyi tekrar çalıştırılabilir tasarlayın. Aynı olayın iki kez gelmesi ikinci sipariş veya fatura oluşturmamalıdır.

6. Kart Verisi Kapsamını Küçültün​

Kart numarasını mağaza sunucusuna almamak, güvenlik kapsamını azaltmaya yardımcı olabilir; fakat PCI DSS sorumluluğunu otomatik olarak sıfırlamaz. Kullanılan yönlendirme, iframe veya gömülü alan modeline göre ödeme kuruluşu ve nitelikli uzmanla kapsamı doğrulayın. Kart verisini log, analitik, destek ekranı veya hata mesajına taşımayın.

• Ödeme sayfasındaki script ve değişikliklerin envanterini tutun.
• Yönetici hesaplarında çok faktörlü doğrulama ve en az yetki uygulayın.
• API anahtarlarını istemci koduna koymayın; ortam ve yetkiye göre ayırın.
• İade ve manuel tahsilat yetkilerini çift kontrol veya limitlerle yönetin.

7. Hesap ve Bot Kötüye Kullanımını İzleyin​

Kimlik bilgisi doldurma, kart deneme, sahte hesap ve stok tüketme saldırıları yalnız güvenlik değil performans sorunudur. IP'ye dayalı tek bir limit, ortak ağdaki gerçek müşterileri engelleyebilir. Hesap, cihaz, davranış, ödeme sonucu ve hız sinyallerini birlikte değerlendirin; yüksek riskte ek doğrulama veya manuel inceleme kullanın.

WAF ve bot kurallarının arama motoru taramasını, ödeme webhook'unu veya erişilebilirlik aracını engellemediğini kayıtlarla doğrulayın. 403 ve 429 oranını dönüşümle aynı zaman çizelgesinde izleyin.

8. Tüketici Bilgisini Performanstan Feda Etmeyin​

Teslimat, toplam bedel, ek masraf, cayma ve iade koşulları ödeme öncesinde açık olmalıdır. Bu bilgileri sırf sayfayı kısaltmak için gizli veya geç yüklenen bir katmana taşımayın. Hız optimizasyonu, yasal ve kullanıcı açısından kritik açıklamayı kaldırmak değil; daha erken ve anlaşılır sunmaktır.

Kampanya fiyatı, kupon ve kargo bedelinin ürün sayfası, sepet, checkout ve sipariş kaydında aynı hesaplama sürümünü kullanmasını sağlayın. Sonradan değişen kuralın geçmiş sipariş kanıtını bozmaması için karar girdilerini saklayın.

9. İzleme ve Alarm Kurun​

• Performans: Şablon bazında LCP/INP/CLS, TTFB ve cache hit oranı
• Ticari akış: Sepete ekleme, checkout başlatma, ödeme başarı/başarısızlık ve terk
• Operasyon: Stok/fiyat eşitleme gecikmesi, webhook kuyruğu ve fatura hatası
• Güvenlik: Yetkisiz giriş, anahtar kullanımı, WAF/bot engeli ve dosya değişikliği
• Mutabakat: Sağlayıcı tahsilatı, sipariş, iade ve banka hareketi arasındaki fark

Alarmı yalnız yüzdeye bağlamayın. Düşük trafikte bir kritik ödeme hatası yüzdesel olarak aşırı, yüksek trafikte ise küçük görünebilir. Hem adet hem oran hem de parasal etki eşiği kullanın.

Yayın ve Olay Kontrol Listesi​

• Test kartlarıyla başarılı, başarısız, timeout, 3D Secure ve iade akışları sınandı mı?
• Aynı ödeme isteği ve webhook olayı tekrarlandığında tek sonuç oluşuyor mu?
• Mobil checkout, klavye gezinmesi ve hata mesajları çalışıyor mu?
• Cache/WAF/CDN değişikliğinin hesap ve sepet verisini sızdırmadığı doğrulandı mı?
• Sürüm, sorumlu, geri alma ve müşteri iletişimi planı kayıtlı mı?
• Mutabakat raporu sipariş ve sağlayıcı kayıtlarını aynı kimlikle birleştiriyor mu?

Sık Sorulan Sorular​

Daha hızlı checkout için alanları kaldırmalı mıyım?
Yalnız iş, ödeme, teslimat veya mevzuat açısından gereksiz alanları kaldırın. Kritik bilginin gizlenmesi hız değil güven kaybı yaratır.

Ödeme sağlayıcısına yönlendirme güvenliği çözer mi?
Kart verisi kapsamını azaltabilir; mağaza hesabı, sipariş, API anahtarı, webhook ve sahtecilik kontrolleri yine işletmenin sorumluluk alanındadır.

Her sayfayı cache'e almak doğru mu?
Hayır. Sepet, hesap ve ödeme gibi kişisel/dinamik sayfalar genel cache'e alınmamalıdır. Kurallar gerçek oturumlarla sınanmalıdır.

INP neden ödeme sayfasında yükselir?
Çok sayıda üçüncü taraf betik, ağır doğrulama, büyük framework işi veya tıklama sonrası senkron hesaplama ana iş parçacığını bloke edebilir.

Webhook kaybolursa ne yapılır?
İmzalı olayları kalıcı kuyruğa alın, tekrar denemeyi idempotent yapın ve düzenli mutabakatla sağlayıcıdaki işlemleri mağaza kayıtlarıyla karşılaştırın.

Kampanya öncesi en önemli test nedir?
Beklenen tepe yükünde ürün, sepet ve ödeme akışını dış servis gecikmeleriyle birlikte sınamak; alarm ve geri alma adımını prova etmektir.

İç Bağlantılar​

• E-Ticaret ve Ödeme Başlangıç Rotası
• E-ticaret performans rehberi
• Ödeme sistemi performans kontrolü
• Güvenli ödeme entegrasyonu

Dış Kaynaklar​

• web.dev — Core Web Vitals
• Stripe Docs — Idempotent istekler
• Stripe Docs — Webhook güvenliği ve işleme
• PCI Security Standards Council — PCI DSS
• Ticaret Bakanlığı — Mesafeli Sözleşmeler Rehberi

Özetle​

Kritik müşteri yolculuğunu haritalayın, kişisel sayfaları cache'ten ayırın, ödeme ve webhook işlemlerini yinelenmeye dayanıklı kurun; performans, güvenlik ve mutabakatı aynı panelde izleyin. En çok hata aldığınız alışveriş adımını ve ölçtüğünüz metriği paylaşarak darboğazı birlikte sınıflandırabilirsiniz.

---