Site hızı ve işletme metrikleri hakkında

Site hızının işletme metrikleriniz üzerindeki etkisini değerlendirmek için A/B testinden yararlanın.

Bart Jarochowski
Bart Jarochowski
Martin Schierle
Martin Schierle
Dikla Cohen
Dikla Cohen

Son birkaç yıldır site hız performansının kullanıcı deneyiminin önemli bir parçası olduğu ve iyileştirilmesinin dönüşüm oranları ve hemen çıkma oranları gibi farklı işletme metriklerine fayda sağladığı iyice anlaşılmıştır. Bu iddiayı destekleyen birçok makale ve örnek olay yayınlandı. Örneğin, Cloudflare'ın Web Sitesi Performansı Dönüşüm Oranlarını Nasıl Etkiler?, Deloitte'un Milisaniyeler Milyonlar Kazandırır ve eBay.com'da Hızlı Alışveriş bunlardan bazılarıdır.

Hızın önemi açık olsa da birçok şirket, site hızını artıracak çalışmalara öncelik vermekte zorlanıyor. Bunun nedeni, bu çalışmaların kendi kullanıcılarını ve dolayısıyla kendi işletmelerini tam olarak nasıl etkilediğini bilmemeleridir.

Veri olmadığında site hızı çalışmalarını ertelemek ve diğer görevlere odaklanmak kolaydır. Şirketteki bazı kişilerin site hızının önemini fark etmesine rağmen bu konuda bir gerekçe oluşturamamaları ve birden fazla paydaşı buna göre yatırım yapmaya ikna edememeleri yaygın bir durumdur.

Bu makalede, site hızının işletme metrikleri üzerindeki etkisini değerlendirmek ve bu konuda daha etkili kararlar almak için A/B testinden nasıl yararlanacağınızla ilgili üst düzey bir rehberlik sunulmaktadı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 hipotezini test etmektir. Basitlik açısından, başlangıçta analiz için tek bir sayfayı tanımlamakla sınırlı kalabilirsiniz. Gelecekteki çalışmalar, bulguları doğrulamak için aynı türden birden fazla sayfayı ve ardından sitenin diğer alanlarını kapsayacak şekilde genişletilebilir. Bu adımın alt kısmında, nereden başlayacağınızla ilgili bazı öneriler verilmiştir. Sayfa seçim sürecini yönlendiren çeşitli koşullar vardır:

  • A/B testi yalnızca mobil kullanıcıların cihazlarında çalıştırılmalıdır. Dünya genelinde, destek verdiğimiz iş ortağı sitelerinin trafiğinin ortalama %50'sinden fazlası (ve bu oran giderek artıyor) mobil cihazlardan geliyor. Ancak bu oran, bölgeye ve dikey sektöre göre önemli ölçüde artabilir. Mobil cihazlar, işleme ve bellek kısıtlamaları ile daha kararsız ağlar nedeniyle daha yavaş web sitelerine karşı daha hassastır. Ayrıca, hareket halindeyken kullanım kalıpları nedeniyle hızla ilgili beklentiler daha yüksektir.
  • 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 bir dönüşüm hunisi kullanılarak analiz edilen kullanıcı yolculuğuyla ilgilidir. Örneğin, bir e-ticaret web sitesindeki kullanıcıların satın alma işlemini tamamlamak için ana sayfa, kategori sayfaları, ürün sayfaları ve ödeme sayfasında gezinmesi gerekir. Dönüşümler için optimizasyon yapıyorsanız bu sayfalardan biri iyi bir aday olabilir.

  • Sayfanın tek bir amacı olmalıdır. Sitenizin çok özel bir misyonu yoksa genellikle testiniz için ana sayfayı kullanmaktan kaçınmanız önerilir. Birçok ticari sitenin ana sayfaları, analizinizin gürültülü olmasını sağlayacak çok çeşitli işlevlere erişim portallarıdır. Örneğin, bir haber sitesinde oturum başına sayfa görüntüleme sayısı için optimizasyon yapıyorsanız sitenin ticari olmayan bölümlerini hariç tutup para kazanılan bölümlere ve makalelere odaklanmak en iyi seçenek olabilir.

  • Seçilen sayfa, istatistiksel olarak anlamlı bir sonuç elde etmek için uzun süre beklemenize gerek kalmaması için yeterli trafik almalıdır.

  • Seçilen sayfa nispeten yavaş olmalıdır. Hatta ne kadar yavaş olursa o kadar iyidir. Bu, sayfayı iyileştirmenin daha kolay olacağı anlamına gelir. Ayrıca verilerin çok daha net olması da beklenir. Hangi sayfalarınızın en yavaş olduğunu görmek için Google Analytics Hız Raporu'nu veya Search Console Core Web Vitals raporunu hızlıca tarayabilirsiniz.

  • Sayfa nispeten kararlı olmalıdır. Test tamamlanana kadar sayfaları (işletme metriklerini etkileyecek her şeyi) güncellemeyin. Dikkate alınacak dış faktörler ne kadar az olursa analiz o kadar net olur.

