Vaka Analizi: B2B E-Ticaret Sitelerinde Ağırlaşan WooCommerce Altyapısını Kurtarma
Kurumsal toptan satış operasyonları yürüten B2B şirketlerinin en büyük handikabı, karmaşık iskontoların ve ağır veri sorgularının web sitesini felç etmesidir. İlk Bayta Kadar Geçen Sürenin (TTFB) 2.5 saniyenin üzerine çıktığı bir WooCommerce platformunu, Nginx, Redis ve Cloudflare Zaraz üçgeniyle nasıl ölçeklenebilir bir mimariye kavuşturduğumuzu şeffafça paylaşıyoruz.
Müşteri Gizliliği İlkemiz: B2B müşterimizin iş modelinin ve bayilik yapılanmasının kopyalanmasını engellemek amacıyla marka adı gizlenmiş; odak noktası yalnızca arka uç (backend) optimizasyonu ve sunucu hızlandırma metrikleri olmuştur.
01 / Kriz ve Meydan Okuma
Toptan satış yapan müşterimiz, her bir bayisine (satıcı) farklı indirim oranları sunan karmaşık bir WooCommerce altyapısına sahipti. Sitedeki yoğun veritabanı sorguları (Query) ve sayfaya gömülü onlarca pazarlama pikseli (Analytics, Ads, Hotjar) sitenin ana iş parçacığını (Main Thread) kilitliyordu.
Sunucunun isteğe ilk yanıt verme süresi (TTFB) 2.5 saniyelere ulaşmıştı. Toptan sipariş geçmek isteyen B2B bayiler, sepet ve ödeme adımlarındaki yavaşlık nedeniyle sıkılarak sayfayı terk ediyor veya telefonla sipariş vermeye yönelerek operasyonel yükü (çağrı merkezi maliyetlerini) artırıyordu.
02 / Triple Works Teşhisi (Audit)
Çoğu ajansın yapacağı gibi siteye sıradan bir “Cache Eklentisi” kurup geçmenin işe yaramayacağı çok açıktı. Çünkü sorun statik (blog) sayfalarda değil; doğrudan dinamik fiyatlandırmanın hesaplandığı, sepet ve ödeme (Checkout) gibi önbelleklenemeyen sayfalardaydı.
Yaptığımız detaylı Log ve Şelale (Waterfall) analizlerinde şunları tespit ettik:
- Her bayi girişi yaptığında, veritabanından yüzlerce fiyat kuralı anlık hesaplanarak MariaDB sunucusunu yoruyordu.
- Gereksiz üçüncü parti takip scriptleri tarayıcıda darboğaz yaratıyor, Core Web Vitals metriklerini kırmızıya boyuyordu.
Sunucu Seviyesinde Müdahale Şarttı
WordPress içerisinden eklenti kurarak çözülemeyecek kadar ağır bir veri yükü vardı. Sorunu PHP veya WordPress seviyesinde değil, doğrudan sunucu donanımı (Server-side) ve ağ (Network) mimarisinde çözmemiz gerekiyordu.
03 / Mühendislik ve Tedavi Süreci
Sitenin hem arka yüzünü hem de dış dünyaya bakan yüzünü (Frontend) baştan aşağıya modifiye ettik:
- Veritabanı Hafifleştirme (Redis): MariaDB sunucusunun her tıklamada tekrar hesaplama yapmasını engellemek için bellek içi veri yapısı deposu olan Redis Object Cache kurgusunu sisteme entegre ettik. Sık yapılan veritabanı sorguları doğrudan RAM’den okunmaya başladı.
- Sunucu Yorumlama Hızı: Statik ve önbelleğe uygun isteklerde Nginx FastCGI Cache’i, PHP çalışma süresini azaltmak için ise OPcache’i devreye aldık. Sepet, ödeme ve oturum bazlı istekleri cache kapsamının dışında tutarak dinamik WooCommerce akışını koruduk.
- Üçüncü Parti Script Yükü (Zaraz): Google Analytics, Facebook Pixel ve diğer harici kodları Cloudflare Zaraz altyapısı üzerinden çalıştırarak, tarayıcıdaki üçüncü parti JavaScript yükünü önemli ölçüde azalttık ve ana iş parçacığındaki yükü düşürdük.
- Güvenlik ve Performans (Turnstile): Eski ve yavaş reCAPTCHA sistemlerini kaldırarak, bayilerin form doldurma işlemlerini hızlandıran Cloudflare Turnstile ile spam koruması sağladık.
Gerçek Sonuçlar ve Performans Etkisi
Sunucu ve ağ mimarisindeki bu derin mühendislik çalışmasının ardından site; ölçeklenebilir, cache katmanları ayrıştırılmış ve WooCommerce iş akışlarına göre optimize edilmiş bir sunucu mimarisine dönüştü.
Hızlanan ödeme ekranları ve daha akıcı B2B sipariş adımları, kullanıcıların satın alma sürecindeki sürtünmeyi azaltarak sepet ve form dönüşümlerinin iyileşmesine katkı sağladı. Core Web Vitals metriklerinin iyileşmesiyle birlikte teknik kullanıcı deneyimi güçlendi; organik görünürlük tarafında da olumlu değişimler gözlemledik.