Web sitesi hızı dönüşümleri nasıl etkiler? (Ve önce neyi düzeltmelisiniz?)

Hız, kimsenin doğrudan şikâyet etmediği konulardan biridir; çünkü ziyaretçiler “Ana sayfanızın yüklenmesi dört saniye sürdü, ben de çıktım” diyen bir destek talebi açmaz. Sadece çıkıp giderler ve geriye analitikte, kolayca başka bir şeye (teklife, metinlere, tasarıma) yorulabilecek bir hemen çıkma kaydı kalır. Gerçekte ise bu kaybın kayda değer bir kısmı, kimse teklifi değerlendirecek kadar ilerlemeden önce yaşanır.

Hız ile dönüşüm arasındaki bağ neden bu kadar doğrudan?

Yükleme süresine eklenen her saniye, dikkatin dağılabileceği bir andır: bir bildirime, başka bir sekmeye, başka bir sekmede açık duran bir rakibin arama sonucuna. Bağlantıların daha istikrarsız, sabrın daha kısa olduğu mobilde bu etki daha da keskindir. Üstüne üstlük etkiler birikir: Yavaş bir sayfa yüklemesini çoğu zaman, sayfa açıldıktan sonra da yavaş ve takılan bir deneyim izler. Hemen tepki vermeyen butonlar, aniden belirip düzeni kaydıran görseller, her tuş vuruşunda geciken formlar... Bunların her biri, akışı sonuna kadar götürmek yerine yarıda bırakmak için küçük bir bahane daha demektir.

Bu yalnızca bir mobil sorunu ya da niş bir e-ticaret sorunu değildir. Ödeme akışlarında, kayıt formlarında, potansiyel müşteri toplayan açılış sayfalarında ve SaaS deneme sürümlerinin ilk kullanım adımlarında aynı şekilde karşımıza çıkar; çünkü temeldeki mekanizma her yerde aynıdır: “İlgilendi” ile “harekete geçti” arasındaki sürtünme insanları kaybettirir ve yükleme süresi bu sürtünmenin en yaygın, en kolay düzeltilebilir kaynaklarından biridir.

Önce neyi düzeltmelisiniz?

Her performans iyileştirmesi aynı getiriyi sağlamaz ve ekipler çoğu zaman yanlış olanlara zaman harcar. Tipik etkisine göre kabaca sıralarsak:

• Görseller. Optimize edilmemiş, gereğinden büyük görseller yavaş sayfaların tek başına en yaygın nedenidir ve genellikle düzeltilmesi en kolay olanıdır. Doğru sıkıştırma, modern formatlar ve görüntülendiği bağlama uygun boyutlar, gözle görülür hiçbir kalite kaybı olmadan sayfa ağırlığını büyük ölçüde azaltabilir.
• İlk bayta kadar geçen süre (TTFB). Sunucunun kendisi geç yanıt veriyorsa, hiçbir frontend optimizasyonu bunu tam olarak telafi edemez. Bunun kökeninde çoğu zaman optimize edilmemiş veritabanı sorguları, eksik önbellekleme ya da gerçek trafik için yetersiz kalan barındırma yatar.
• Render'ı engelleyen script'ler ve stiller. Sayfanın içerik gösterebilmesi için önce tamamen yüklenip çalışması gereken her şey, kendisinden sonra gelen her şeyi geciktirir. Üçüncü taraf script'ler (sohbet widget'ları, reklam etiketleri, analitik araçları) burada sık rastlanan ve hafife alınan suçlulardır.
• Düzen kararlılığı. Yüklenirken yer değiştiren içerik yalnızca özensiz görünmekle kalmaz; yanlış dokunuşlara ve sitenin yarım kalmış ya da güvenilmez olduğu hissine yol açar. Bu his de doğrudan teklifin kendisine duyulan güvene yansır.
• Özellikle ödeme ya da form akışı. Sitede hızın her şeyin önüne konması gereken tek bir bölüm varsa, o da dönüşümden önceki son birkaç adımdır. Kullanıcı bir işlemi tamamlamaya ne kadar yakınsa, onu yavaş ve takılan bir etkileşim yüzünden kaybetmenin bedeli o kadar ağırdır.

İş gerekçesi, açıkça

Performans çalışmaları, ürün yol haritasında görünmez olduğu için çoğu zaman geri plana itilir: Yeni bir özellik getirmez, sürüm notlarında etkileyici durmaz. Oysa dönüşüm oranı ona doğrudan bağlıdır ve bunu göstermek kolaydır: Aynı trafiği bir sayfanın hızlı ve yavaş sürümlerine yönlendirin; hızlı olan, bunu ölçmüş neredeyse her sektörde tutarlı biçimde daha iyi dönüşüm sağlar. Nadiren elinizdeki en büyük kaldıraçtır, ama neredeyse hiç dezavantajı olmayan birkaç kaldıraçtan biridir: Daha hızlı bir site; her ziyaretçiye, her cihazda, sitenin her hedefi için aynı anda fayda sağlar.

Gerçekte nereden başlamalı?

Siteyi gerçek bir performans denetiminden geçirin (Google PageSpeed Insights veya benzeri bir araçla, yalnızca sentetik bir laboratuvar puanına değil, gerçek saha verilerine bakarak) ve tahmin yürütmek yerine gerçekte neyin başarısız olduğunu görün. Önce etkisi en yüksek, emeği en düşük kalemleri düzeltin (bunlar neredeyse her zaman görseller ve render'ı engelleyen script'lerdir), ardından listede aşağı doğru ilerleyin. Her anlamlı değişiklikten sonra yeniden test edin; çünkü performans çalışmalarında bir darboğazı çözdüğünüzde sıradakiyle karşılaşmak olağandır.

Burncode'da her web geliştirme projesinde hızı sonradan akla gelen bir detay olarak değil, birinci sınıf bir gereksinim olarak ele alıyoruz. Çünkü güzel tasarlanmış ama yavaş yüklenen bir site, iş sonuçları açısından kimsenin ziyaretini tamamlamadığı bir siteden farksızdır.