RAIL adalah model performa yang berfokus pada pengguna yang menyediakan struktur untuk memikirkan performa. Model ini mengelompokkan pengalaman pengguna ke dalam tindakan utama (misalnya, ketuk, scroll, muat) dan membantu Anda menentukan sasaran performa untuk setiap tindakan tersebut.
RAIL adalah singkatan dari empat aspek berbeda dalam 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 penelitian UX tentang cara pengguna memahami penundaan.
Fokus pada pengguna
Jadikan pengguna sebagai titik fokus upaya peningkatan performa Anda. Tabel di bawah menjelaskan metrik utama tentang persepsi pengguna terhadap penundaan performa:
Persepsi pengguna terhadap penundaan performa| 0 hingga 16 md | Pengguna sangat pandai melacak gerakan, dan mereka tidak menyukai animasi yang tidak lancar. Mereka menganggap animasi lancar selama 60 frame baru dirender setiap detik. Itu berarti 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 | Merespons tindakan pengguna dalam jangka waktu ini dan pengguna merasa hasilnya langsung muncul. Jika lebih lama, hubungan antara tindakan dan reaksi akan terputus. |
| 100 hingga 1000 md | Dalam rentang waktu ini, tugas terasa sebagai bagian dari perkembangan tugas yang alami dan berkelanjutan. Bagi sebagian besar pengguna di web, memuat halaman atau mengubah tampilan merupakan tugas. |
| 1.000 md atau lebih | Setelah 1.000 milidetik (1 detik), pengguna akan kehilangan fokus pada tugas yang sedang mereka lakukan. |
| 10000 md atau lebih | Setelah 10.000 milidetik (10 detik), pengguna akan merasa frustrasi dan cenderung menghentikan tugas. Mereka mungkin kembali atau tidak kembali lagi nanti. |
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 melukis 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 spesifik untuk kondisi koneksi jaringan dan hardware 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 interaksi terjadi secara 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 penarikan atau scroll sentuh.
Meskipun mungkin terdengar berlawanan dengan intuisi, merespons input pengguna secara langsung tidak selalu merupakan keputusan yang tepat. Anda dapat menggunakan jendela 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 menggunakan 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 memperhitungkan hal ini, dapat diasumsikan bahwa hanya 50 md yang tersisa yang tersedia untuk penanganan input sebenarnya. Efek ini divisualisasikan dalam diagram di bawah yang menunjukkan cara input yang diterima selama tugas tidak ada aktivitas diantrekan, sehingga mengurangi waktu pemrosesan yang tersedia:
Animasi: menghasilkan frame dalam 10 md
Sasaran:
Menghasilkan 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 panduan 10 md per frame.
Usahakan kelancaran visual. Pengguna akan menyadari saat kecepatan frame bervariasi.
Panduan:
Pada titik tekanan tinggi seperti animasi, kuncinya adalah tidak melakukan apa pun jika Anda bisa, dan melakukan hal minimum jika Anda tidak bisa. Jika memungkinkan, manfaatkan respons 100 md untuk menghitung terlebih dahulu tugas yang berat sehingga Anda dapat 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 termasuk menggeser cepat, yaitu saat pengguna mulai men-scroll, lalu melepaskan jari, dan halaman terus men-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: Memaksimalkan waktu tunggu untuk meningkatkan kemungkinan halaman merespons input pengguna dalam waktu 50 md.
Panduan:
Gunakan waktu tidak ada aktivitas untuk menyelesaikan pekerjaan yang ditunda. Misalnya, untuk pemuatan halaman awal, muat sesedikit mungkin data, lalu gunakan waktu idle 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 tunggu, interaksi pengguna harus selalu menjadi prioritas tertinggi dan menghentikan pekerjaan waktu tunggu.
Pemuatan: menayangkan konten dan menjadi interaktif dalam waktu kurang dari 5 detik
Saat halaman dimuat lambat, perhatian pengguna akan teralihkan, dan pengguna menganggap tugas tersebut gagal. Situs yang dimuat dengan cepat memiliki sesi rata-rata yang lebih lama, rasio pentalan yang lebih rendah, dan visibilitas iklan yang lebih tinggi.
Sasaran:
Optimalkan untuk performa pemuatan cepat relatif terhadap 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 Anda di perangkat seluler dan koneksi jaringan yang umum digunakan oleh 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 menunjukkan bahwa dasar 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 Anda biasanya mengklaim bahwa perangkat tersebut menggunakan koneksi 2G, 3G, atau 4G, pada kenyataannya kecepatan koneksi yang efektif sering kali jauh lebih lambat, karena kehilangan paket 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. Mana yang Anda gunakan bergantung pada jenis informasi yang Anda butuhkan, dan jenis alur kerja yang Anda sukai.
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 bertenaga.
Batasi kecepatan 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 mana yang paling banyak memakan waktu.
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 Pemantau Performa.
Visualisasikan permintaan jaringan yang terjadi saat Anda merekam dengan bagian Network.
Ambil screenshot saat merekam untuk memutar ulang persis seperti tampilan halaman saat halaman dimuat, atau animasi diaktifkan, 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 menggambar secara real-time untuk mengidentifikasi peristiwa menggambar yang mahal dan dapat merusak performa animasi Anda.
Mercusuar
Lighthouse tersedia di Chrome DevTools, di PageSpeed Insights, sebagai Ekstensi Chrome, sebagai modul Node.js, dan dalam WebPageTest. Anda memberinya URL, lalu alat ini akan 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 durasi yang diperlukan aplikasi Anda untuk merespons input pengguna, berdasarkan waktu tunggu thread utama.
Tidak menggunakan pemroses pasif untuk meningkatkan performa scroll.
Total Blocking Time. Mengukur total waktu 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 menyimpan 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 waktu. Masukkan URL di webpagetest.org/easy untuk mendapatkan laporan mendetail tentang performa pemuatan halaman di perangkat Moto G4 yang sebenarnya 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 persepsi pengguna terhadap situs Anda untuk menetapkan sasaran performa yang paling berdampak pada pengalaman pengguna.
Fokus pada pengguna.
Merespons input pengguna dalam waktu kurang dari 100 md.
Menghasilkan frame dalam waktu kurang dari 10 md saat membuat animasi atau men-scroll.
Maksimalkan waktu tidak ada aktivitas thread utama.
Muat konten interaktif dalam waktu kurang dari 5.000 md.