RAIL, performans hakkında düşünmek için bir yapı sağlayan kullanıcı odaklı bir performans modelidir. Model, kullanıcının deneyimini temel işlemlere (ör. dokunma, kaydırma, yükleme) ayırır ve her biri için performans hedefleri belirlemenize yardımcı olur.
RAIL, web uygulaması yaşam döngüsünün dört farklı yönünü ifade eder: yanıt (response), animasyon (animation), boşta kalma (idle) ve yükleme (load). Kullanıcıların bu bağlamların her birinde farklı performans beklentileri vardır. Bu nedenle performans hedefleri, bağlama ve kullanıcıların gecikmeleri nasıl algıladığına dair kullanıcı deneyimi araştırmasına göre tanımlanır.
Kullanıcıya odaklanma
Performans çalışmalarınızda kullanıcıları odak noktası haline getirin. Aşağıdaki tabloda, kullanıcıların performans gecikmelerini nasıl algıladığına dair temel metrikler açıklanmaktadır:
Performans gecikmeleriyle ilgili kullanıcı algısı| 0-16 ms | Kullanıcılar hareketleri takip etmede çok iyidir ve animasyonların akıcı olmaması hoşlarına gitmez. Saniyede 60 yeni kare oluşturulduğu sürece animasyonları akıcı olarak algılarlar. Tarayıcının yeni kareyi ekrana çizmesi için gereken süre de dahil olmak üzere kare başına 16 ms'dir. Bu da uygulamaya bir kare oluşturması için yaklaşık 10 ms süre bırakır. |
| 0 ila 100 ms | Bu zaman aralığında kullanıcı işlemlerine yanıt verin. Böylece kullanıcılar sonucu anında almış gibi hisseder. Daha uzun sürdüğünde ise eylem ile tepki arasındaki bağlantı kopar. |
| 100 ila 1.000 ms | Bu pencerede, her şey doğal ve sürekli bir görev ilerlemesinin parçası gibi görünür. Web'deki çoğu kullanıcı için sayfaları yüklemek veya görünümleri değiştirmek bir görevi temsil eder. |
| 1.000 ms veya daha fazla | 1.000 milisaniyeden (1 saniye) sonra kullanıcılar yaptıkları işe odaklanamaz. |
| 10.000 ms veya daha fazla | 10.000 milisaniyeden (10 saniye) sonra kullanıcılar hayal kırıklığına uğrar ve görevleri bırakma olasılıkları artar. Bu kişiler daha sonra geri dönebilir veya dönmeyebilir. |
Hedefler ve yönergeler
RAIL bağlamında hedefler ve kurallar terimleri belirli anlamlara sahiptir:
Hedefler: Kullanıcı deneyimiyle ilgili temel performans metrikleri. Örneğin, 100 milisaniyeden kısa sürede boyamak için dokunun. İnsan algısı nispeten sabit olduğundan bu hedeflerin yakın zamanda değişmesi beklenmiyor.
Kurallar Hedeflerinize ulaşmanıza yardımcı olan öneriler. Bunlar, mevcut donanım ve ağ bağlantısı koşullarına özel olabilir ve bu nedenle zaman içinde değişebilir.
Yanıt: Etkinlikleri 50 ms'den kısa sürede işleme
Hedef: Kullanıcı girişiyle başlatılan bir geçişi 100 ms içinde tamamlayarak kullanıcıların etkileşimlerin anlık olduğunu hissetmesini sağlayın.
Kurallar:
100 ms içinde görünür bir yanıt sağlamak için kullanıcı girişi etkinliklerini 50 ms içinde işleyin. Bu, düğmeleri tıklama, form kontrollerini değiştirme veya animasyonları başlatma gibi çoğu giriş için geçerlidir. Bu durum, dokunarak sürükleme veya kaydırma işlemleri için geçerli değildir.
Bu durum kulağa mantıksız gelse de kullanıcı girişine hemen yanıt vermek her zaman doğru bir yaklaşım değildir. Bu 100 ms'lik pencereyi diğer maliyetli işlemleri yapmak için kullanabilirsiniz ancak kullanıcıyı engellememeye dikkat edin. Mümkünse arka planda çalışın.
Tamamlanması 50 ms'den uzun süren işlemler için her zaman geri bildirim sağlayın.
50 ms mi yoksa 100 ms mi?
Hedef, girişe 100 ms'den kısa sürede yanıt vermek. Peki neden bütçemiz yalnızca 50 ms? Bunun nedeni, genellikle giriş işleme ek olarak başka işlemlerin de yapılması ve bu işlemlerin, kabul edilebilir giriş yanıtı için ayrılan sürenin bir kısmını kullanmasıdır. Bir uygulama, boşta kalma süresi boyunca önerilen 50 ms'lik parçalar halinde çalışıyorsa bu, girişin bu çalışma parçalarından biri sırasında gerçekleşmesi durumunda 50 ms'ye kadar sıraya alınabileceği anlamına gelir. Bunu göz önünde bulundurarak, gerçek giriş işleme için yalnızca kalan 50 ms'nin kullanılabileceğini varsaymak güvenlidir. Bu etki, aşağıdaki şemada görselleştirilmiştir. Şemada, boşta kalma görevi sırasında alınan girişin nasıl sıraya alındığı ve mevcut işlem süresinin nasıl kısaldığı gösterilmektedir:
Animasyon: 10 ms içinde bir kare üretme
Hedefler:
Animasyondaki her kareyi 10 ms veya daha kısa sürede oluşturun. Teknik olarak, her kare için maksimum bütçe 16 ms'dir (1000 ms / saniyede 60 kare ≈ 16 ms). Ancak tarayıcıların her kareyi oluşturmak için yaklaşık 6 ms'ye ihtiyacı vardır. Bu nedenle, kare başına 10 ms kuralı geçerlidir.
Görsel akıcılığı hedefleyin. Kullanıcılar, kare hızlarının değiştiğini fark eder.
Kurallar:
Animasyonlar gibi yüksek baskı noktalarında, yapabileceğiniz yerlerde hiçbir şey yapmamak, yapamayacağınız yerlerde ise kesinlikle en az şeyi yapmak önemlidir. Mümkün olduğunda, 60 FPS'ye ulaşma şansınızı en üst düzeye çıkarmak için pahalı işlemleri önceden hesaplamak üzere 100 ms yanıt süresinden yararlanın.
Çeşitli animasyon optimizasyonu stratejileri için Oluşturma Performansı'na bakın.
- Girişler ve çıkışlar, ara animasyonlar ve yükleme göstergeleri gibi görsel animasyonlar.
- Kaydırma Buna, kullanıcının kaydırmaya başlayıp bırakması ve sayfanın kaydırmaya devam etmesi anlamına gelen hızlı kaydırma da dahildir.
- Sürükleme Animasyonlar genellikle kullanıcının etkileşimlerini (ör. haritayı kaydırma veya yakınlaştırmak için parmakla sıkıştırma) takip eder.
Boşta: Boşta kalma süresini en üst düzeye çıkarın
Hedef: Sayfanın kullanıcı girişine 50 ms içinde yanıt verme olasılığını artırmak için boşta kalma süresini en üst düzeye çıkarın.
Kurallar:
Boş zamanı, ertelenen işleri tamamlamak için kullanın. Örneğin, ilk sayfa yüklemesi için mümkün olduğunca az veri yükleyin, ardından geri kalanını yüklemek için boşta kalma süresini kullanın.
Boşta kalma süresinde 50 ms veya daha kısa sürede iş yapma Bu sürenin aşılması, uygulamanın 50 ms içinde kullanıcı girişine yanıt verme özelliğini etkileme riski oluşturur.
Kullanıcı, boşta kalma süresi boyunca bir sayfayla etkileşim kurarsa kullanıcı etkileşimi her zaman en yüksek önceliğe sahip olmalı ve boşta kalma süresi boyunca yapılan çalışmayı kesintiye uğratmalıdır.
Yükleme: İçeriği 5 saniyeden kısa sürede sunma ve etkileşimli hale getirme
Sayfalar yavaş yüklendiğinde kullanıcıların dikkati dağılır ve kullanıcılar görevi bozuk olarak algılar. Hızlı yüklenen sitelerde ortalama oturum süresi daha uzun, hemen çıkma oranı daha düşük ve reklam görüntülenebilirliği daha yüksektir.
Hedefler:
Kullanıcılarınızın cihaz ve ağ özelliklerine göre hızlı yükleme performansı için optimizasyon yapın. Şu anda, ilk yüklemeler için iyi bir hedef, sayfayı yüklemek ve yavaş 3G bağlantıları olan orta sınıf mobil cihazlarda 5 saniye veya daha kısa sürede etkileşimli hale gelmektir.
Sonraki yüklemelerde, sayfanın 2 saniyeden kısa sürede yüklenmesi iyi bir hedeftir.
Kurallar:
Yükleme performansınızı, kullanıcılarınız arasında yaygın olan mobil cihazlarda ve ağ bağlantılarında test edin. Kullanıcılarınızın bağlantı dağılımını öğrenmek için Chrome Kullanıcı Deneyimi Raporu'nu kullanabilirsiniz. Siteniz için veriler mevcut değilse The Mobile Economy 2019, iyi bir küresel temel olarak Moto G4 gibi orta sınıf bir Android telefon ve yavaş bir 3G ağı (400 ms RTT ve 400 kbps aktarım hızı olarak tanımlanır) kullanılmasını önerir. Bu kombinasyon WebPageTest'te kullanılabilir.
Normal mobil kullanıcınızın cihazı 2G, 3G veya 4G bağlantısı kullandığını iddia etse de paket kaybı ve ağ varyansı nedeniyle etkili bağlantı hızının genellikle çok daha yavaş olduğunu unutmayın.
Tam yükleme algısı oluşturmak için her şeyi 5 saniyeden kısa sürede yüklemeniz gerekmez. Resimleri geç yükleme, JavaScript paketlerini kod bölme ve web.dev'de önerilen diğer optimizasyonları kullanabilirsiniz.
RAIL'i ölçmeye yönelik araçlar
RAIL ölçümlerinizi otomatikleştirmenize yardımcı olacak birkaç araç vardır. Hangisini kullanacağınız, ihtiyacınız olan bilgi türüne ve tercih ettiğiniz iş akışı türüne bağlıdır.
Chrome Geliştirici Araçları
Chrome Geliştirici Araçları, sayfanız yüklenirken veya çalışırken olan her şeyle ilgili ayrıntılı analizler sağlar. Performans paneli kullanıcı arayüzünü tanımak için Çalışma Zamanı Performansını Analiz Etmeye Başlama başlıklı makaleyi inceleyin.
Aşağıdaki DevTools özellikleri özellikle önemlidir:
Daha az güçlü bir cihazı simüle etmek için CPU'nuzu kısıtlayın.
Daha yavaş bağlantıları simüle etmek için ağı sınırlayın.
Kaydınız sırasında ana iş parçacığında gerçekleşen her etkinliği görüntülemek için Ana iş parçacığı etkinliğini görüntüleyin.
Etkinlikleri en çok zaman alanlara göre sıralamak için ana ileti dizisi etkinliklerini tabloda görüntüleyin.
Animasyonlarınızın gerçekten sorunsuz çalışıp çalışmadığını ölçmek için saniyedeki kare sayısını (FPS) analiz edin.
Performans İzleyici ile CPU kullanımını, JS yığın boyutunu, DOM düğümlerini, saniyedeki düzen sayısını ve daha fazlasını gerçek zamanlı olarak izleyin.
Ağ bölümünü kullanarak kayıt yaparken gerçekleşen ağ isteklerini görselleştirin.
Sayfa yüklenirken veya animasyon tetiklenirken sayfanın tam olarak nasıl göründüğünü tekrar oynatmak için kayıt sırasında ekran görüntüsü alma
Bir kullanıcı sayfayla etkileşim kurduktan sonra sayfada neler olduğunu hızlıca belirlemek için görüntüleme etkileşimlerini kullanın.
Potansiyel olarak sorunlu bir dinleyici her tetiklendiğinde sayfayı vurgulayarak kaydırma performansıyla ilgili sorunları anında tespit edin.
Animasyonlarınızın performansına zarar verebilecek maliyetli boyama etkinliklerini belirlemek için boyama etkinliklerini gerçek zamanlı olarak görüntüleyin.
Deniz Feneri
Lighthouse; Chrome Geliştirici Araçları'nda, PageSpeed Insights'ta, Chrome uzantısı olarak, Node.js modülü olarak ve WebPageTest'te kullanılabilir. Araca bir URL verirsiniz. Araç, yavaş bir 3G bağlantısı olan orta seviye bir cihazı simüle eder, sayfada bir dizi denetim gerçekleştirir ve ardından yükleme performansıyla ilgili bir raporun yanı sıra iyileştirme önerileri sunar.
Aşağıdaki denetimler özellikle önemlidir:
Yanıt
Maksimum Olası İlk Giriş Gecikmesi. Ana iş parçacığının boşta kalma süresine göre uygulamanızın kullanıcı girişine ne kadar sürede yanıt vereceğini tahmin eder.
Kaydırma performansını artırmak için pasif işleyicileri kullanmıyor.
Toplam Engelleme Süresi. Bir sayfanın, kullanıcı girişine (ör. fare tıklamaları, ekrana dokunma veya klavyeye basma) yanıt vermesinin engellendiği toplam süreyi ölçer.
Etkileşime Hazır Olma Süresi. Kullanıcının tüm sayfa öğeleriyle tutarlı bir şekilde etkileşim kurabildiği zamanı ölçer.
Yükleme
Sayfa ve start_url değerlerini kontrol eden bir hizmet çalışanı kaydedilmiyor. Bir hizmet çalışanı, kullanıcının cihazındaki ortak kaynakları önbelleğe alarak ağ üzerinden kaynak getirmek için harcanan süreyi azaltabilir.
Ekran dışındaki resimleri erteleyin. Ekran dışındaki resimlerin yüklenmesini, ihtiyaç duyulana kadar erteleyin.
Görselleri uygun şekilde boyutlandırın. Mobil görüntü alanında oluşturulan boyuttan önemli ölçüde büyük resimler yayınlamayın.
Aşırı büyük bir DOM boyutundan kaçının. Yalnızca sayfayı oluşturmak için gereken DOM düğümlerini göndererek ağ baytlarını azaltın.
WebPageTest
WebPageTest, web sayfalarına erişmek ve zamanlama metriklerini toplamak için gerçek tarayıcıları kullanan bir web performansı aracıdır. Yavaş bir 3G bağlantısı olan gerçek bir Moto G4 cihazda sayfanın yükleme performansıyla ilgili ayrıntılı bir rapor almak için webpagetest.org/easy adresine bir URL girin. Lighthouse denetimi içerecek şekilde de yapılandırabilirsiniz.
Özet
RAIL, bir web sitesinin kullanıcı deneyimine farklı etkileşimlerden oluşan bir yolculuk olarak bakmak için kullanılan bir yöntemdir. Kullanıcı deneyimi üzerinde en büyük etkiye sahip performans hedefleri belirlemek için kullanıcıların sitenizi nasıl algıladığını anlayın.
Kullanıcıya odaklanma
Kullanıcı girişine 100 ms'den kısa sürede yanıt verin.
Animasyon yaparken veya kaydırırken 10 ms'den kısa sürede bir kare oluşturun.
Ana iş parçacığı boşta kalma süresini en üst düzeye çıkarın.
Etkileşimli içerikleri 5.000 ms'den kısa sürede yükleyin.