Yukarıdakileri kılavuz olarak kullanarak hangi sayfaların testiniz için iyi adaylar olduğunu daha net anlayabilirsiniz. Yerleşik işletme metrikleri, A/B testi ve analizlere sahip olma olasılığınız yüksek olduğundan reklam açılış sayfaları da iyi bir seçimdir. Yine de emin değilseniz sektöre göre bazı fikirler aşağıda verilmiştir:

  • İçerik web siteleri: bölümler, makaleler
  • Mağaza ön yüzleri: kategori sayfaları, ürün sayfaları
  • Medya oynatıcılar: video keşfi/arama sayfaları, video oynatma sayfası
  • Hizmetler ve Keşif (seyahat, kiralık araçlar, hizmet kaydı vb.): ilk form giriş sayfası

2. Adım: Performansı ölçün

Metrikleri ölçmenin genel olarak iki yolu vardır: laboratuvarda ve sahada. Gerçek kullanıcıların deneyimini yansıttığı için sahada metriklerin ölçülmesinin (Gerçek Kullanıcı İzleme (RUM) olarak da bilinir) daha yararlı olduğunu düşünüyoruz. RUM verilerini raporlamanıza yardımcı olabilecek kitaplıklar ve hizmetlere örnek olarak Perfume, Firebase Performance Monitoring ve Google Analytics Events verilebilir.

Kullanıcı deneyiminin farklı yönlerini yakalamayı amaçladıkları için birçok metrik arasından seçim yapabilirsiniz. Amacınızın, hızınız ile işletme 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ü ilişkiyi hangi hız metriğinin sağladığını belirlemek için birkaç hız metriğini izlemek yararlı olabilir. Genel olarak Core Web Vitals ile başlamanızı öneririz. web-vitals.js kitaplığı, sahadaki bazı Önemli Web Verilerini ölçmenize yardımcı olabilir. Ancak tarayıcı desteğinin%100 olmadığını unutmayın. Core Web Vitals'ın yanı sıra diğer Web Vitals'a da göz atmanız önerilir. "İlk Reklam Tıklama Süresi" gibi özel metrikler de tanımlayabilirsiniz.

3. adım: Hız performansı varyantları oluşturun

Bu aşamada, sayfanın mevcut sürümüyle test edilecek daha hızlı bir sürümü oluşturmak için değişiklikler uygularsınız.

Göz önünde bulundurulması gereken bazı noktalar:

  1. Kullanıcı arayüzünde veya kullanıcı deneyiminde değişiklik yapmaktan kaçının. Bir sayfanın diğerinden daha hızlı olması dışında, değişiklikler kullanıcılar tarafından fark edilmemelidir.
  2. Ölçüm de bu aşamanın önemli bir parçasıdır. Geliştirme sırasında, değişikliklerinizin performans üzerindeki etkisini belirtmek için Lighthouse gibi laboratuvar test araçları kullanılmalıdır. Bir metrikteki değişikliklerin genellikle başka bir metriği etkileyebileceğini unutmayın. Sayfalar yayınlandıktan sonra daha doğru bir değerlendirme için RUM'u kullanın.

Performans varyantları farklı şekillerde oluşturulabilir. Test amacıyla bunu mümkün olduğunca basit bir şekilde yapmanız gerekir. Aşağıda birkaç seçenek verilmiştir.

Daha hızlı bir sayfa oluşturma

Dikkate alabileceğiniz diğer optimizasyonları Hızlı yükleme süreleri ve Ön uç performansı kontrol listesinde bulabilirsiniz. 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 ve basit bir komut dosyası ekleyerek, sunucu yanıt sürelerini yavaşlatarak, daha büyük resimler yükleyerek vb. yapılabilir. Financial Times, performansın işletme metriklerini nasıl etkilediğini test ederken bu seçeneği tercih etti: Daha hızlı bir FT.com başlıklı makaleyi inceleyin.

Sayfa yükleme hızını artırma

Test sayfasının (ör. ürün ayrıntıları sayfası) çoğunlukla farklı bir sayfadan (ör. ana sayfa) bağlantısının verildiği durumlarda, test grubu için ürün sayfasını doğrudan ana sayfadan prefetching veya önceden oluşturma, sayfanın sonraki yüklemelerini hızlandırır. Bu durumda A/B testi bölme işleminin (4. adım) ana sayfada yapıldığını unutmayın. Ayrıca, tüm bunlar ilk sayfayı yavaşlatabileceğinden, bunu ölçtüğünüzden ve test sonuçlarını analiz ederken (5. adım) dikkate aldığınızdan emin olun.

