Arayüzde Yanıt Süresi: 0,1 - 1 - 10 Saniye Sınırları

Bir arayüzün hızlı sayılması için kaç milisaniyede cevap vermesi gerektiği kırk yılı aşkın süredir aynı üç sayıyla anlatılıyor: 0,1 saniye, 1 saniye, 10 saniye. Bu sayılar ağ hızıyla değil insan algısının çalışma biçimiyle ilgili, o yüzden donanım geliştikçe eskimiyorlar. Zor kısım sınırları ezberlemek değil; hangi ölçümün onlara karşılık geldiğini bilmek ve sınır aşıldığında ekranda ne olacağına karar vermek.

Üç sayı nereden geliyor

Sınırlar Robert B. Miller'ın 1968 tarihli tepki süresi çalışmasına dayanıyor, bugünkü yaygın hâlini Nielsen Norman Group'un özetinden tanıyoruz. Her biri farklı bir algısal eşiği işaretliyor.

0,1 saniye anındalık eşiği. Bu sürenin altında kalan tepki, kullanıcıya sistemin cevap verdiğini değil, nesneyi doğrudan kendisinin hareket ettirdiğini hissettirir. Sürükle bırak, buton basma hâli, sekme değişimi bu kategoride. 60 Hz bir ekranda 100 milisaniye yaklaşık altı kare demek; yani gecikme kullanıcıya görünmeden önce tarayıcının altı kare çizme payı var.

1 saniye düşünce akışının kopmadığı üst sınır. Kullanıcı gecikmeyi fark eder, ama ne yapmak istediğini unutmaz. Bu aralıkta ekstra bir gösterge koymak genellikle zarar verir, çünkü kullanıcının fark etmediği bir bekleme varmış izlenimi yaratır.

10 saniye dikkatin dağıldığı yer. Bu süreyi aşan işlemlerde kullanıcı başka sekmeye geçer, telefonuna bakar, bazen sayfayı kapatır. On saniyeden uzun sürecek bir işlemin yüzdelik ilerleme göstergesi olmak zorunda, çünkü geri dönen kullanıcının "hâlâ çalışıyor mu, donmuş mu" sorusuna cevap verecek tek şey odur.

Sınırlar sayfaya değil, tek tek etkileşimlere ait

Yaygın hata bu üç sayıyı sayfa açılış süresiyle eşleştirmek. Oysa eşikler her etkileşim için ayrı ayrı geçerli. Üç saniyede açılan ama her filtre tıklamasına 80 milisaniyede cevap veren bir liste sayfası, yarım saniyede açılıp her sıralama işleminde 1,5 saniye donan bir sayfadan çok daha hızlı hissettirir. Kullanıcı açılışı bir kez yaşar, etkileşimi yüzlerce kez.

Bu yüzden ölçüm listesi sayfa bazlı değil eylem bazlı kurulmalı: arama kutusuna yazarken öneri gelme süresi, forma kaydet dedikten sonra geri bildirim süresi, menü açılma süresi.

Ortalama yanıt süresi sizi yanıltır

Tek bir ortalama sayı bu eşiklerle birlikte kullanılamaz. Yirmi isteğin on dokuzu 200 milisaniyede, biri 3 saniyede dönüyorsa ortalama 340 milisaniye çıkar. Rapora bakan kişi her şeyin 1 saniye sınırının çok altında olduğunu görür. Gerçekte her yirmi tıklamadan biri kullanıcının dikkatini kaçırıyordur ve şikâyetler de tam oradan gelir.

Eşikler algıyla ilgili olduğu için ölçümün de en kötü deneyimi yakalaması gerekir. p95 ve p99 değerlerini takip edin; ortalamayı yalnızca eğilim değişikliğini görmek için tutun. Google Search Console gibi araçların saha verisi burada laboratuvar testinden daha kullanışlı, çünkü gerçek cihaz ve gerçek bağlantı çeşitliliğini içerir.

Göstergeyi ne zaman göstermeli, ne zaman göstermemeli

Yükleniyor göstergesinin kendisi de bir gecikme kaynağı gibi algılanır. 300 milisaniyede biten bir işlem için spinner koyarsanız, gösterge ekrana gelir ve neredeyse aynı anda kaybolur; kullanıcı bunu hız olarak değil, ekranın titremesi olarak okur.

Çözüm iki kurala iniyor. Göstergeyi hemen değil, yaklaşık 400 milisaniye sonra göster. Bir kez gösterdiysen en az 500 milisaniye ekranda tut. Bunu üçüncü parti bir kütüphaneye havale etmene gerek yok: göstergeyi bir zamanlayıcının arkasına al, işlem süre dolmadan biterse zamanlayıcıyı iptal et, gösterge hiç ekrana gelmesin. Birkaç satırlık iş, ve arayüzün en çok şikâyet alan titremesini ortadan kaldırır.

Sürenin tahmin edilebildiği yerde yüzdelik çubuk, tahmin edilemediği yerde belirsiz bir hareketli simge kullanın. Sahte yüzde, yani ilerlemeyi bilmediğiniz hâlde çubuğu yavaşça doldurmak, ilk seferde işe yarar; kullanıcı çubuğun %90'da takıldığını bir kez gördükten sonra bir daha o çubuğa güvenmez.

Yanıt süresini gerçekten kısaltan şeyler

Ölçüm yerli yerine oturduktan sonra sıra asıl maliyeti bulmaya gelir. Sık karşılaşılan kaynaklar sırasıyla şunlar:

• Gereğinden büyük gönderilen görseller. GIFsicle, JPEGtran ve OptiPNG gibi araçlarla yapılan kayıpsız sıkıştırma hâlâ en ucuz kazanç.
• Sıkıştırılmadan gönderilen metin kaynakları. Gzip veya Brotli açık değilse HTML, CSS ve JavaScript birkaç katı büyüklükte geziyor demektir.
• İlk ekranda gerekmeyen her şeyin peşinen yüklenmesi. Ekranın altındaki görseller ve hemen kullanılmayan modüller ertelenebilir.
• Tek bir tıklamanın arkasında zincirlenmiş istekler. Sıralı üç istek, aynı işi yapan paralel üç isteğin üç katı sürer.

Uzun işlemde kullanıcıya bırakılacak kontrol

On saniyeyi aşan işlemlerde gösterge tek başına yetmez. Kullanıcı hangi adımda olduğunu bilmeli, işlemi durdurabilmeli, bittiğinde ne yapacağını görebilmeli. Rapor üretimi, toplu yükleme, ödeme onayı gibi akışlarda iptal düğmesinin olmaması, kullanıcının sayfayı yenilemesine yol açar; bu da çoğu zaman işlemin yarıda kalmasından daha kötü bir sonuç doğurur.

Beklemeyi gizlemeye çalışmak yerine açıkça anlatmak, aynı süreyi ölçülebilir biçimde daha kısa hissettirir.