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 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 các 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ó những 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 về hiệu suất được xác định dựa trên bối cảnh và nghiên cứu về trải nghiệm người dùng về cách người dùng cảm nhận độ 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 nâng cao hiệu suất của bạn. Bảng dưới đây mô tả các chỉ số chính về cách người dùng cảm nhận độ trễ 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 có khả năng theo dõi chuyển động rất tốt và họ không thích khi ảnh động không mượt mà. Họ cảm 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. Đó là 16 mili giây cho mỗi khung hình, bao gồm cả thời gian cần thiết để trình duyệt vẽ khung hình mới lên màn hình, để lại cho ứng dụng 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 kết quả xuất hiện ngay lập tức. Nếu lâu hơn, mối liên hệ giữa hành động và phản ứng sẽ bị gián đoạn. |
| 100 đến 1000 mili giây | Trong khoảng thời gian này, mọi việc diễn ra như một quá trình tự nhiên và liên tục của các nhiệm vụ. Đố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 tác vụ. |
| Từ 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 tác vụ mà họ đang thực hiện. |
| Từ 10.000 mili giây trở lên | Nếu thời gian chờ quá 10.000 mili giây (10 giây), người dùng sẽ cảm thấy khó chịu và có thể bỏ dở các tác 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 vòng chưa đến 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. Đề xuất giúp bạn đạt được mục tiêu. Các đề xuất này có thể dành riêng cho điều kiện phần cứng và kết nối mạng hiện tại, do đó, có thể thay đổi theo thời gian.
Phản hồi: xử lý các sự kiện trong vòng chưa đến 50 mili giây
Mục tiêu: Hoàn tất một quá trình chuyển đổi do người dùng nhập trong vòng 100 mili giây, để người dùng cảm thấy 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ế độ kiểm soát biểu mẫu hoặc bắt đầu hoạt ảnh. Đ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ù có vẻ phản trực giác, 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 dữ liệu đầ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 thao tá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 thực hiện công việc ở chế độ nền.
Đối với những thao tác mất hơn 50 mili giây để hoàn tất, hãy luôn cung cấp ý kiến 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 100 mili giây, vậy tại sao ngân sách của chúng ta chỉ có 50 mili giây? Điều này là do thường có những công việc khác đượ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 cho phản hồi đầu vào có thể chấp nhận được. Nếu một ứng dụng đang thực hiện công việc trong các khối 50 mili giây được đề xuất trong thời gian rảnh, điều đó có nghĩa là đầu vào có thể được xếp hàng đợi tối đa 50 mili giây nếu xảy ra trong một trong những khối công việc đó. Để giải thích cho điều này, bạn 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ơ đồ bên dưới, cho thấy cách dữ liệu đầu vào nhận được trong một tác vụ không hoạt động được xếp hàng, làm giảm thời gian xử lý có sẵn:
Ả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. 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/giây ≈ 16 mili giây), nhưng các 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ạo hiệu ứng 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 chịu á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à làm ở 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 tận dụng phản hồi 100 ms để tính toán trước những thao tác tốn nhiều tài nguyên để tối đa hoá cơ hội đạt được 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. Trong đó có thao tác 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.
- Kéo. Ảnh động thường đi kèm với các lượt tương tác của người dùng, chẳng hạn như thao tác 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 chờ để tăng khả năng trang phản hồi thao tác nhập 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ị hoãn lại. Ví dụ: đối với lần tải trang ban đầu, 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ó thể làm ảnh hưởng đến khả năng phản hồi thông tin đầ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 thời gian thực hiện công việc ở chế độ chờ, 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 ở chế độ chờ.
Tải: phân phối nội dung và trở nên tương tác trong vòng chưa đầy 5 giây
Khi các trang tải chậm, sự chú ý của người dùng sẽ bị phân tán và họ sẽ cảm thấy như tác vụ bị gián đoạn. Những trang web tải nhanh có thời lượng trung bình của phiên dài hơn, tỷ lệ thoát thấp hơn và tỷ lệ 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 so 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à tương tác trong 5 giây hoặc ít hơn trên các thiết bị di động tầm trung có kết nối 3G chậm.
Đối với các 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 để biết phân phối kết nối của người dùng. Nếu không có dữ liệu cho trang web của bạn, thì Nền kinh tế di động năm 2019 cho thấy một đường cơ sở toàn cầu phù hợp là đ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à 400 ms RTT và tốc độ truyền 400 kbps). Bạn có thể sử dụng tổ hợp này 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ể 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à sự khác biệt về mạng.
Bạn không cần phải tải mọi thứ trong vòng 5 giây để tạo cảm giác tải hoàn tất. Hãy cân nhắc tải từng phần hình ảnh, phân chia mã các gói JavaScript và các hoạt động 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. Bạn sử dụng loại 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
Công cụ cho nhà phát triển của Chrome 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. Hã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.
Hạn chế băng thông 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 trên luồng chính trong 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 số khung hình trên 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ớ heap JS, các nút DOM, bố cục mỗi giây và nhiều chỉ số khác theo thời gian thực bằng Trình giám sát hiệu suất.
Hình dung các yêu cầu mạng xảy ra trong khi bạn đang ghi bằng mục 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 trong 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 một trình nghe có khả năng gây ra vấn đề kích hoạt.
Xem các sự kiện kết xuất theo thời gian thực để xác định những sự kiện kết xuất tốn kém có thể làm ảnh hưởng đến hiệu suất của ảnh động.
Ngọn hải đăng
Lighthouse có trong Công cụ cho nhà phát triển của Chrome, 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 các quy trình kiểm tra trên trang, sau đó cung cấp cho bạn một 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 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ể. Ước tính thời gian ứng dụng của bạn cần để phản hồi thông tin đầu vào của người dùng, dựa trên thời gian chờ của luồng chính.
Không sử dụng trình nghe bị độ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 thông tin đầu vào của người dùng, chẳng hạn như thao tác nhấp chuột, nhấn vào màn hình hoặc nhấn phím.
Thời gian trước khi người dùng có thể 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ý một trình chạy dịch vụ kiểm soát trang và start_url. Một worker dịch vụ có thể lưu vào bộ nhớ đệm các tài nguyên phổ biến trên thiết bị của người dùng, 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.
Thay đổi kích thước hình ảnh cho phù hợp. Không phân phát những hình ảnh lớn hơn đáng kể so với kích thước được hiển thị trong khung hiển thị trên thiết bị di động.
Không sử dụng HTTP/2 cho tất cả các tài nguyên của trang web.
Tránh kích thước DOM quá lớn. Giảm số byte mạng bằng cách chỉ gửi các nút DOM cần thiết để hiển thị trang.
WebPageTest
WebPageTest là một công cụ đo hiệu suất trang web, sử dụng trình duyệt thực để truy cập vào các trang web và thu thập các 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 trang trên một 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 để thêm một bài 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 như một hành trình bao gồm các lượt tương tác riêng biệt. Hiểu cách người dùng cảm nhận 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 một khung hình trong vòng 10 mili giây khi tạo hiệu ứng chuyển độ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 5.000 mili giây.