Sayfa hızı konuşulurken herkes aynı yere koşuyor: hosting. "Sunucu yavaş, paketi yükseltirim, düzelir." Paketi yükseltiyorsun, fatura artıyor, açılış süresi neredeyse aynı kalıyor. Çünkü problem çoğu zaman işlemci gücünde değil, sayfanın ne beklediğinde. Bir e-pin satış scripti ana sayfası, ziyaretçiye tek bir piksel göstermeden önce onlarca sorgu, birkaç dış istek ve megabaytlarca görsel yükü sırada tutuyor olabilir.
İşin can sıkıcı tarafı şu: bu gecikme en pahalı yerde vuruyor. Ürün listesinin yarım saniye yavaş gelmesi katlanılabilir; ödeme adımının üç saniye beklemesi ise doğrudan ciro kaybıdır. Bu yazıda gecikmenin gerçekte nerede saklandığını, hangi ölçümün neyi söylediğini ve bir epin yazılım kurulumunda hangi müdahalenin gerçekten sonuç verdiğini sırayla açacağız.
Hız sorununu hosting sanıyorsun ama sayfa bir sorgu bekliyor
Bir sayfanın yavaşlığını anlamanın en dürüst yolu, sunucunun ilk baytı ne zaman gönderdiğini ölçmektir. Bu süre uzunsa sorun tarayıcıda ya da görsellerde değil, arka planda. E-pin satan sitelerde en sık rastlanan sebep, ana sayfada döngü içine sıkışmış sorgulardır: kırk ürünün her biri için ayrı stok sayımı, ayrı kategori adı, ayrı kur çevrimi.
Kırk ürün, ürün başına üç sorgu demek yüz yirmi sorgu. Her biri tek başına hızlı görünür, toplamı sayfayı boğar. Çözüm tek cümlelik: döngü içinde sorgu çalıştırmayacaksın. Stok sayımları tek bir toplu sorguyla alınıp bellekte eşleştirilir. Bu tek değişiklik, çoğu kurulumda sunucu yanıtını yarıya indirir ve hiçbir donanım masrafı gerektirmez.
E-pin sitesinde ilk baytın gecikmesi nereden gelir?
Üç ana kaynak var. Birincisi yukarıda anlattığımız sorgu enflasyonu. İkincisi senkron dış isteklerdir: kur servisi, bakiye sorgusu, tedarikçi stok kontrolü. Bunlardan biri sayfa oluşturulurken beklenirse, o servisin yavaşlığı senin sayfanın yavaşlığı olur. Üçüncüsü ise indeksi olmayan tablolardır; sipariş tablosu büyüdükçe listeleme ekranları tuhaf biçimde ağırlaşır.
Dış isteklerin çözümü sayfayı beklemekten kurtarmaktır. Kur bilgisi zamanlanmış bir görevle çekilip veritabanına yazılır, sayfa hazır değeri okur. Tedarikçi stoğu sipariş anında doğrulanır, vitrin gösterilirken değil. Böylece dış servis çökse bile vitrin ayakta kalır; bu sadece hız değil, dayanıklılık kazancıdır.
| Müdahale | Tipik kazanç | Zorluk | Risk |
|---|---|---|---|
| Döngü içi sorguları toplu sorguya çevir | 300-700 ms | Orta | Düşük |
| Kur/bakiye isteklerini zamanlanmış göreve al | 200-900 ms | Düşük | Düşük |
| Görselleri modern formata dönüştür | 1,5-3 MB | Düşük | Yok |
| Tembel yükleme (görseller) | 0,4-1,2 s | Düşük | Yok |
| Tablo indekslerini düzelt | 100-500 ms | Orta | Düşük |
| Sayfa önbelleği (yalnızca statik bölümler) | 400-800 ms | Orta | Orta |
| Hosting paketini yükselt | 50-150 ms | Çok düşük | Maliyet |
Görsel ağırlığı: kırk oyun logosu dört megabayt eder
Kategori sayfasına bakıp "birkaç küçük logo var" diyorsun. Ölçtüğünde her biri 300 KB'lık, 1200 piksel genişliğinde PNG dosyaları olduğunu görüyorsun. Tarayıcı onları 120 piksele küçültüp gösteriyor, ama indirdiği boyut tam boy. Mobil kullanıcı da bunu kendi verisiyle indiriyor.
Burada yapılacak iş sıkıcı ama etkisi en büyük olan iştir: görselleri gösterilecekleri boyutta üret, modern formata çevir, genişlik ve yükseklik değerlerini işarete yaz, ilk ekranın altındaki görselleri tembel yükle. Genişlik ve yükseklik yazmak sadece hız değil, düzen kaymasını da bitirir. Bir dijital ürün satış scripti kullanıyorsan görsel boyutlandırmanın yükleme anında otomatik yapılıp yapılmadığını mutlaka kontrol et; elde yapılan bir iş uzun vadede sürdürülemez.
Tipik bir e-pin kategori sayfasında gecikmenin dağılımı
- Sunucu tarafı sorgu ve şablon 40%
- Görsel indirme 28%
- Betik ve stil dosyaları 20%
- Dış servis ve izleme kodları 12%
Önbellek nerede biter, dinamik stok nerede başlar?
Önbellek hız işinin en güçlü, aynı zamanda en tehlikeli aracıdır. Tüm sayfayı önbelleğe alırsan uçarsın; ama tükenmiş bir ürünü "stokta" göstermeye başlarsan güvenilirliğini kaybedersin. Bu yüzden e-pin satışında önbellek sınırı net çizilmeli.
Pratik kural şudur: menü, kategori ağacı, açıklama metinleri, blog ve alt bilgi önbelleğe girer; stok, fiyat, bakiye ve sepet asla girmez. Ürün kartını önbellekten servis eder, stok durumunu küçük bir istekle canlı doldurursun. Böylece sayfa anında açılır, kritik veri ise her zaman gerçek kalır. Sipariş ve ödeme adımlarında ise önbellek tamamen kapalı olmalı; burada hız kazanmanın yolu sorguyu azaltmaktır, çıktıyı saklamak değil.
Her iyileştirmeden önce ve sonra aynı sayfayı, aynı koşulda üç kez ölç ve ortancayı not al. Tek ölçüm yanıltır; ortanca, yaptığın işin gerçekten işe yarayıp yaramadığını söyler.
Mobil bağlantı testini neden herkes atlıyor?
Ofisteki fiber hattında site uçuyor. Müşterinin çoğu ise şehir içinde, değişken sinyalde, orta segment bir telefonla geziyor. Bu iki dünya arasındaki fark üç kat açılış süresi demek. Test etmenin yolu basit: tarayıcının geliştirici araçlarında ağı yavaş bir profile sabitle, işlemciyi dörde bölünmüş simüle et, sonra ana sayfadan ödemeye kadar tam bir satın alma yap.
Bu testte en çok göze batan şey genelde betiklerdir. Sohbet aracı, ısı haritası, üç farklı izleme kodu, birkaç yazı tipi dosyası. Her biri tek başına masum, toplamı ödeme adımını felç ediyor. Sert bir karar ver: ödeme sayfasında sadece ödeme için gereken kod çalışsın. Pazarlama betikleri vitrinde kalsın, kasada değil.
Hız bütçesi koymadan optimizasyon bitmez
Optimizasyon bir seferlik iş değil, bir disiplindir. Bugün düzelttiğin sayfaya üç hafta sonra yeni bir kampanya görseli ve yeni bir izleme kodu eklenir, her şey geri gelir. Bunu önlemenin tek yolu sayısal bir bütçe koymak ve her yeni eklemede o bütçeyi sorgulamaktır.
Pinova, ürün listelerini toplu sorgularla kuran, görselleri yükleme anında boyutlandıran ve önbellek sınırını stok verisinin dışında tutan bir mimariyle gelir. Yani hız için sonradan yapılan bir cila değil, baştan kurulmuş bir düzen. Bir e-pin satış yazılımı seçerken sorulacak soru "hızlı mı" değil; "büyüdüğümde de hızlı kalacak mı" olmalıdır.
| Hız bütçesi maddesi | Hedef | Ölçüm yeri |
|---|---|---|
| Sunucu ilk yanıt süresi | 800 ms altı | Ağ sekmesi, ilk istek |
| En büyük içerik boyanma süresi | 2,5 s altı | Mobil yavaş profil |
| Sayfa toplam ağırlığı | 1,5 MB altı | Ağ sekmesi toplamı |
| Sayfa başına sorgu sayısı | 40 altı | Sorgu kaydı |
| Ödeme sayfasındaki üçüncü taraf betiği | 0 | Ağ sekmesi, alan adı süzgeci |
| Düzen kayması | 0,1 altı | Mobil ölçüm aracı |
| Görsel başına boyut | 80 KB altı | Ağ sekmesi sıralaması |
Hızı sonradan eklenen bir cila olmaktan çıkar
Pinova'nın toplu sorgu düzeni, akıllı önbellek sınırı ve otomatik görsel boyutlandırması ile büyürken de hızlı kal.
Hosting paketimi yükseltmek hızı gerçekten artırır mı?
Sınırlı ölçüde. Sorun sorgu sayısı ya da görsel ağırlığıysa daha güçlü sunucu aynı işi biraz daha hızlı yapar, ama iş yükünü ortadan kaldırmaz. Önce ölç, sonra harca.
Stok bilgisini önbelleğe alabilir miyim?
Alma. Stok, fiyat ve bakiye canlı kalmalı. Sayfanın statik iskeletini önbellekten servis edip stok durumunu küçük bir canlı istekle doldurmak doğru yaklaşımdır.
İzleme kodlarını tamamen kaldırmam mı gerekiyor?
Hayır, yerlerini değiştirmen gerekiyor. Pazarlama ve analiz kodları vitrin sayfalarında kalabilir; ödeme adımında yalnızca ödemeye ait kod çalışmalı. Dönüşüm olayını dönüş sayfasında tetikleyebilirsin.
Hızı hangi sıklıkta ölçmeliyim?
Ayda bir rutin ölçüm, ayrıca her yeni eklenti, kampanya görseli veya izleme kodu sonrası tek seferlik kontrol. Bütçeyi aşan ekleme geri alınır ya da hafifletilir.
Hız, e-pin satışında bir teknik detay değil; müşterinin sana güvenip güvenmeyeceğine karar verdiği ilk saniyedir. Sorguyu azalt, görseli hafiflet, önbelleği doğru yere koy, kasadaki fazlalığı temizle ve bir bütçe belirle. Bu düzenin hazır kurulmuş halini görmek istersen canlı demo üzerinde kategori ve ödeme sayfalarını kendi bağlantınla ölç, sonra özellikler bölümünden altyapı başlıklarını incele.