Shopify hız denetimi: ölçümden düzeltmeye

Hız puanı kovalamak yerine gerçek kullanıcı verisine bakmak, sorunu doğru yerde aramak ve düzeltmeleri kazanca göre sıralamak. Denetimi nasıl yürüttüğümüzü adım adım yazdık.

Mağaza hızı konuşulurken sohbet neredeyse her zaman aynı yerde başlıyor: bir hız testi açılıyor, çıkan puan konuşuluyor. Oysa o puan tek bir cihazda, tek bir bağlantıda, tek bir sayfa için üretilmiş bir tahmin. Gerçek müşterilerinizin deneyimiyle ilişkisi sınırlı.

Bu yazı, hız denetimini nasıl yürüttüğümüzü anlatıyor: neyi ölçüyoruz, hangi sırayla bakıyoruz ve hangi düzeltmenin gerçekten karşılığı oluyor. Mağazaları yavaşlatan tekil sebepleri ayrı bir yazıda toplamıştık; burada yöntemin kendisi var.

Önce doğru veriye bakmak: saha mı, laboratuvar mı?

İki tür hız verisi var ve karıştırıldıklarında yanlış işlere haftalar harcanıyor.

Denetime her zaman saha verisiyle başlıyoruz. Laboratuvar testinde kırmızı görünen ama gerçek kullanıcı verisinde sorun üretmeyen kalemlerle uğraşmak, en yaygın vakit kaybı.

Hangi sayfalar ölçülür?

Ana sayfa üzerinden yürütülen hız çalışmaları eksik kalıyor, çünkü ciro ana sayfada üretilmiyor. Denetimde dört sayfa tipini ayrı ayrı ölçüyoruz:

Her sayfa tipi için mobil ve masaüstü ayrı raporlanır. Türkiye'deki mağazalarda trafiğin büyük kısmı mobil olduğu için, masaüstünde iyi görünen bir mağaza pratikte yavaş olabiliyor.

Neye bakıyoruz?

Tek bir puan yerine kullanıcının hissettiği üç şeye bakıyoruz: sayfa ne zaman görünür hale geliyor, ne zaman kullanılabilir oluyor ve görüntü oynuyor mu.

Son maddeyi hedef haline getirmemek önemli. Sayfa ağırlığını düşürmek başlı başına bir amaç değil; amaç, kullanıcının beklediği anı kısaltmak.

Sorunun kaynağını ayırmak

Ölçüm sorunu gösterir, kaynağı göstermez. Kaynağı ayırmak için yükleme dökümüne bakıyoruz ve yükü dört gruba ayırıyoruz:

Deneyimimizde en büyük kazanç neredeyse her zaman son iki gruptan geliyor. Tema kodunu optimize etmek için harcanan emek, sayfada dört ayrı ölçümleme betiği varken karşılığını vermiyor.

Düzeltmeleri sıralamak: kazanç ve risk

Denetimin çıktısı bir sorun listesi değil, sıralanmış bir iş listesi olmalı. Her maddeyi iki eksende puanlıyoruz: beklenen kazanç ve uygulama riski.

Son satır bilinçli bir tercih. Hız puanını yükselten ama gerçek kullanıcı deneyimini değiştirmeyen müdahaleler var; rapor güzelleşiyor, ciro değişmiyor. Bunları önermiyoruz.

Uygulama yığını: en sık bulunan kalem

Denetimlerde en çok kazanç üreten başlık uygulama temizliği. Baktığımız yerler:

Bu temizliği yaparken kural şu: önce yedek, sonra tek tek kaldırma, her adımda ölçüm. Toplu temizlik yapılan projelerde bir şey bozulduğunda sebebini bulmak zorlaşıyor.

Görseller: en ucuz kazanç

Ölçüm sonrası: kazancı doğrulamak

Denetimin son adımı, yapılan işin gerçekten karşılığı olup olmadığını göstermek. Yalnızca hız metriğine bakmak yetmiyor.

Son madde ölçüm disiplininin özeti. Aynı hafta içinde hem hız düzeltmesi hem tema değişikliği hem yeni kampanya yapılan mağazalarda, iyileşmenin neyden geldiğini kimse söyleyemez.

Ne zaman hız çalışması yapılmaz?

Dürüst olalım: her mağazanın hız çalışmasına ihtiyacı yok. Şu durumlarda önce başka bir şey yapılmalı:

Bu değerlendirmeyi denetimin başında yapıyoruz. Çalışmanın karşılığının düşük olacağını düşünüyorsak, projeyi almadan önce bunu söylüyoruz.

Yapmadığımız şeyler

Özet

Hız denetimi bir test aracının puanını yükseltme işi değil; gerçek kullanıcının beklediği süreyi kısaltma işi. Saha verisiyle başlamak, sayfa tiplerini ayırmak, yükü dört gruba bölmek ve düzeltmeleri kazanca göre sıralamak yöntemin tamamı.

Mağaza adresinizi ve analitik erişiminizi paylaşın; saha verinizle başlayıp sayfa tipi bazında bir denetim çıkaralım. Mevcut durumunuzda çalışmanın karşılığı düşükse, bunu da açıkça söyleriz.