4. adım: A/B testi oluşturun

Aynı sayfanın biri diğerinden daha hızlı olan iki sürümünü oluşturduktan sonra, sonraki adımda etkiyi ölçmek için trafiği bölmeniz gerekir. Genel olarak A/B testi yapmak için birçok teknik ve araç vardır ancak tüm yöntemlerin hız performansı üzerindeki etkiyi ölçmek için uygun olmadığını unutmayın.

Optimizely veya Optimize gibi bir A/B testi aracı kullanıyorsanız istemci tarafı A/B testi genellikle deneme yüklenene kadar sayfa içeriğini gizleyerek çalıştığından istemci tarafı test yerine sunucu tarafı test oluşturmanızı önemle tavsiye ederiz. Bu durumda A/B testinin kendisi, ölçmek istediğiniz metrikleri çarpıtmış olur. Yalnızca istemci tarafı test yapabiliyorsanız denemeyi farklı bir sayfada oluşturun ve trafiği bölmek için test sayfanıza yönlendiren bağlantıları değiştirin. Bu sayede test sayfası, istemci tarafı testi tarafından aşağı çekilmez.

Sunucu tarafı test aracılığıyla belirli bir ürün ayrıntıları sayfasında (PDP) performans değişikliklerini A/B testi örneği:

Sunucu tarafı test şeması

İstek arka uçta işlenir ve kullanıcılar sayfanın iki farklı sürümüne dağıtılır. Bu genel olarak iyi bir kurulum olsa da sunucu tarafı bölme işlemini ayarlamak için genellikle BT kaynaklarına ihtiyaç duyulur.

Test JavaScript'ini çalıştırmak için önceki sayfayı (aşağıdaki şemada ana sayfa) kullanan istemci tarafı test kurulumu örneğini burada bulabilirsiniz:

İstemci tarafı test şeması

Test JavaScript'i, giden bağlantıyı değiştirerek iki test grubuna söz konusu PDP'nin iki sürümünün bağlantılarını verir. Optimizely veya Optimize gibi yaygın A/B testi araçlarıyla kolayca kurulabilir ve yönetilebilir. Test JavaScript'i farklı bir sayfada çalıştığından performans testini etkilemez.

Alternatif olarak, davranışları ve performansları çok benzer olan iki sayfa da 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, doğru bir A/B testi yapmadığınız anlamına gelir ancak yine de oldukça yararlı olabilir.

Test sayfanız reklam kampanyaları için açılış sayfası olarak kullanılıyorsa reklam ağınızın yerleşik A/B testi araçlarını (ör. Facebook Ads Bölme Testi veya Google Ads Taslakları ve Denemeleri) kullanmanız yararlı olabilir. Bu seçenek sizin için uygun değilse aynı kuruluma sahip iki kampanya kullanabilir ve hedefler olarak farklı açılış sayfaları ayarlayabilirsiniz.

5. adım: A/B testini analiz edin

Testinizi yeterince uzun süre çalıştırdıktan ve sonuçlardan emin olabilecek kadar veri topladıktan sonra tüm verileri bir araya getirip analiz yapabilirsiniz. Bunu nasıl yapacağınız, testin nasıl çalıştırıldığına bağlıdır. Bu nedenle, seçenekleri inceleyelim.

Testiniz, yukarıda belirtilen araçlar kullanılarak reklam açılış sayfalarında çalıştırıldıysa analiz, bir sonucu okumak kadar kolaydır. Google'ın Taslaklar ve Denemelerini kullanıyorsanız ScoreCard'nı 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ını da sunar.

Google Analytics veya benzer bir araç kullanıyorsanız raporu kendiniz oluşturmanız gerekir. Neyse ki Google Analytics, özel raporlar oluşturmayı oldukça kolaylaştırıyor. Bu nedenle, ilk olarak buradan başlamalısınız. Özel boyut kullanarak Google Analytics'e hız verileri gönderdiyseniz bu verileri nasıl ayarlayacağınızı ve özel raporlarınıza nasıl ekleyeceğinizi öğrenmek için Raporlama kılavuzuna göz atın. Raporunuzun denemenin tarihini kapsadığından ve her iki varyantı da gösterecek şekilde yapılandırıldığından emin olun. Bu rapora neler eklenmelidir?

  • Öncelikle, en çok önemsediğiniz işletme metriklerini eklemeniz 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ı iyileştirmek için iyi bir neden olan diğer standart sayfa metrikleri arasında hemen çıkma oranı, ortalama oturum süresi ve çıkış yüzdesi de yer alır.

