RAIL adalah model performa yang berfokus pada pengguna yang memberikan struktur untuk memikirkan performa. Model ini menguraikan pengalaman pengguna menjadi tindakan utama (misalnya, ketuk, scroll, muat) dan membantu Anda menentukan sasaran performa untuk setiap tindakan tersebut.
RAIL adalah singkatan dari empat aspek berbeda dari siklus proses aplikasi web: respons, animasi, tidak ada aktivitas, dan pemuatan. Pengguna memiliki ekspektasi performa yang berbeda untuk setiap konteks ini, sehingga sasaran performa ditentukan berdasarkan konteks dan riset UX tentang cara pengguna memandang penundaan.
Fokus pada pengguna
Jadikan pengguna sebagai titik fokus upaya performa Anda. Tabel di bawah menjelaskan metrik utama tentang cara pengguna melihat penundaan performa:
Persepsi pengguna terhadap penundaan performa| 0 hingga 16 mdtk | Pengguna sangat mahir dalam melacak gerakan, dan mereka tidak menyukai animasi yang tidak lancar. Mereka menganggap animasi berjalan lancar selama 60 frame baru dirender setiap detik. Artinya, 16 md per frame, termasuk waktu yang diperlukan browser untuk menggambar frame baru ke layar, sehingga aplikasi memiliki waktu sekitar 10 md untuk menghasilkan frame. |
| 0 hingga 100 md | Respons tindakan pengguna dalam jangka waktu ini dan pengguna akan merasa hasilnya langsung terlihat. Jika lebih lama, hubungan antara tindakan dan reaksi akan terputus. |
| 100 hingga 1.000 md | Dalam jendela ini, berbagai hal terasa sebagai bagian dari progres tugas yang alami dan berkelanjutan. Bagi sebagian besar pengguna di web, memuat halaman atau mengubah tampilan merupakan sebuah tugas. |
| 1.000 md atau lebih | Setelah 1.000 milidetik (1 detik), pengguna kehilangan fokus pada tugas yang sedang mereka lakukan. |
| 10.000 md atau lebih | Lebih dari 10.000 milidetik (10 detik), pengguna akan merasa frustrasi dan cenderung mengabaikan tugas. Mereka mungkin akan kembali lagi nanti atau tidak. |
Sasaran dan pedoman
Dalam konteks RAIL, istilah sasaran dan panduan memiliki arti khusus:
Sasaran. Metrik performa utama yang terkait dengan pengalaman pengguna. Misalnya, ketuk untuk merender dalam waktu kurang dari 100 milidetik. Karena persepsi manusia relatif konstan, sasaran ini kemungkinan tidak akan berubah dalam waktu dekat.
Panduan. Rekomendasi yang membantu Anda mencapai sasaran. Rekomendasi ini mungkin khusus untuk kondisi koneksi jaringan dan hardware saat ini, sehingga dapat berubah seiring waktu.
Respons: Memproses peristiwa dalam waktu kurang dari 50 md
Sasaran: Selesaikan transisi yang dimulai oleh input pengguna dalam waktu 100 md, sehingga pengguna merasa interaksinya instan.
Panduan:
Untuk memastikan respons yang terlihat dalam waktu 100 md, proses peristiwa input pengguna dalam waktu 50 md. Hal ini berlaku untuk sebagian besar input, seperti mengklik tombol, mengalihkan kontrol formulir, atau memulai animasi. Hal ini tidak berlaku untuk seret atau scroll sentuh.
Meskipun mungkin terdengar berlawanan dengan intuisi, merespons input pengguna secara langsung tidak selalu merupakan keputusan yang tepat. Anda dapat menggunakan periode 100 md ini untuk melakukan pekerjaan berat lainnya, tetapi berhati-hatilah agar tidak memblokir pengguna. Jika memungkinkan, lakukan pekerjaan di latar belakang.
Untuk tindakan yang memerlukan waktu lebih dari 50 md untuk diselesaikan, selalu berikan masukan.
50 md atau 100 md?
Tujuannya adalah merespons input dalam waktu kurang dari 100 md, jadi mengapa anggaran kita hanya 50 md? Hal ini karena umumnya ada pekerjaan lain yang dilakukan selain penanganan input, dan pekerjaan tersebut menghabiskan sebagian waktu yang tersedia untuk respons input yang dapat diterima. Jika aplikasi melakukan pekerjaan dalam potongan 50 md yang direkomendasikan selama waktu tidak ada aktivitas, berarti input dapat diantrekan hingga 50 md jika terjadi selama salah satu potongan pekerjaan tersebut. Dengan mempertimbangkan hal ini, dapat diasumsikan bahwa hanya sisa 50 md yang tersedia untuk penanganan input yang sebenarnya. Efek ini divisualisasikan dalam diagram di bawah yang menunjukkan cara input yang diterima selama tugas tidak ada aktivitas dimasukkan ke dalam antrean, sehingga mengurangi waktu pemrosesan yang tersedia:
Animasi: Menghasilkan frame dalam 10 md
Sasaran:
Buat setiap frame dalam animasi dalam waktu 10 md atau kurang. Secara teknis, anggaran maksimum untuk setiap frame adalah 16 md (1000 md / 60 frame per detik ≈ 16 md), tetapi browser memerlukan sekitar 6 md untuk merender setiap frame, sehingga panduannya adalah 10 md per frame.
Targetkan kelancaran visual. Pengguna akan menyadari jika kecepatan frame bervariasi.
Panduan:
Dalam titik tekanan tinggi seperti animasi, kuncinya adalah tidak melakukan apa pun jika memungkinkan, dan melakukan hal yang sangat minimal jika tidak memungkinkan. Jika memungkinkan, manfaatkan respons 100 md untuk melakukan pra-penghitungan pekerjaan yang berat sehingga Anda memaksimalkan peluang mencapai 60 fps.
Lihat Performa Rendering untuk berbagai strategi pengoptimalan animasi.
- Animasi visual, seperti masuk dan keluar, tween, dan indikator pemuatan.
- Men-scroll. Hal ini mencakup flinging, yaitu saat pengguna mulai men-scroll, lalu melepaskannya, dan halaman terus di-scroll.
- Menarik. Animasi sering kali mengikuti interaksi pengguna, seperti menggeser peta atau mencubit untuk melakukan zoom.
Tidak ada aktivitas: Memaksimalkan waktu tidak ada aktivitas
Sasaran: Maksimalkan waktu tidak ada aktivitas untuk meningkatkan peluang halaman merespons input pengguna dalam waktu 50 md.
Panduan:
Gunakan waktu tidak ada aktivitas untuk menyelesaikan pekerjaan yang ditangguhkan. Misalnya, untuk pemuatan halaman awal, muat data sesedikit mungkin, lalu gunakan waktu tidak ada aktivitas untuk memuat sisanya.
Lakukan pekerjaan selama waktu tidak ada aktivitas dalam 50 md atau kurang. Jika lebih lama, Anda berisiko mengganggu kemampuan aplikasi untuk merespons input pengguna dalam waktu 50 md.
Jika pengguna berinteraksi dengan halaman selama pekerjaan waktu tidak ada aktivitas, interaksi pengguna harus selalu diprioritaskan dan menghentikan pekerjaan waktu tidak ada aktivitas.
Pemuatan: Menayangkan konten dan menjadi interaktif dalam waktu kurang dari 5 detik
Saat pemuatan halaman lambat, perhatian pengguna akan teralihkan, dan pengguna akan menganggap tugas tersebut rusak. Situs yang dimuat dengan cepat memiliki rata-rata sesi yang lebih lama, rasio pantulan yang lebih rendah, dan visibilitas iklan yang lebih tinggi.
Sasaran:
Optimalkan performa pemuatan cepat sesuai dengan kemampuan perangkat dan jaringan pengguna Anda. Saat ini, target yang baik untuk pemuatan pertama adalah memuat halaman dan menjadi interaktif dalam 5 detik atau kurang pada perangkat seluler kelas menengah dengan koneksi 3G yang lambat.
Untuk pemuatan berikutnya, target yang baik adalah memuat halaman dalam waktu kurang dari 2 detik.
Panduan:
Uji performa pemuatan di perangkat seluler dan koneksi jaringan yang umum di kalangan pengguna Anda. Anda dapat menggunakan Chrome User Experience Report untuk mengetahui distribusi koneksi pengguna Anda. Jika data tidak tersedia untuk situs Anda, The Mobile Economy 2019 menyarankan bahwa dasar pengukuran global yang baik adalah ponsel Android kelas menengah, seperti Moto G4, dan jaringan 3G yang lambat (didefinisikan sebagai RTT 400 md dan kecepatan transfer 400 kbps). Kombinasi ini tersedia di WebPageTest.
Perlu diingat bahwa meskipun perangkat pengguna seluler biasa mungkin mengklaim bahwa perangkat tersebut menggunakan koneksi 2G, 3G, atau 4G, pada kenyataannya kecepatan koneksi efektif sering kali jauh lebih lambat, karena paket hilang dan variasi jaringan.
Anda tidak perlu memuat semuanya dalam waktu kurang dari 5 detik untuk menghasilkan persepsi pemuatan yang lengkap. Pertimbangkan pemuatan lambat gambar, pemisahan kode paket JavaScript, dan pengoptimalan lain yang disarankan di web.dev.
Alat untuk mengukur RAIL
Ada beberapa alat untuk membantu Anda mengotomatiskan pengukuran RAIL. Pilihan Anda bergantung pada jenis informasi yang Anda perlukan, dan jenis alur kerja yang Anda pilih.
Chrome DevTools
Chrome DevTools memberikan analisis mendalam tentang semua yang terjadi saat halaman Anda dimuat atau dijalankan. Lihat Mulai Menganalisis Performa Runtime untuk memahami UI panel Performa.
Fitur DevTools berikut sangat relevan:
Lakukan throttling pada CPU untuk menyimulasikan perangkat yang kurang canggih.
Batasi jaringan untuk menyimulasikan koneksi yang lebih lambat.
Lihat aktivitas thread utama untuk melihat setiap peristiwa yang terjadi di thread utama saat Anda merekam.
Lihat aktivitas thread utama dalam tabel untuk mengurutkan aktivitas berdasarkan aktivitas yang menghabiskan waktu paling banyak.
Analisis frame per detik (FPS) untuk mengukur apakah animasi Anda benar-benar berjalan lancar.
Pantau penggunaan CPU, ukuran heap JS, node DOM, tata letak per detik, dan lainnya secara real-time dengan Performance Monitor.
Visualisasikan permintaan jaringan yang terjadi saat Anda merekam dengan bagian Network.
Ambil screenshot saat merekam untuk memutar ulang tampilan halaman saat pemuatan halaman, atau animasi aktif, dan sebagainya.
Lihat interaksi untuk mengidentifikasi dengan cepat apa yang terjadi di halaman setelah pengguna berinteraksi dengannya.
Temukan masalah performa scroll secara real-time dengan menandai halaman setiap kali pemroses yang berpotensi bermasalah diaktifkan.
Lihat peristiwa gambar secara real-time untuk mengidentifikasi peristiwa gambar yang mahal yang dapat membahayakan performa animasi Anda.
Mercusuar
Lighthouse tersedia di Chrome DevTools, di PageSpeed Insights, sebagai Ekstensi Chrome, sebagai modul Node.js, dan dalam WebPageTest. Anda memberikan URL, alat ini menyimulasikan perangkat kelas menengah dengan koneksi 3G yang lambat, menjalankan serangkaian audit pada halaman, lalu memberikan laporan tentang performa pemuatan, serta saran tentang cara meningkatkannya.
Audit berikut sangat relevan:
Respons
Potensi Maksimal Penundaan Input Pertama. Memperkirakan berapa lama waktu yang diperlukan aplikasi Anda untuk merespons input pengguna, berdasarkan waktu tidak ada aktivitas thread utama.
Tidak menggunakan pemroses pasif untuk meningkatkan performa scroll.
Total Blocking Time. Mengukur jumlah total waktu saat halaman diblokir agar tidak merespons input pengguna, seperti klik mouse, ketukan layar, atau penekanan keyboard.
Time To Interactive. Mengukur kapan pengguna dapat berinteraksi secara konsisten dengan semua elemen halaman.
Pemuatan
Tidak mendaftarkan pekerja layanan yang mengontrol halaman dan start_url. Service worker dapat meng-cache resource umum di perangkat pengguna, sehingga mengurangi waktu yang dihabiskan untuk mengambil resource melalui jaringan.
Tunda gambar di luar layar. Tunda pemuatan gambar di luar layar hingga diperlukan.
Sesuaikan ukuran gambar dengan benar. Jangan menayangkan gambar yang jauh lebih besar daripada ukuran yang dirender di area pandang seluler.
Hindari ukuran DOM yang berlebihan. Kurangi byte jaringan dengan hanya mengirimkan node DOM yang diperlukan untuk merender halaman.
WebPageTest
WebPageTest adalah alat performa web yang menggunakan browser sungguhan untuk mengakses halaman web dan mengumpulkan metrik pengaturan waktu. Masukkan URL di webpagetest.org/easy untuk mendapatkan laporan mendetail tentang performa pemuatan halaman di perangkat Moto G4 sungguhan dengan koneksi 3G yang lambat. Anda juga dapat mengonfigurasinya untuk menyertakan audit Lighthouse.
Ringkasan
RAIL adalah lensa untuk melihat pengalaman pengguna situs sebagai perjalanan yang terdiri dari interaksi yang berbeda. Pahami cara pengguna memandang situs Anda untuk menetapkan sasaran performa dengan dampak terbesar pada pengalaman pengguna.
Fokus pada pengguna.
Merespons input pengguna dalam waktu kurang dari 100 md.
Menghasilkan frame dalam waktu kurang dari 10 md saat menganimasikan atau men-scroll.
Maksimalkan waktu tidak ada aktivitas thread utama.
Memuat konten interaktif dalam waktu kurang dari 5.000 md.