RAIL là một mô hình hiệu suất lấy người dùng làm trung tâm, cung cấp cấu trúc để suy nghĩ về hiệu suất. Mô hình này chia nhỏ trải nghiệm của người dùng thành các hành động chính (ví dụ: nhấn, cuộn, tải) và giúp bạn xác định mục tiêu hiệu suất cho từng hành động.
RAIL là viết tắt của 4 khía cạnh riêng biệt trong vòng đời của ứng dụng web: phản hồi, ảnh động, trạng thái rảnh và tải. Người dùng có kỳ vọng khác nhau về hiệu suất cho từng bối cảnh này, vì vậy, mục tiêu hiệu suất được xác định dựa trên bối cảnh và nghiên cứu trải nghiệm người dùng về cách người dùng nhận thấy độ trễ.
Tập trung vào người dùng
Đặt người dùng làm trọng tâm trong nỗ lực cải thiện hiệu suất. Bảng dưới đây mô tả các chỉ số chính về cách người dùng nhận biết độ trễ về hiệu suất:
Cảm nhận của người dùng về độ trễ hiệu suất| 0 đến 16 mili giây | Người dùng rất giỏi theo dõi chuyển động và họ không thích khi ảnh động không mượt mà. Họ nhận thấy ảnh động mượt mà miễn là 60 khung hình mới được kết xuất mỗi giây. Tức là 16 mili giây cho mỗi khung hình, bao gồm cả thời gian trình duyệt vẽ khung hình mới lên màn hình, khiến ứng dụng mất khoảng 10 mili giây để tạo một khung hình. |
| 0 đến 100 mili giây | Phản hồi hành động của người dùng trong khoảng thời gian này và người dùng cảm thấy như kết quả là ngay lập tức. Nếu lâu hơn, mối liên kết giữa hành động và phản ứng sẽ bị phá vỡ. |
| 100 đến 1000 mili giây | Trong cửa sổ này, mọi thứ đều diễn ra theo một trình tự tự nhiên và liên tục. Đối với hầu hết người dùng trên web, việc tải trang hoặc thay đổi chế độ xem là một nhiệm vụ. |
| 1.000 mili giây trở lên | Sau 1000 mili giây (1 giây), người dùng sẽ mất tập trung vào nhiệm vụ họ đang thực hiện. |
| 10.000 mili giây trở lên | Sau 10.000 mili giây (10 giây), người dùng sẽ cảm thấy khó chịu và có khả năng sẽ bỏ dở nhiệm vụ. Họ có thể quay lại sau hoặc không. |
Mục tiêu và nguyên tắc
Trong bối cảnh của RAIL, các thuật ngữ mục tiêu và nguyên tắc có ý nghĩa cụ thể:
Mục tiêu. Các chỉ số hiệu suất chính liên quan đến trải nghiệm người dùng. Ví dụ: nhấn để vẽ trong chưa đầy 100 mili giây. Vì nhận thức của con người tương đối ổn định, nên những mục tiêu này khó có thể thay đổi trong thời gian tới.
Nguyên tắc. Các đề xuất giúp bạn đạt được mục tiêu. Những đề xuất này có thể dành riêng cho phần cứng hiện tại và điều kiện kết nối mạng, do đó có thể thay đổi theo thời gian.
Phản hồi: Xử lý sự kiện trong vòng chưa đầy 50 mili giây
Mục tiêu: Hoàn tất quá trình chuyển đổi do hoạt động đầu vào của người dùng bắt đầu trong vòng 100 mili giây, để người dùng cảm thấy như các hoạt động tương tác diễn ra tức thì.
Nguyên tắc:
Để đảm bảo phản hồi hiển thị trong vòng 100 mili giây, hãy xử lý các sự kiện đầu vào của người dùng trong vòng 50 mili giây. Điều này áp dụng cho hầu hết các hoạt động đầu vào, chẳng hạn như nhấp vào nút, bật/tắt các chế độ điều khiển biểu mẫu hoặc bắt đầu ảnh động. Điều này không áp dụng cho thao tác kéo hoặc cuộn bằng cách chạm.
Mặc dù nghe có vẻ không hợp lý, nhưng không phải lúc nào bạn cũng nên phản hồi ngay lập tức thông tin đầu vào của người dùng. Bạn có thể sử dụng khoảng thời gian 100 mili giây này để thực hiện các công việc tốn kém khác, nhưng hãy cẩn thận để không chặn người dùng. Nếu có thể, hãy làm việc ở chế độ nền.
Đối với những hành động mất hơn 50 mili giây để hoàn tất, hãy luôn cung cấp phản hồi.
50 mili giây hay 100 mili giây?
Mục tiêu là phản hồi dữ liệu đầu vào trong vòng chưa đầy 100 mili giây, vậy tại sao ngân sách của chúng ta chỉ là 50 mili giây? Điều này là do thường có các công việc khác được thực hiện ngoài việc xử lý hoạt động đầu vào và công việc đó chiếm một phần thời gian có sẵn để phản hồi hoạt động đầu vào ở mức chấp nhận được. Nếu một ứng dụng đang thực hiện công việc trong các đoạn 50 mili giây được đề xuất trong thời gian rảnh, thì tức là dữ liệu đầu vào có thể được đưa vào hàng đợi trong tối đa 50 mili giây nếu xảy ra trong một trong các đoạn công việc đó. Do đó, chúng ta có thể giả định rằng chỉ còn 50 mili giây để xử lý dữ liệu đầu vào thực tế. Hiệu ứng này được minh hoạ trong sơ đồ dưới đây, cho thấy cách dữ liệu đầu vào nhận được trong một tác vụ rảnh được đưa vào hàng đợi, làm giảm thời gian xử lý hiện có:
Ảnh động: Tạo một khung hình trong 10 mili giây
Mục tiêu:
Tạo mỗi khung hình trong ảnh động trong vòng 10 mili giây trở xuống. Về mặt kỹ thuật, ngân sách tối đa cho mỗi khung hình là 16 mili giây (1000 mili giây/60 khung hình mỗi giây ≈ 16 mili giây), nhưng trình duyệt cần khoảng 6 mili giây để kết xuất mỗi khung hình, do đó, nguyên tắc là 10 mili giây cho mỗi khung hình.
Cố gắng đạt được độ mượt mà về mặt hình ảnh. Người dùng sẽ nhận thấy khi tốc độ khung hình thay đổi.
Nguyên tắc:
Ở những điểm có áp lực cao như ảnh động, mấu chốt là không làm gì khi có thể và làm ở mức tối thiểu khi không thể. Bất cứ khi nào có thể, hãy tận dụng phản hồi 100 mili giây để tính toán trước công việc tốn kém nhằm tối đa hoá cơ hội đạt được 60 khung hình/giây.
Hãy xem phần Hiệu suất kết xuất để biết các chiến lược tối ưu hoá ảnh động.
- Ảnh động trực quan, chẳng hạn như ảnh động xuất hiện và biến mất, ảnh động trung gian và chỉ báo tải.
- Đang cuộn. Điều này bao gồm cả thao tác vuốt nhanh, tức là khi người dùng bắt đầu cuộn, sau đó thả tay ra và trang tiếp tục cuộn.
- Kéo. Ảnh động thường theo sau các hoạt động tương tác của người dùng, chẳng hạn như kéo bản đồ hoặc chụm để thu phóng.
Không hoạt động: Tối đa hoá thời gian không hoạt động
Mục tiêu: Tối đa hoá thời gian rảnh để tăng khả năng trang phản hồi hoạt động đầu vào của người dùng trong vòng 50 mili giây.
Nguyên tắc:
Sử dụng thời gian rảnh để hoàn thành công việc bị trì hoãn. Ví dụ: đối với lần tải trang đầu tiên, hãy tải càng ít dữ liệu càng tốt, sau đó sử dụng thời gian rảnh để tải phần còn lại.
Thực hiện công việc trong thời gian rảnh từ 50 mili giây trở xuống. Nếu lâu hơn, bạn có nguy cơ can thiệp vào khả năng phản hồi của ứng dụng đối với hoạt động đầu vào của người dùng trong vòng 50 mili giây.
Nếu người dùng tương tác với một trang trong khi thực hiện công việc trong thời gian rảnh, thì hoạt động tương tác của người dùng phải luôn được ưu tiên cao nhất và làm gián đoạn công việc trong thời gian rảnh.
Tải: Cung cấp nội dung và có thể tương tác trong vòng chưa đầy 5 giây
Khi trang tải chậm, người dùng sẽ mất tập trung và cho rằng tác vụ bị hỏng. Các trang web tải nhanh có thời lượng phiên trung bình dài hơn, tỷ lệ thoát thấp hơn và khả năng xem quảng cáo cao hơn.
Mục tiêu:
Tối ưu hoá để có hiệu suất tải nhanh tương ứng với khả năng của thiết bị và mạng của người dùng. Hiện tại, mục tiêu phù hợp cho lần tải đầu tiên là tải trang và có thể tương tác trong 5 giây trở xuống trên các thiết bị di động tầm trung có kết nối 3G chậm.
Đối với những lần tải tiếp theo, mục tiêu phù hợp là tải trang trong vòng chưa đầy 2 giây.
Nguyên tắc:
Kiểm tra hiệu suất tải trên các thiết bị di động và kết nối mạng mà người dùng của bạn thường sử dụng. Bạn có thể sử dụng Báo cáo trải nghiệm người dùng trên Chrome để tìm hiểu mức phân phối kết nối của người dùng. Nếu trang web của bạn không có dữ liệu, thì báo cáo The Mobile Economy 2019 (Nền kinh tế di động năm 2019) đề xuất rằng một đường cơ sở chung phù hợp là một chiếc điện thoại Android tầm trung, chẳng hạn như Moto G4 và mạng 3G chậm (được xác định là RTT 400 mili giây và tốc độ truyền 400 kb/giây). Sự kết hợp này có trên WebPageTest.
Hãy nhớ rằng mặc dù thiết bị của người dùng di động thông thường có thể cho biết rằng thiết bị đang kết nối 2G, 3G hoặc 4G, nhưng trên thực tế, tốc độ kết nối hiệu quả thường chậm hơn đáng kể do mất gói và biến thiên mạng.
Bạn không cần phải tải mọi thứ trong vòng chưa đầy 5 giây để tạo cảm giác tải xong. Hãy cân nhắc việc tải chậm hình ảnh, chia tách mã gói JavaScript và các phương pháp tối ưu hoá khác được đề xuất trên web.dev.
Công cụ đo lường RAIL
Có một số công cụ giúp bạn tự động hoá các phép đo RAIL. Việc bạn sử dụng công cụ nào sẽ tuỳ thuộc vào loại thông tin bạn cần và loại quy trình làm việc bạn muốn.
Công cụ của Chrome cho nhà phát triển
Chrome DevTools cung cấp thông tin phân tích chuyên sâu về mọi hoạt động diễn ra trong khi trang của bạn tải hoặc chạy. Xem bài viết Bắt đầu phân tích hiệu suất thời gian chạy để làm quen với giao diện người dùng của bảng điều khiển Hiệu suất.
Các tính năng sau đây của Công cụ cho nhà phát triển đặc biệt phù hợp:
Điều tiết CPU để mô phỏng một thiết bị có hiệu suất thấp hơn.
Điều tiết mạng để mô phỏng các kết nối chậm hơn.
Xem hoạt động của luồng chính để xem mọi sự kiện đã xảy ra trên luồng chính trong khi bạn đang ghi.
Xem các hoạt động của luồng chính trong một bảng để sắp xếp các hoạt động dựa trên hoạt động nào mất nhiều thời gian nhất.
Phân tích số khung hình/giây (FPS) để đo lường xem ảnh động của bạn có thực sự chạy mượt mà hay không.
Theo dõi mức sử dụng CPU, kích thước vùng nhớ khối xếp JS, nút DOM, bố cục mỗi giây và nhiều thông tin khác theo thời gian thực bằng Trình theo dõi hiệu suất.
Trực quan hoá các yêu cầu mạng xảy ra trong khi bạn đang ghi bằng phần Mạng.
Chụp ảnh màn hình trong khi ghi lại để phát lại chính xác giao diện của trang khi trang tải hoặc một ảnh động được kích hoạt, v.v.
Xem các lượt tương tác để nhanh chóng xác định những gì đã xảy ra trên một trang sau khi người dùng tương tác với trang đó.
Tìm vấn đề về hiệu suất cuộn theo thời gian thực bằng cách làm nổi bật trang bất cứ khi nào trình nghe có khả năng gặp vấn đề kích hoạt.
Xem các sự kiện vẽ theo thời gian thực để xác định các sự kiện vẽ tốn kém có thể gây hại cho hiệu suất của ảnh động.
Ngọn hải đăng
Lighthouse có trong Chrome DevTools, tại PageSpeed Insights, dưới dạng tiện ích Chrome, dưới dạng mô-đun Node.js và trong WebPageTest. Bạn cung cấp cho công cụ này một URL, công cụ này sẽ mô phỏng một thiết bị tầm trung có kết nối 3G chậm, chạy một loạt quy trình kiểm tra trên trang, sau đó cung cấp cho bạn báo cáo về hiệu suất tải cũng như các đề xuất về cách cải thiện.
Các quy trình kiểm tra sau đây đặc biệt phù hợp:
Đáp
Thời gian phản hồi lần tương tác đầu tiên tối đa có thể xảy ra. Ước tính thời gian ứng dụng của bạn phản hồi hoạt động đầu vào của người dùng, dựa trên thời gian rảnh của luồng chính.
Không sử dụng trình nghe thụ động để cải thiện hiệu suất cuộn.
Tổng thời gian chặn. Đo lường tổng thời gian một trang bị chặn phản hồi hoạt động đầu vào của người dùng, chẳng hạn như nhấp chuột, nhấn vào màn hình hoặc nhấn bàn phím.
Thời gian tương tác. Đo lường thời điểm người dùng có thể tương tác nhất quán với tất cả các phần tử trên trang.
Tải
Không đăng ký trình chạy dịch vụ kiểm soát trang và start_url. Trình chạy dịch vụ có thể lưu các tài nguyên phổ biến vào bộ nhớ đệm trên thiết bị của người dùng, giúp giảm thời gian tìm nạp tài nguyên qua mạng.
Trì hoãn hình ảnh ngoài màn hình. Trì hoãn việc tải hình ảnh ngoài màn hình cho đến khi cần.
Thay đổi kích thước hình ảnh cho phù hợp. Đừng phân phát hình ảnh lớn hơn đáng kể so với kích thước được hiển thị trong khung nhìn trên thiết bị di động.
Tránh kích thước DOM quá lớn. Giảm số byte mạng bằng cách chỉ cung cấp các nút DOM cần thiết để hiển thị trang.
WebPageTest
WebPageTest là một công cụ đo lường hiệu suất web sử dụng trình duyệt thực tế để truy cập vào các trang web và thu thập chỉ số về thời gian. Nhập một URL tại webpagetest.org/easy để nhận báo cáo chi tiết về hiệu suất tải của trang trên thiết bị Moto G4 thực có kết nối 3G chậm. Bạn cũng có thể định cấu hình để thêm một quy trình kiểm tra Lighthouse.
Tóm tắt
RAIL là một lăng kính để xem xét trải nghiệm người dùng của một trang web dưới dạng một hành trình bao gồm các hoạt động tương tác riêng biệt. Hiểu cách người dùng nhìn nhận trang web của bạn để đặt ra các mục tiêu hiệu suất có tác động lớn nhất đến trải nghiệm người dùng.
Tập trung vào người dùng.
Phản hồi hoạt động đầu vào của người dùng trong vòng chưa đầy 100 mili giây.
Tạo khung hình trong chưa đầy 10 mili giây khi tạo ảnh động hoặc cuộn.
Tối đa hoá thời gian rảnh của luồng chính.
Tải nội dung tương tác trong vòng chưa đầy 5.000 mili giây.