RAIL là 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 của vòng đời ứng dụng web: phản hồi, ảnh động, không hoạt động và tải. Người dùng có kỳ vọng khác nhau về hiệu suất đối với từng bối cảnh trong số này, vì vậy, các mục tiêu về 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 cảm nhận về độ trễ.
Tập trung vào người dùng
Lấy người dùng làm trung tâm của nỗ lực hiệu suất của bạn. Bảng dưới đây mô tả các chỉ số chính về cảm nhận của người dùng về độ trễ về hiệu suất:
Nhận thức của người dùng về độ trễ hiệu suất| 0 đến 16 mili giây | Người dùng đặc biệt thích theo dõi chuyển động và họ không thích điều đó khi ảnh động không mượt mà. Chúng nhận biết ảnh động mượt mà miễn là mỗi giây có 60 khung hình mới được kết xuất. Quá trình này mất 16 mili giây trên mỗi khung hình, bao gồm cả thời gian trình duyệt cần để vẽ khung mới lên màn hình, khiến ứng dụng còn lại khoảng 10 mili giây để tạo 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 rằng kết quả là có ngay lập tức. Còn nữa, việc kết nối giữa hành động và phản ứng sẽ bị ngắt. |
| 100 đến 1000 mili giây | Trong cửa sổ này, mọi thứ sẽ có cảm giác như một phần của tiến trình nhiệm vụ 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 biểu thị một công việc. |
| 1000 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 việc họ đang thực hiện. |
| 10000 mili giây trở lên | Sau 10.000 mili giây (10 giây), người dùng cảm thấy khó chịu và có khả năng từ bỏ các nhiệm vụ. Họ có thể quay lại sau hoặc không. |
Mục tiêu và nguyên tắc
Khi nói đến 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. Do nhận thức của con người tương đối không thay đổi, nên những mục tiêu này khó có thể thay đổi ngay.
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 điều kiện kết nối mạng và phần cứng hiện tại, và do đó có thể thay đổi theo thời gian.
Phản hồi: xử lý sự kiện trong 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 khởi tạo trong vòng 100 mili giây, để người dùng cảm thấy các 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ư thao tác nhấp vào nút, bật/tắt các thành phần điều khiển biểu mẫu hoặc ảnh động bắt đầu. Đ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ác thường, nhưng đây không phải lúc nào cũng là lệnh gọi phù hợp để phản hồi ngay hoạt động đầ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 tác vụ 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 trong nền.
Đối với các thao tác mất hơn 50 mili giây để hoàn tất, hãy luôn đưa ra 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 dưới 100 mili giây, vậy tại sao ngân sách của chúng ta chỉ có 50 mili giây? Lý do là thường thì còn có công việc khác đang được thực hiện ngoài việc xử lý dữ liệu đầu vào, và công việc đó chiếm một phần thời gian có sẵn để phản hồi đầu vào được chấp nhận. Nếu một ứng dụng đang thực hiện công việc ở khoảng thời gian đề xuất là 50 mili giây trong thời gian không hoạt động, thì tức là dữ liệu đầu vào có thể được đưa vào hàng đợi tối đa 50 mili giây nếu hoạt động đó diễn ra tại một trong những đoạn đó. Do đó, bạn có thể giả định rằng hệ thống chỉ có thể sử dụng 50 mili giây còn lại để xử lý đầu vào thực tế. Hiệu ứng này được thể hiện trong sơ đồ bên dưới cho thấy cách dữ liệu đầu vào nhận được trong một tác vụ ở trạng thái rảnh được đưa vào hàng đợi, giúp giảm thời gian xử lý sẵn có:
Ảnh động: tạo một khung hình trong 10 mili giây
Mục tiêu:
Tạo từng khung hình trong ảnh động trong vòng 10 mili giây. Về mặt kỹ thuật, ngân sách tối đa cho mỗi khung là 16 mili giây (1000 mili giây/60 khung hình/giây tương đương 16 mili giây), nhưng các trình duyệt cần khoảng 6 mili giây để hiển thị từng khung hình, do đó phải tuân theo nguyên tắc là 10 mili giây trên mỗi khung hình.
Hãy cố gắng đảm bảo hình ảnh mượt mà. Người dùng sẽ chú ý khi tốc độ khung hình thay đổi.
Nguyên tắc:
Ở các điểm áp lực cao như ảnh động, điều quan trọng là không làm gì cả khi bạn có thể và ở mức tối thiểu tuyệt đối khi bạn không thể. Bất cứ khi nào có thể, hãy sử 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ăng tối đa khả năng đạt được tốc độ 60 khung hình/giây.
Xem phần Hiệu suất hiển thị để biết các chiến lược tối ưu hoá ảnh động khác nhau.
- Ảnh động trực quan, chẳng hạn như số lượt truy cập và số lượt thoát, số ở dạng tiền thiếu niên và chỉ báo đang tải.
- Thao tác cuộn. Điều này bao gồm cử chỉ hất (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).
- Tính năng kéo. Ảnh động thường theo các 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 không hoạt động để 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 không hoạt động để hoàn tất công việc bị trì hoãn. Ví dụ: đối với tải trang ban đầu, hãy tải ít dữ liệu nhất có thể, sau đó sử dụng thời gian không hoạt động để tải phần còn lại.
Thực hiện công việc trong thời gian không hoạt động trong vòng 50 mili giây. Nếu lâu hơn thì bạn có nguy cơ gây ảnh hưởng đến khả năng phản hồi hoạt động đầu vào của người dùng trong vòng 50 mili giây của ứng dụng.
Nếu người dùng tương tác với một trang trong khi làm việc trong thời gian không hoạt động, thì hoạt động tương tác của người dùng phải luôn có mức độ ưu tiên cao nhất và làm gián đoạn công việc trong thời gian không hoạt động.
Tải: phân phối nội dung và tương tác trong chưa đầy 5 giây
Khi các trang tải chậm, sự chú ý của người dùng sẽ mất đi và người dùng sẽ nhận thấy nhiệm vụ đã bị hỏng. Các trang web tải nhanh sẽ có 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á để đạt 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 khi tải trang lần đầu là tải trang và tương tác trong vòng 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, bạn nên tải trang trong vòng chưa đầy 2 giây.
Nguyên tắc:
Kiểm thử 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 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 bản 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 này, thì báo cáo The Mobile Education 2019 gợi ý rằng đường cơ sở toàn cầu tốt là điện thoại Android tầm trung, chẳng hạn như Moto G4, có mạng 3G chậm (được xác định là RTT 400 mili giây và tốc độ truyền 400 kb/giây). Tổ hợp này có trên WebPageTest.
Xin lưu ý rằng mặc dù thiết bị của người dùng di động thông thường có thể tuyên bố rằng thiết bị đang sử dụng 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 dữ liệu và phương sai mạng.
Bạn không cần phải tải mọi thứ trong chưa đầy 5 giây để có thể cảm nhận về quá trình tải hoàn chỉnh. Hãy cân nhắc việc tải từng phần hình ảnh, các gói JavaScript phân tách mã và các phương án 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á việc đo lường RAIL. Phương thức bạn sử dụng phụ thuộc vào loại thông tin bạn cần và loại quy trình làm việc mà bạn ưu tiên.
Công cụ của Chrome cho nhà phát triển
Công cụ của Chrome cho nhà phát triển cung cấp bản phân tích chuyên sâu về mọi thứ xảy ra khi trang của bạn tải hoặc chạy. Hãy xem bài viết Bắt đầu phân tích hiệu suất trong 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ó liên quan đặc biệt đến:
Điều tiết CPU để mô phỏng một thiết bị kém mạnh mẽ 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 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 những hoạt động chiếm nhiều thời gian nhất.
Phân tích 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 tính năng 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 về mạng đã xảy ra trong khi bạn ghi bằng phần Mạng.
Chụp ảnh màn hình trong khi ghi để phát lại chính xác giao diện của trang khi trang được tải hoặc ảnh động được kích hoạt, v.v.
Xem các lượt tương tác để nhanh chóng xác định điều gì đã xảy ra trên một trang sau khi người dùng tương tác với trang đó.
Tìm các 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ó thể có 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 Công cụ của Chrome cho nhà phát triển, tại PageSpeed Insights, dưới dạng một Phần mở rộng của Chrome, dưới dạng một mô-đun Node.js và trong WebPageTest. Bạn cung cấp cho trang một URL, công cụ này 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 bài kiểm tra trên trang rồi cung cấp cho bạn báo cáo về hiệu suất tải cũng như đề xuất về cách cải thiện.
Các hoạt động 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ể đạt được. Ước tính thời gian mà ứng dụng của bạn cần để phản hồi hoạt động đầu vào của người dùng, dựa trên thời gian ở trạng thái 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à một trang bị chặn không cho 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 một người dùng có thể tương tác một cách nhất quán với tất cả các phần tử của trang.
Tải
Không đăng ký một 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. Hoãn tải hình ảnh ngoài màn hình cho đến khi cần thiết.
Chọn kích thước hình ảnh phù hợp. Không phân phát hình ảnh lớn hơn đáng kể so với kích thước hiển thị trong khung nhìn trên thiết bị di động.
Không sử dụng HTTP/2 cho tất cả tài nguyên của trang web này.
Tránh kích thước DOM quá lớn. Bạn có thể giảm số byte mạng bằng cách chỉ vận chuyển các nút DOM cần thiết để hiển thị trang.
WebPageTest
WebPageTest là một công cụ về hiệu suất web sử dụng trình duyệt thực để truy cập vào các trang web và thu thập chỉ số thời gian. Nhập URL tại trang Websitetest.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 tế có kết nối 3G chậm. Bạn cũng có thể định cấu hình để đưa vào hoạt động kiểm tra Lighthouse.
Tóm tắt
RAIL là một thấu kính giúp xem xét trải nghiệm người dùng trên 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ảm nhận của người dùng về trang web của bạn để đặt 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 100 mili giây.
Tạo khung hình trong vòng chưa đầy 10 mili giây khi tạo ảnh động hoặc cuộn.
Tối đa hoá thời gian ở trạng thái rảnh của luồng chính.
Tải nội dung tương tác trong chưa đầy 5000 mili giây.