Ayrıca mobil cihazları filtrelemeniz ve botları ve kullanıcı olmayan diğer trafiği hariç tutmanız gerekebilir. Daha gelişmiş analizler, bölgeye, ağlara, cihazlara, trafik kaynağına ve kullanıcı profillerine ve türlerine (ör. yeni kullanıcılar ve tekrar ziyaret edenler) göre de filtreleme yapar. Her kullanıcı grubu, daha yavaş hızlara karşı az veya çok hassas olabilir. Bu grupları belirlemek de oldukça faydalıdır.

Looker Studio (eski adıyla Data Studio) veya diğer veri görselleştirme araçları, Google Analytics dahil olmak üzere çeşitli veri kaynaklarını entegre etmeyi kolaylaştırır. Bu sayede analiz yapmanın yanı sıra, daha fazla destek almak için modern bir web sitesini yönetmekle ilgili birçok paydaşla paylaşılabilen kontrol panelleri oluşturabilirsiniz. Örneğin Guardian, kısa süre önce yayınlanan içerikler sayfa boyutu veya hız eşiklerini aştığında ve kullanıcıların memnuniyetsiz olmasına neden olabilecek durumlarda yazım ekibini uyaran bir otomatik uyarı sistemi oluşturdu.

6. Adım: Sonuçlar çıkarın ve sonraki adımlara karar verin

Performans ile işletme metriklerini birbirine bağlayan verilere sahip olduktan sonra sonuçları inceleyebilir ve sonuçlardan çıkarım yapmaya başlayabilirsiniz.

Performansı iyileştirme ile işletme metriklerini iyileştirme arasında net bir ilişki görüyorsanız sonuçları özetleyin ve şirket genelinde raporlayın. Artık hız performansından "iş dilinde" bahsedebildiğiniz için farklı paydaşların dikkatini çekme ve site hız performansını herkesin radarına yerleştirme olasılığınız daha yüksek. Sonraki adım, sonuçlara göre performans bütçeleri belirlemek ve bu bütçeleri karşılayacak çalışmaları planlamaktır. Bu tür çalışmaların sağlayacağı değeri bildiğiniz için öncelikleri buna göre belirleyebilirsiniz.

Bir korelasyon belirleyemezseniz aşağıdaki uyarılara göz atın ve sitenin başka bir yerinde (ör. satın alma hunisinin tamamında veya farklı bir sayfa türünde) benzer testlerin çalıştırılıp çalıştırılmaması gerektiğini değerlendirin.

Uyarılar

Site hızı metrikleri ile işletme metrikleri arasında önemli bir korelasyon bulunamamasının birkaç nedeni olabilir:

  • Seçilen sayfa, incelediğiniz işletme metrikleri üzerinde yeterince etkili değil. Örneğin, ödeme sayfası çok kullanıcı dostu değilse veya yavaşsa daha hızlı bir ürün sayfası dönüşüm oranları üzerinde büyük bir etki göstermeyebilir. Hemen çıkma oranları, sepete ekleme oranları veya test ettiğiniz sayfayla daha doğrudan bağlantılı diğer metrikler gibi daha alakalı metrikleri incelemeyi düşünebilirsiniz.
  • İki sürüm arasındaki hız farkı yeterince önemli 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ılmayabilir veya analizler doğru şekilde raporlanmayabilir. Bu sorunun olmadığını doğrulamak için, aynı test mekanizmasını kullanarak bir sayfanın aynı sürümünü test ettiğiniz ve bu sırada sonuçlarda herhangi bir fark olmadığından emin olduğunuz bir A/B testi çalıştırabilirsiniz.
  • Site hızı, işletme metriklerinizi etkilemez. Bu durum nadirdir ancak hedef pazarınızın hıza karşı daha az duyarlı olduğu (ör. siteye çoğunlukla güçlü bir ağdaki güçlü cihazlardan erişiliyor) veya kullanıcı talebinin çok yüksek olduğu ve seçeneklerin sınırlı olduğu durumlarda (ör. yalnızca yoğun talep gören gösteriler için bilet satan bir bilet hizmeti) ortaya çıkabilir. Bunun, daha hızlı bir sitenin kullanıcı deneyimini iyileştirmeyeceği ve sonuç olarak marka itibarını etkilemeyeceği anlamına gelmediğini unutmayın.

Sonuç

Sitenin tamamında hız optimizasyonları başlatmak cazip olsa da uzun vadede genellikle daha faydalı olan, önce kullanıcılarınız ve şirketiniz için daha hızlı bir web sitesine sahip olmanın ne anlama geldiğini anlamaktır. Bu, "FCP'yi 1,5 saniye iyileştirdim" ile "FCP'yi 1,5 saniye iyileştirdim ve bu da dönüşüm oranlarımızı %5 artırdı" arasındaki farktır. Bu sayede, daha fazla çalışmaya öncelik verebilir, farklı paydaşlardan destek alabilir ve site hızı performansını şirket genelinde bir çaba haline getirebilirsiniz.