RAIL adalah model performa yang berfokus pada pengguna yang menyediakan struktur untuk memikirkan performa. Model ini membagi pengalaman pengguna menjadi beberapa tindakan utama (misalnya, mengetuk, men-scroll, memuat) 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 merasakan keterlambatan.
Fokus pada pengguna
Jadikan pengguna sebagai titik fokus upaya performa Anda. Tabel di bawah menjelaskan metrik utama tentang persepsi pengguna terhadap penundaan performa:
Persepsi pengguna tentang keterlambatan performa| 0 hingga 16 md | Pengguna sangat bagus dalam melacak gerakan, dan mereka tidak suka bila animasi tidak berjalan mulus. Mereka menganggap animasi berjalan mulus selama 60 frame baru dirender setiap detik. Waktu ini adalah 16 md per frame, termasuk waktu yang diperlukan browser untuk melukis frame baru ke layar, sehingga aplikasi memiliki waktu sekitar 10 md untuk menghasilkan frame. |
| 0 hingga 100 md | Tanggapi tindakan pengguna dalam jangka waktu ini dan pengguna akan merasa seperti hasilnya langsung. Jika lebih lama, hubungan antara aksi dan reaksi akan terputus. |
| 100 hingga 1000 md | Di dalam periode ini, segala sesuatunya akan terasa sebagai bagian dari perkembangan tugas yang alami dan berkelanjutan. Bagi sebagian besar pengguna di web, memuat halaman atau mengubah tampilan merupakan tugas yang harus dilakukan. |
| 1.000 md atau lebih | Jika melebihi 1.000 milidetik (1 detik), pengguna akan kehilangan fokus pada tugas yang sedang mereka kerjakan. |
| 10.000 md atau lebih | Di atas 10.000 milidetik (10 detik), pengguna akan frustrasi dan cenderung akan meninggalkan tugas. Mereka mungkin akan kembali atau tidak. |
Sasaran dan panduan
Dalam konteks RAIL, istilah sasaran dan panduan memiliki arti tertentu:
Sasaran. Metrik performa utama yang terkait dengan pengalaman pengguna. Misalnya, ketuk untuk menggambar dalam waktu kurang dari 100 milidetik. Karena persepsi manusia relatif konstan, tujuan ini tidak mungkin berubah dalam waktu dekat.
Pedoman. Rekomendasi yang membantu Anda mencapai sasaran. Rekomendasi ini mungkin khusus untuk kondisi koneksi hardware dan jaringan saat ini, sehingga dapat berubah dari waktu ke waktu.
Respons: memproses peristiwa dalam waktu kurang dari 50 md
Sasaran: Menyelesaikan transisi yang dimulai oleh input pengguna dalam waktu 100 md, sehingga pengguna merasa interaksinya instan.
Panduan:
Untuk memastikan respons yang terlihat dalam 100 md, proses peristiwa input pengguna dalam 50 md. Ini berlaku untuk sebagian besar input, seperti mengklik tombol, mengalihkan kontrol formulir, atau memulai animasi. Ini tidak berlaku untuk gestur sentuh atau scroll.
Meskipun terdengar kontra-intuitif, tidak selalu tepat untuk merespons input pengguna dengan segera. Anda dapat menggunakan periode 100 md ini untuk melakukan pekerjaan mahal lainnya, tetapi berhati-hatilah agar tidak memblokir pengguna. Jika memungkinkan, lakukan pekerjaan di belakang layar.
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 sedang dilakukan selain penanganan input, dan pekerjaan tersebut menghabiskan sebagian waktu yang tersedia untuk respons input yang dapat diterima. Jika aplikasi melakukan pekerjaan dalam bagian 50 md yang direkomendasikan selama waktu tidak ada aktivitas, itu berarti input dapat diantrekan hingga 50 md jika terjadi dalam salah satu potongan pekerjaan tersebut. Dengan mempertimbangkan hal ini, dapat diasumsikan bahwa hanya 50 md tersisa yang tersedia untuk penanganan input yang sebenarnya. Efek ini divisualisasikan dalam diagram di bawah yang menunjukkan bagaimana input yang diterima selama tugas tidak ada aktivitas diantrekan, sehingga mengurangi waktu pemrosesan yang tersedia:
Animasi: hasilkan 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 (1.000 md / 60 frame per detik ≈ 16 md), tetapi browser memerlukan waktu sekitar 6 md untuk merender setiap frame, sehingga menjadi panduan 10 md per frame.
Targetkan kelancaran visual. Pengguna akan merasa jika kecepatan frame bervariasi.
Panduan:
Di titik tekanan tinggi seperti animasi, kuncinya adalah tidak melakukan apa pun sebisa mungkin, dan batas minimum jika tidak bisa. Jika memungkinkan, manfaatkan respons 100 md untuk menghitung pekerjaan yang mahal terlebih dahulu sehingga Anda dapat memaksimalkan peluang untuk mencapai 60 fps.
Lihat Performa Rendering untuk berbagai strategi pengoptimalan animasi.
- Animasi visual, seperti masuk dan keluar, hitung nilai, dan indikator pemuatan.
- Men-scroll. Ini termasuk fling, yaitu saat pengguna mulai men-scroll, lalu melepaskannya, dan halaman terus men-scroll.
- Menarik. Animasi sering kali mengikuti interaksi pengguna, seperti menggeser peta atau mencubit untuk melakukan zoom.
Tidak ada aktivitas: maksimalkan waktu tidak ada aktivitas
Sasaran: Memaksimalkan waktu tidak ada aktivitas untuk meningkatkan kemungkinan halaman merespons input pengguna dalam 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.
Melakukan 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 menjadi prioritas tertinggi dan mengganggu pekerjaan waktu tidak ada aktivitas.
Pemuatan: tayangkan konten dan menjadi interaktif dalam waktu kurang dari 5 detik
Jika halaman dimuat dengan lambat, perhatian pengguna akan teralihkan, dan pengguna akan menganggap tugas tersebut rusak. Situs yang dimuat dengan cepat memiliki sesi rata-rata yang lebih panjang, rasio pantulan lebih rendah, dan visibilitas iklan yang lebih tinggi.
Sasaran:
Optimalkan performa pemuatan yang cepat dibandingkan 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 di 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 Anda di perangkat seluler dan koneksi jaringan yang umum di antara pengguna. Anda dapat menggunakan Laporan Pengalaman Pengguna Chrome untuk mengetahui distribusi koneksi pengguna Anda. Jika data tidak tersedia untuk situs Anda, The Mobile Economy 2019 menunjukkan bahwa dasar pengukuran global yang baik adalah ponsel Android kelas menengah, seperti Moto G4, dan jaringan 3G yang lambat (didefinisikan sebagai 400 md RTT dan kecepatan transfer 400 kbps). Kombinasi ini tersedia di WebPageTest.
Perlu diingat bahwa meskipun perangkat pengguna seluler biasa Anda mungkin mengklaim bahwa perangkat tersebut menggunakan koneksi 2G, 3G, atau 4G, pada kenyataannya kecepatan koneksi efektif sering kali jauh lebih lambat karena kehilangan paket dan varian jaringan.
Anda tidak perlu memuat semuanya dalam waktu kurang dari 5 detik untuk menghasilkan persepsi beban yang lengkap. Pertimbangkan pemuatan lambat gambar, paket JavaScript yang memisahkan kode, dan pengoptimalan lainnya yang disarankan di web.dev.
Alat untuk mengukur RAIL
Ada beberapa alat untuk membantu Anda mengotomatiskan pengukuran RAIL. Mana yang Anda gunakan bergantung pada jenis informasi yang Anda butuhkan, dan jenis alur kerja apa yang Anda pilih.
Chrome DevTools
Chrome DevTools memberikan analisis mendalam tentang apa saja yang terjadi saat halaman Anda dimuat atau dijalankan. Lihat Mulai Menganalisis Performa Runtime untuk memahami UI panel Performa.
Fitur DevTools berikut sangat relevan:
Batasi CPU untuk menyimulasikan perangkat yang kurang berdaya.
Batasi jaringan untuk menyimulasikan koneksi yang lebih lambat.
Melihat aktivitas thread utama untuk melihat setiap peristiwa yang terjadi di thread utama saat Anda merekam.
Melihat aktivitas thread utama dalam tabel untuk mengurutkan aktivitas berdasarkan aktivitas yang memerlukan 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 Jaringan.
Ambil screenshot saat merekam untuk memutar kembali tampilan halaman saat halaman dimuat, atau animasi diaktifkan, dan sebagainya.
Lihat interaksi untuk mengidentifikasi dengan cepat apa yang terjadi pada halaman setelah pengguna berinteraksi dengan halaman tersebut.
Temukan masalah performa scroll secara real time dengan menandai halaman setiap kali pemroses yang berpotensi bermasalah diaktifkan.
Lihat peristiwa paint secara real time untuk mengidentifikasi peristiwa paint yang mahal yang mungkin mengganggu performa animasi Anda.
Mercusuar
Lighthouse tersedia di Chrome DevTools, di PageSpeed Insights, sebagai Ekstensi Chrome, sebagai modul Node.js, dan dalam WebPageTest. Anda memberikannya URL, menyimulasikan perangkat kelas menengah dengan koneksi 3G yang lambat, menjalankan serangkaian audit di halaman, lalu memberi Anda laporan tentang performa pemuatan, serta saran tentang cara meningkatkannya.
Audit berikut sangat relevan:
Respons
Potensi Maksimal Penundaan Input Pertama. Memperkirakan waktu yang diperlukan aplikasi untuk merespons input pengguna, berdasarkan waktu tidak ada aktivitas thread utama.
Tidak menggunakan pemroses pasif untuk meningkatkan performa scroll.
Total Waktu Pemblokiran. Mengukur jumlah total waktu halaman diblokir agar tidak merespons input pengguna, seperti klik mouse, ketukan layar, atau penekanan keyboard.
Waktu untuk Interaktif. Mengukur kapan pengguna dapat berinteraksi secara konsisten dengan semua elemen halaman.
Pemuatan
Tidak mendaftarkan pekerja layanan yang mengontrol halaman dan start_url. Pekerja layanan dapat meng-cache resource umum pada 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.
Mengatur ukuran gambar dengan benar. Jangan tampilkan gambar yang secara signifikan lebih besar dari 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 waktu. Masukkan URL di webpagetest.org/easy untuk mendapatkan laporan mendetail tentang performa pemuatan halaman pada perangkat Moto G4 sungguhan dengan koneksi 3G 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 persepsi pengguna terhadap situs Anda untuk menetapkan sasaran performa yang memberikan dampak terbesar pada pengalaman pengguna.
Fokus pada pengguna.
Respons input pengguna dalam waktu kurang dari 100 md.
Buat frame dalam waktu kurang dari 10 md saat menganimasikan atau men-scroll.
Memaksimalkan waktu tidak ada aktivitas thread utama.
Memuat konten interaktif dalam waktu kurang dari 5000 md.