Mobil Sitede Neden Hep Geri Kalıyorsun: E-pin Scriptinde Kimsenin Konuşmadığı Performans Bütçesi ve Her Yeni Özellikte Sitenin Nasıl Sessizce Ağırlaştığı

Bir siteyi bir kere hızlandırmak zor değil. Zor olan, altı ay sonra da hızlı kalmasını sağlamak. Çoğu e-pin satıcısının yaşadığı hikâye şudur: hafta sonu oturulur, görseller küçültülür, gereksiz betikler atılır, test puanı yeşile döner. Sonra bir kupon modülü, bir yorum bölümü, iki analiz kodu, bir duyuru şeridi eklenir. Kimse tek başına suçlu değildir ama site yine ağırdır.

Bu sızıntıyı durduran şey yeni bir optimizasyon turu değil, bir performans bütçesi. Yani "şu sayfa şu ağırlığı geçemez" diye önceden konmuş, tartışmaya kapalı sayılar. Bu yazıda bir e-pin scripti için bu sayıları nasıl belirleyeceğini, nasıl uygulayacağını ve bütçe aşıldığında ne yapacağını anlatıyorum.

Performans bütçesi tam olarak nedir, hız testinden farkı ne?

Hız testi geçmişi ölçer, bütçe geleceği sınırlar. Test sana "sayfan 1,4 megabayt" der; bütçe ise "bu sayfa 900 kilobayttan büyük olamaz, olursa yayına çıkmaz" der. Fark, birinin rapor diğerinin kural olması. Rapor okunur ve unutulur, kural ise her değişiklikte karşına çıkar.

İyi bir bütçe üç katmandan oluşur. Miktar sınırları: toplam ağırlık, JavaScript ağırlığı, istek sayısı, en büyük tek dosya. Zaman sınırları: LCP, INP, etkileşime hazır olma süresi. Kural sınırları: kaç üçüncü taraf alan adına bağlanılabilir, kaç web fontu yüklenebilir, render'ı bloklayan kaynak sayısı. Sadece saniye ölçen bütçe çalışmaz, çünkü saniyeler test cihazına göre değişir ama kilobaytlar değişmez.

Sayıları nasıl belirleyeceksin, kopya çekilecek bir tablo var mı?

Hazır listeler yol gösterir ama bütçen rakibinden türetilmelidir. Yöntem şu: aynı kelimede sıralanan üç rakibinin mobil sayfa ağırlığını ölç, en iyisini bul, ondan yüzde 20 aşağıya bir hedef koy. Amaç "iyi olmak" değil, kullanıcının karşılaştırdığı seçenekler içinde gözle farkedilir biçimde hafif olmak.

İkinci girdi kendi ziyaretçi profilin. Analizinde cihaz ve bağlantı dağılımına bak. Trafiğinin büyük kısmı orta segment Android'den geliyorsa bütçeni buna göre sıkılaştır, çünkü o cihazlarda darboğaz indirme değil işlem gücüdür ve orada JavaScript ağırlığı görsellerden daha çok acıtır. Bu yüzden JS kalemini ayrı bir bütçe satırı yapmak şart.

Neden ödeme sayfasının bütçesi en sıkı olmalı?

Kullanıcı ödeme adımına geldiğinde artık ikna edilmiş durumda; senin tek işin önüne engel koymamak. Buna rağmen pek çok sitede en ağır sayfa ödeme sayfasıdır, çünkü oraya taksit tabloları, canlı destek, güven simgeleri, üç ayrı izleme kodu ve bir de animasyonlu ilerleme çubuğu eklenmiştir. Hepsi iyi niyetlidir, hepsi birlikte satışı düşürür.

Bütçe tablonda ödeme sayfasına en düşük tavanı koy ve buna uymak için sert kararlar al: taksit tablosunu tıklamayla yükle, canlı desteği bu sayfada hiç açma, izleme kodlarını sunucu tarafında topla. Ödeme sayfası gösteri yapılacak yer değil, işin bittiği yerdir.

Bütçeyi kim ve nasıl denetler?

Kâğıtta kalan bütçe işe yaramaz. Denetimi otomatikleştirmenin en basit yolu, her yayın öncesi çalışan tek bir ölçüm adımı kurmak: kritik beş sayfayı mobil kısıtlamayla ölç, sonucu bir dosyaya yaz, tavan aşıldıysa uyarı ver. Küçük ekipler için haftalık bir kontrol bile yeterlidir; önemli olan sıklık değil, sayının kayıt altına alınması.

Yanına bir de karar kuralı yaz: bütçe aşıldığında ya aşımı geri al, ya eşdeğer ağırlıkta başka bir şeyi çıkar, ya da bütçeyi bilinçli olarak ve gerekçesiyle yükselt. Üçüncü seçenek yasak değil; yasak olan, aşımı fark etmemek. Pek çok işletme performansı kaybetmiyor, sadece kaybettiğini ölçmediği için geri alamıyor.

Üçüncü taraf kodlar: bütçenin en büyük düşmanı

Kendi kodun üzerinde tam kontrolün var; üçüncü taraf kodunda yok. Bugün 30 kilobayt olan bir betik, sağlayıcı güncelleme yaptığında yarın 90 kilobayt olabilir ve sen haberdar olmazsın. Bu yüzden bütçende üçüncü taraflar için ayrı ve daha katı bir satır tut: kaç alan adına bağlanıldığı, toplam ne kadar ağırlık getirdikleri, hangilerinin ana iş parçacığını meşgul ettiği.

Pratik kural şu: aynı işi yapan iki araç varsa birini kapat. Analiz için iki farklı sistem, ısı haritası, anket modülü ve sohbet aracını birlikte taşımak mobilde gerçekten pahalıdır. Kalanları da mümkün olduğunca ertele; kullanıcı ilk kaydırmayı yapmadan hiçbiri yüklenmesin. Bir dijital ürün satış scripti üzerinde bu tek karar, mobil etkileşim gecikmesini yüzde otuza kadar düşürebilir.

Bütçeyi sıfırdan mı kurmalısın, hazır altyapıdan mı devralmalısın?

Kendi geliştirici ekibin varsa yukarıdaki tabloyu doldurup ölçüm adımını kurmak bir haftalık iştir. Tek başına ya da küçük bir ekiple çalışıyorsan, temel kararları senin yerine vermiş bir e-pin satış yazılımı ile başlamak daha gerçekçi. Pinova'da sayfa bazlı kaynak yükleme, görsel işleme hattı ve ertelenen entegrasyon mantığı varsayılan olduğu için bütçeni yoktan var etmek yerine devraldığın bir tabandan sıkılaştırırsın.

Hangi yolu seçersen seç, unutma: performans bir proje değil, bir bakım kalemidir. Bütçe de bu bakımı hatırlatan tek şeydir. Hangi kararların hazır geldiğini özellikler sayfasından, paket kapsamlarını fiyat bölümünden inceleyebilir, kurulum adımları için panel tarafına geçebilirsin.

Performans bütçesi kulağa kısıtlayıcı geliyor ama pratikte tam tersini yapıyor: neyi ekleyebileceğini net bildiğin için karar vermek hızlanıyor. Bu tabanın hazır kurulu hâlini görmek istersen canlı demo üzerinde kategori ve ödeme sayfalarını mobil kısıtlamayla ölçüp yukarıdaki tavanlarla karşılaştırabilirsin; kendi sitenle aradaki farkı ilk bakışta fark edeceksin.