Site hızının iş metrikleriniz üzerindeki etkisini değerlendirmek için A/B testinden yararlanın.
Son birkaç yılda, site hızı performansının kullanıcı deneyiminin önemli bir parçası olduğu ve bunu iyileştirmenin dönüşüm oranları ve hemen çıkma oranları gibi farklı işletme metrikleri için faydalı olduğu kabul edildi. Bu durumu destekleyen çok sayıda makale ve örnek olay yayınlandı. Cloudflare'in Web Sitesi Performansı Dönüşüm Oranlarını Nasıl Etkiliyor?, Deloitte'un Milisaniyeler Milyonlar Kazandırıyor ve eBay.com'da Hız Alışverişi başlıklı makalelerden bazılarını sayabiliriz.
Hızın konusu net olsa da birçok şirket, bunun kendi kullanıcılarını ve sonuç olarak işletmelerini tam olarak nasıl etkilediğini tam olarak bilmedikleri için, site hızlarını iyileştirecek çalışmalara öncelik vermekte hâlâ zorlanmaktadır.
Veri olmadığında, site hızı çalışmalarını geciktirmek ve diğer görevlere odaklanmak kolaydır. Yaygın bir senaryo, şirketteki bazı kişilerin site hızının önemini fark etmelerine rağmen bunun için bir gerekçe oluşturamamaları ve birden çok paydaşı buna uygun şekilde yatırım yapmaya ikna edememeleridir.
Bu makalede, site hızının işletme metrikleri üzerindeki etkisini değerlendirmek ve böylece bu konuda daha etkili kararlar almak için A/B testinden nasıl yararlanılacağı konusunda ileri düzey rehberlik sağlanmıştır.
1. Adım: A/B testi yapılacak bir sayfa seçin
Amacınız, sayfa hızının işletme metriklerinizle ilgili olduğu varsayımını test etmektir. Basitlik açısından, başlangıçta kendinizi analiz için tek bir sayfa tanımlamakla sınırlandırabilirsiniz. İleride yapılacak çalışmalar, bulguları doğrulamak için aynı türden birden fazla sayfaya ve ardından sitenin diğer alanlarına genişleyebilir. Nereden başlayacağınıza dair bazı öneriler bu adımın sonunda verilmiştir. Sayfa seçim sürecini etkileyen birkaç gereksinim vardır:
- A/B testi yalnızca mobil cihaz kullanıcılarının cihazlarında çalıştırılmalıdır. Tüm dünyada, desteklediğimiz iş ortağı sitelerinin trafiğinin ortalama %50'sinden fazlasının mobil cihazlardan geldiğini (ve giderek arttığını!) görüyoruz ancak bu oran, bölgeye ve sektöre göre önemli ölçüde artabilir. Mobil cihazlar, işleme ve bellek kısıtlamalarının yanı sıra daha az kararlı ağlar nedeniyle daha yavaş web sitelerine karşı daha hassastır. Ayrıca, hareket halindeki kullanım kalıpları, hız beklentilerinin daha yüksek olduğu anlamına gelir.
Test için seçtiğiniz sayfa, dönüşüm huninizin önemli bir parçası olmalıdır. Her sitenin farklı bir amacı olduğundan her site farklı başarı metriklerini izler. Bu metrikler genellikle, dönüşüm hunisi kullanılarak analiz edilen bir kullanıcı yolculuğuyla ilgilidir. Örneğin, bir e-ticaret web sitesindeki kullanıcıların satın alma işlemini tamamlamak için bir ana sayfada, kategori sayfalarında, ürün sayfalarında ve ödeme sayfasında gezinmesi gerekir. Dönüşümleri optimize ediyorsanız bu sayfalardan biri iyi bir aday olabilir.
Sayfanın tek bir amacı olmalıdır. Sitenizin belirli bir misyonu yoksa genellikle testiniz için ana sayfayı kullanmaktan kaçınmanız önerilir. Pek çok ticari sitenin ana sayfası, analizlerinizi gürültülü hale getirecek çok çeşitli işlevlere yönlendiren portallardır. Örneğin, bir haber sitesinde oturum başına sayfa görüntüleme sayısını optimize ediyorsanız, en iyi seçenek sitenin ticari olmayan bölümlerini hariç tutmak ve para kazandıran bölümlere ve makalelere odaklanmaktır.
İstatistiksel olarak anlamlı bir sonuç almak için uzun süre beklemek zorunda kalmamanız için seçilen sayfa yeterli trafik almalıdır.
Seçilen sayfa nispeten yavaş olmalıdır. Aslında, ne kadar yavaş olursa o kadar iyidir. Bu, yalnızca sayfayı iyileştirmenin daha kolay olacağı anlamına gelmez, aynı zamanda verilerin daha net olması gerektiği anlamına gelir. En yavaş sayfalarınızın hangileri olduğunu görmek için Google Analytics Hız Raporunuzu veya Arama Konsolu Önemli Web Verileri raporunuzu hızlı bir şekilde tarayabilirsiniz.
Sayfa nispeten sabit olmalıdır. Test tamamlanana kadar sayfaları (işletme metriklerini etkileyecek her şey) güncellemeyin. Dikkate alınması gereken dış faktörler ne kadar az olursa analiz de o kadar anlaşılır olur.
Yukarıdakileri rehber olarak kullandığınızda hangi sayfaların testiniz için iyi aday olduğu biraz daha net olacaktır. Reklam açılış sayfaları da iyi bir seçimdir çünkü muhtemelen yerleşik işletme metrikleri, A/B testi ve analiz elinizin altındadır. Yine de emin değilseniz, aşağıda her sektör için bazı fikirler sunulmuştur:
- İçerik Web Siteleri: bölümler, makaleler
- Vitrinler: kategori sayfaları, ürün sayfaları
- Medya Oynatıcılar: video keşif/arama sayfaları, video oynatma sayfası
- Hizmetler ve Keşif (seyahat, kiralık araba, hizmet tescili vb.): ilk form girişi sayfası
2. Adım: Performansı ölçme
Metrikleri ölçmenin iki genel yolu vardır: laboratuvarda ve sahada. Sahadaki ölçüm metriklerinin (Gerçek Kullanıcı İzleme (RUM) olarak da bilinir) daha faydalı olduğunu, çünkü gerçek kullanıcıların deneyimini yansıttığını gördük. RUM verilerini raporlamanıza yardımcı olabilecek kitaplık ve hizmetlere örnek olarak Perfume, Firebase Performance Monitoring ve Google Analytics Etkinlikleri verilebilir.
Kullanıcı deneyiminin farklı yönlerini yakalamayı amaçladıkları için seçebileceğiniz birçok metrik bulunmaktadır. Hedefinizin nihayetinde hızınız ve iş metrikleriniz arasında doğrudan bir ilişki olup olmadığını belirlemek olduğunu unutmayın. Bu nedenle, işletmenizin başarısıyla en güçlü bağıntıyı belirlemek için birkaç hız metriğini takip etmek faydalı olabilir. Genel olarak Önemli Web Verileri ile başlamanızı öneririz. web-vitals.js kitaplığı, alandaki Önemli Web Verileri'nin bazılarını ölçmenize yardımcı olabilir ancak tarayıcı desteğinin%100 olmadığını unutmayın. Core Web Vitals'ın yanı sıra Other Web Vitals da göz atmaya değer. Ayrıca "İlk Reklam Tıklamasına Kadar Geçen Süre" gibi özel metrikler de tanımlayabilirsiniz.
3. Adım: Hız performansı varyantları oluşturun
Bu aşamada, geçerli sürüm karşısında test edilecek sayfanın daha hızlı bir sürümünü oluşturmak için değişiklikler uygularsınız.
Göz önünde bulundurulması gereken birkaç nokta:
- Kullanıcı arayüzünde veya kullanıcı deneyiminde herhangi bir değişiklik yapmaktan kaçının. Bir sayfa diğerinden daha hızlı olmasının yanı sıra, değişiklikler kullanıcılar tarafından görülmemelidir.
- Ölçüm de bu aşamanın önemli bir yönüdür. Geliştirme sırasında, değişikliklerinizin performans üzerindeki etkisini belirtmek için Lighthouse gibi laboratuvar testi araçları kullanılmalıdır. Bir metrikte yapılan değişikliklerin çoğu zaman diğerini etkileyebileceğini unutmayın. Sayfalar yayınlandıktan sonra, daha doğru bir değerlendirme için RUM'a bağlı kalın.
Performans varyantları farklı şekillerde oluşturulabilir. Testin amacı, bunu mümkün olduğunca basit bir şekilde yapmaktır. Aşağıda birkaç seçenek verilmiştir.
Daha hızlı bir sayfa oluşturun
- Test sayfanızdaki resimleri manuel olarak optimize etmek için Squoosh gibi bir araç kullanın.
- Yalnızca tek bir sayfa için kullanılmayan JavaScript veya CSS'yi manuel olarak ortadan kaldırmak üzere DevTools kod kapsamını kullanın.
- Üçüncü taraf komut dosyalarını verimli bir şekilde yükleme
- Kritik CSS'leri ayırmak ve satır içine almak için Kritik gibi bir araç kullanın.
- Kullanıcı deneyimini etkilemeyen ve testte kullanılmadan yapabileceğiniz kritik olmayan JavaScript kodunu (örneğin, belirli üçüncü taraf kitaplıklar) kaldırın
- Tüm tarayıcılar tarafından desteklenmeyen tarayıcı düzeyinde geç yükleme uygulayın, ancak desteklendiği durumlarda performansı yine de önemli ölçüde artırabilir
- Kritik olmayan analiz etiketlerini kaldırın veya eşzamansız olarak yükleyin
Göz önünde bulundurulması gereken ek optimizasyonları Hızlı yükleme süreleri ve Ön Uç Performansı Kontrol Listesi'nde bulabilirsiniz. Ayrıca, performansı artırma fırsatlarını belirleyen Lighthouse'u çalıştırmak için PageSpeed Insights'ı da kullanabilirsiniz.
Sayfayı yavaşlatma
Bu, varyant oluşturmanın en kolay yolu olabilir. Basit bir komut dosyası ekleyerek, sunucu yanıt sürelerini kısaltarak, daha büyük resimler yükleyerek vb. bunu da yapabilirsiniz. Financial Times, performansın kendi iş metriklerini nasıl etkilediğini test ederken bu seçeneği tercih etti: Daha hızlı bir FT.com sitesine bakın.
Sayfanın daha hızlı yüklenmesini sağlama
Test sayfasına (örneğin, bir ürün ayrıntıları sayfası) çoğunlukla farklı bir sayfadan (ör. ana sayfa) bağlantı verilen durumlarda, test grubu için ürün sayfasının doğrudan ana sayfadan önceden yüklenmesi veya önceden oluşturulması, sayfanın daha sonra yüklenmesini hızlandırır. Bu durumda, A/B testi bölmesinin (4. adım) ana sayfada yapıldığını unutmayın. Ayrıca, tüm bunlar ilk sayfayı yavaşlatabilir. Bu nedenle, test sonuçlarını analiz ederken bunu mutlaka dikkate alın ve dikkate alın (5. adım).
4. Adım: A/B testi oluşturun
Aynı sayfanın, birinin diğerinden daha hızlı olduğu iki sürümüne sahip olduğunuzda, sonraki adım etkiyi ölçmek için trafiği bölmektir. Genel olarak, A/B testleri yapmak için pek çok teknik ve araç vardır ancak tüm yöntemlerin hız performansı etkisini ölçmek için uygun olmadığını unutmayın.
Optimizely veya Optimize gibi bir A/B testi aracı kullanıyorsanız istemci tarafı testi yerine sunucu tarafı testi ayarlamanızı önemle tavsiye ederiz. İstemci tarafı A/B testi genellikle deneme yüklenene kadar sayfa içeriğini gizler ve bu da A/B testinin ölçmek istediğiniz metrikleri çarpıtacağı anlamına gelir. Yalnızca istemci taraflı test yapabiliyorsanız denemeyi farklı bir sayfada ayarlamayı ve trafiği bölmek için test sayfanızın bağlantı noktalarını değiştirmeyi düşünün. Bu şekilde, test sayfasının kendisi istemci taraflı test tarafından aşağı sürüklenmez.
Sunucu tarafı testi aracılığıyla belirli bir ürün ayrıntıları sayfasında (PDP) AB testi performans değişikliklerini gösteren örnek:
İstek, kullanıcıları sayfanın iki farklı sürümüne dağıtan arka uca gider. Bu, genel olarak iyi bir kurulum olsa da sunucu tarafı bölme işlemini kurmak için genellikle BT kaynaklarına ihtiyaç duyar.
Aşağıda, test amaçlı JavaScript'i çalıştırmak için önceki sayfanın (aşağıdaki şemada yer alan ana sayfa) kullanıldığı bir istemci tarafı test kurulumu örneği verilmiştir:
Test JavaScript'i, giden bağlantıyı kullanarak iki test kullanıcı grubuna söz konusu PDP'nin iki sürümüne bağlantılar verir. Bu özelliğin kurulumu ve bakımı, Optimizely veya Optimize gibi yaygın A/B testi araçlarıyla kolay bir şekilde gerçekleştirilebilir ve test edilen JavaScript'in farklı bir sayfada çalışması nedeniyle performans testini etkilemez.
Alternatif olarak, çok benzer davranan ve performans gösteren iki sayfa seçebilirsiniz (örneğin, çok benzer iki ürün için). Değişikliklerinizi bunlardan birine uygulayın ve ardından zaman içindeki metriklerdeki farkı karşılaştırın. Bu, uygun bir A/B testi uygulamadığınız anlamına gelir, ancak yine de oldukça bilgilendirici olabilir.
Test sayfanızın reklam kampanyaları için açılış sayfası olarak kullanılması durumunda, reklam ağınızın yerleşik A/B testi araçlarını (ör. Facebook Reklamları Bölünme Testi veya Google Ads Taslakları ve Denemeler) kullanmak faydalı olabilir. Bu bir seçenek değilse aynı kuruluma sahip iki kampanya kullanabilir ve hedef olarak farklı açılış sayfaları ayarlayabilirsiniz.
5. Adım: A/B testini analiz etme
Testinizi yeterince uzun bir süre çalıştırdıktan ve sonuçlar konusunda kendinize güvenmenizi sağlayacak yeterli veriye sahip olduktan sonra sıra her şeyi bir araya getirip analiz yapmaya gelir. Bunu nasıl yapacağınız testin nasıl çalıştığına göre değişir. Şimdi seçenekleri gözden geçirelim.
Testiniz, yukarıda belirtilen araçlar kullanılarak reklam açılış sayfalarında çalıştırıldıysa analiz, bir sonucu okumak kadar basit olmalıdır. Google'ın Taslaklar ve Denemeler özelliğini kullanıyorsanız ScoreCard'ı kullanarak karşılaştırmaya göz atın.
Optimizely veya Optimize gibi platformlar, sonuçları yorumlamanın ve hızın sayfalarınız üzerindeki etkisini belirlemenin kolay yolları da sunar.
Google Analytics veya benzer bir araç kullanıyorsanız raporu kendiniz çekmeniz gerekir. Neyse ki Google Analytics, özel raporlar oluşturmayı son derece kolay hale getirir. Bu nedenle buradan başlamanız gerekir. Google Analytics'e özel boyut kullanarak hız verileri gönderdiyseniz bunları nasıl ayarlayacağınızı ve özel raporlarınıza dahil edeceğinizi öğrenmek için Raporlama kılavuzuna göz atın. Raporunuzun deneme tarihini kapsadığından ve her iki varyantı da gösterecek şekilde yapılandırıldığından emin olun. Bu raporda neler yer almalıdır?
- Öncelikle, en çok önem verdiğiniz işletme metriklerini dahil etmeniz gerekir: dönüşümler, sayfa görüntülemeleri, görüntülenen reklamlar, dönüşüm oranı, e-ticaret metrikleri, tıklama oranı vb.
- Ayrıca site hızını artırmak için faydalı olan diğer standart sayfa metrikleri de hemen çıkma oranı, ortalama oturum süresi ve çıkış yüzdesidir.
Ayrıca, mobil cihazlar için filtreleme yapmanız ve botları ve kullanıcı haricindeki diğer trafiği hariç tuttuğunuzdan emin olmanız gerekebilir. Daha gelişmiş analizde bölgeye, ağlara, cihazlara, trafik kaynağına göre ve kullanıcı profillerine ve türlerine (ör. yeni kullanıcılar ile tekrar gelen ziyaretçiler) göre filtreleme de yapılır. Her kullanıcı grubu daha düşük hızlara karşı daha az veya daha fazla hassas olabilir. Bunları tanımlamak da oldukça yararlıdır.
Looker Studio (eski adıyla Data Studio) veya diğer veri görselleştirme araçları, Google Analytics gibi çeşitli veri kaynaklarını entegre etmeyi kolaylaştırır. Bu da hem analiz yapmayı kolaylaştırır hem de daha fazla destek alabilmeleri için modern bir web sitesinin işletilmesinde yer alan birçok paydaşla paylaşılabilecek gösterge tabloları oluşturur. Örneğin, Guardian kısa bir süre önce yayınlanan içerik sayfa boyutunu veya hız eşiklerini aştığında içerik ekibini uyaran ve muhtemelen kullanıcıların memnuniyetsiz olmasına yol açabilecek bir otomatik uyarı sistemi oluşturdu.
6. Adım: Çıkarımlar yapma ve sonraki adımlara karar verme
Performans ve işletme metriklerini birbirine bağlayan verileriniz olduğunda, sonuçları inceleyebilir ve çıkarım yapmaya başlayabilirsiniz.
Performansı iyileştirme ile işletme metriklerini iyileştirme arasında bir ilişki olduğunu açıkça görebiliyorsanız sonuçları özetleyin ve şirket genelinde raporlayın. Artık hız performansından "işletme dilinde" bahsedebildiğinize göre farklı paydaşların dikkatini çekme ve site hızı performansını herkesin göz önünde bulundurması daha olasıdır. Bir sonraki adım, sonuçlara dayalı olarak performans bütçeleri belirlemek ve bu bütçeleri karşılamak için yapılacak çalışmayı planlamaktır. Bu tür bir çalışmanın sağlayacağı değeri bildiğiniz için önceliği buna göre belirleyebilirsiniz.
Bir korelasyon tespit edemezseniz aşağıdaki uyarılara göz atın ve sitede başka bir yerde (örneğin, satın alma dönüşüm hunisinin tamamında veya farklı bir sayfa türünde) benzer testler yapılması gerekip gerekmediğini değerlendirin.
Uyarılar
Site hızı metrikleriyle iş metrikleri arasında belirgin bir bağlantı bulamamanızın birkaç nedeni olabilir:
- Seçilen sayfa, incelediğiniz işletme metrikleri üzerinde yeterli etkiye sahip değildir. Örneğin, ödeme sayfası çok kullanışlı veya yavaşsa daha hızlı bir ürün sayfasının dönüşüm oranları üzerinde büyük bir etkisi olmayabilir. Hemen çıkma oranları, sepete ekleme oranları veya test ettiğiniz sayfayla daha doğrudan bağlantılı başka bir metrik gibi daha alakalı metriklere bakabilirsiniz.
- İki sürümün hızı arasındaki fark yeterince belirgin değil. Bu, ölçtüğünüz RUM metriklerine göre değerlendirilmelidir.
- A/B testi mekanizmasında bir hata var. Trafik düzgün dağıtılmamış veya analizler doğru şekilde raporlanmamış olabilir. Bunu önlemek için sayfanın aynı sürümünü aynı test mekanizmasını kullanarak test ettiğiniz ve sonuçlarda fark olmadığından emin olduğunuz bir A/A testi çalıştırmayı düşünün.
- Site hızı, işletme metriklerinizi gerçekten etkilemez. Bu nadir görülen bir durumdur ancak hedef pazarınızın hız konusunda daha az hassas olduğu (ör. siteye çoğunlukla güçlü bir ağdaki güçlü cihazlardan erişildiği) veya kullanıcı talebinin çok yüksek olduğu ve seçeneklerin sınırlı olduğu durumlarda (ör. yüksek talep gören programlara özel bilet satan bir bilet satışı hizmeti) meydana gelebilir. Bunun daha hızlı bir sitenin kullanıcı deneyimini iyileştirmeyeceği ve bunun sonucunda markanın itibarını etkileyeceği anlamına gelmediğini unutmayın.
Sonuç
Sitenin tamamında hız optimizasyonları başlatmak cazip görünse de, daha hızlı bir web sitesine sahip olmanın kullanıcılarınız ve şirketiniz için ne anlama geldiğini anlamak uzun vadede genellikle daha faydalıdır. "FCP'yi 1,5 saniye iyileştirdik" demek ile "FCP'yi 1,5 saniye iyileştirdik ve dönüşüm oranlarımızı %5 artırdık" demek arasında fark var. Bu, ek çalışmalara öncelik vermenize, farklı paydaşları ikna etmenize ve site hızı performansını şirket genelinde bir çalışma haline getirmenize imkan tanır.