Đo đạc hiệu suất, tốc độ website bằng mô hình RAIL

RAIL là mô hình hiệu suất, tốc độ trang lấy người dùng làm trung tâm (user-centric), mô hình này chia nhỏ trải nghiệm người dùng thành các hành động quan trọng (key action). Mục tiêu cũng như hướng dẫn của RAIL hướng đến là: giúp đỡ các nhà lập trình và người thiết kế đảm bảo được trải nghiệm của người dùng tốt nhất có thể cho từng hành động của họ (người dùng). Bằng cách xây dựng cấu trúc dựa trên tính toán kỹ lưỡng về hiệu suất, RAIL cho phép các nhà thiết kế và lập trình viên tạo ra các mục tiêu đáng tin cậy, đem lại ảnh hưởng cao nhất cho trải nghiệm người dùng (user experience).

Từng ứng dụng web có bốn khía cạnh khác nhau trong vòng đời của nó, và hiệu suất cũng như tốc độ khớp khít với chúng theo những cách khác nhau:

mô hình RAIL
Hình 1. Đây là 4 phần trong mô hình hiệu suất RAIL. Response / Đáp ứng. Animation / Hoạt ảnh (*). Idle / Thời gian rảnh rỗi. Load / Tải

(*): Ý nghĩa của từ hoạt ảnh sẽ được giải thích trong phần tương ứng, video và ảnh động chỉ là một phần trong đó, hoạt ảnh có ý nghĩa rộng và phức tạp hơn.

Các mục tiêu và hướng dẫn

Trong bối cảnh của mô hình RAIL, thuật ngữ mục tiêuhướng dẫn có các nghĩa cụ thể sau đây:

  • Mục tiêu (Goal). Các chỉ số hiệu suất quan trọng đối với trải nghiệm của người dùng. Vì nhận thức của con người tương đối ổn định, các mục tiêu này không có khả năng thay đổi trong một sớm một chiều.
  • Hướng dẫn (Guideline). Các khuyến nghị giúp bạn đạt được mục tiêu đề ra. Chúng có thể đáp ứng riêng cho cấu hình phần cứng và điều kiện kết nối mạng hiện tại, và do vậy có thể thay đổi theo thời gian (change over time).

Tập trung vào người dùng

Ở đây các nỗ lực tối ưu hiệu suất, tốc độ của bạn lấy người dùng làm tâm điểm. Bảng bên dưới mô tả các chỉ số quan trọng về cách người dùng nhận thức sự trì hoãn về hiệu suất, tốc độ.Nhận thức của người dùng về trì hoãn hiệu suất
0 đến 16msNgười dùng rất giỏi trong việc theo dõi chuyển động (tracking motion), và họ khó chịu khi các hoạt ảnh (animation) diễn ra không mượt mà. Họ nhận thức các họat ảnh là mượt mà miễn là nó thỏa mãn điều kiện kết xuất được 60 frame mới mỗi giây. Tương đương với tốc độ 16ms/frame, bao gồm cả thời gian cần thiết cho trình duyệt đẩy frame mới lên màn hình, do vậy bạn nên để tốc độ tạo một frame của ứng dụng vào khoảng 10ms.
0 đến 100msPhản hồi cho tương tác của người dùng trong khoảng thời gian này và người dùng cảm thấy thích kết quả ngay lập tức. Nếu dài hơn, kết nối giữa hành động và phản hồi (reaction) sẽ bị phá vỡ.
100 đến 300msNgười dùng cảm thấy độ trễ ở mức độ nhẹ.
300 đến 1000msTrong khoảng này, mọi thứ được cảm nhận tự nhiên và tiến trình của tác vụ được nhìn nhận là liên tục. Với phần đa người dùng web, việc tải trang hoặc vùng xem thay đổi được coi như một tác vụ.
1000ms hoặc hơnTrên 1000ms (1 giây), người dùng mất tập trung vào tác vụ mà họ đang thực hiện.
10000ms hoặc hơnTrên 10000ms (10 giây), người dùng sẽ cảm thấy bực bội và có khả năng bỏ ngang tác vụ. Họ có thể có hoặc có thể không quay trở lại sau này.

Nhận thức của người dùng về khía cạnh trì hoãn hiệu suất, tốc độ là khác nhau, tùy thuộc vào điều kiện kết nối mạng và phần cứng. Lấy ví dụ, trải nghiệm tải trang trong vòng 1000ms là hợp lý trên trên máy bàn có phần cứng tốt với kết nối Wifi nhanh, vì người dùng đã quen với trải nghiệm tải trang 1000ms. Nhưng với thiết bị di động có kết nối 3G chậm, tải trang trong vòng 5000ms là mục tiêu khả dĩ hơn, vì người dùng di động nói chung có khả năng kiên nhẫn hơn.

Đáp ứng: xử lý các sự kiện dưới 50ms

Mục tiêu: Hoàn thành quá trình chuyển đổi được khởi tạo bởi hành vi nhập vào của người dùng (user input) trong vòng 100ms. Người dùng mất phần lớn thời gian chờ đợi của họ trên website là cho các phản hồi đầu vào, chứ không phải chờ đợi trang tải về.

Hướng dẫn:

  • Xử lý các sự kiện nhập vào của người dùng trong vòng 50ms để đảm bảo hiển thị phản hồi trong vòng 100ms, nếu không, sự kết nối giữa hành động và phản hồi sẽ bị phá vỡ. Điều này áp dụng cho phần lớn các mục nhập đầu vào, chẳng hạn như click vào button (nút bấm), bắt đầu hoạt ảnh. Điều này không áp dụng cho việc kéo chạm hoặc cuộn trang.
  • Mặc dù nghe có vẻ phản trực giác, không phải lúc nào việc phản hồi ngay lập tức cho mục nhập đầu vào của người dùng cũng hợp lý. Bạn có thể sử dụng khoảng thời gian 100ms này để thực hiện các công việc quan trọng khác. Nhưng hãy cẩn thận, bạn đừng chặn người dùng. Nếu có thể, hãy thực hiện nhiệm vụ dưới chế độ nền.
  • Với các hành động kéo dài hơn 50ms mới hoàn thành được, luôn luôn cung cấp thông tin phản hồi.

50ms hay 100ms?:

Mục tiêu là phản hồi cho mục nhập đầu vào (input) dưới 100ms, vậy thì tại sao chỉ tiêu của chúng ta chỉ có 50ms mà thôi? Điều này là vì: thường sẽ có các công việc khác phải làm bổ sung vào việc xử lý mục nhập đầu vào (input handling), và công việc đó chiếm một phần thời gian có sẵn để đưa ra đáp ứng cho đầu vào mà chấp nhận được. Nếu một ứng dụng thực hiện công việc theo khuyến nghị cách quãng 50ms trong thời gian rảnh, điều đó có nghĩa là input có thể phải xếp hàng đợi đến 50ms nếu nó xuất hiện vào đúng lúc bắt đầu idle task (tác vụ nhàn rỗi). Để phòng bị cho việc này, sẽ an toàn khi giả định là chỉ còn có 50ms khả dụng cho việc xử lý input trong thực tế. Hiệu ứng này được minh họa trong đồ hình bên dưới, cho chúng ta thấy cách tiếp nhận mục nhập đầu vào trong suốt một tác vụ nhàn rồi (idle task) đang xếp hàng, làm giảm đi thời gian xử lý có sẵn:

Đáp ứng trong RAIL
Hình 2. Cách các tác vụ nhàn rỗi ảnh hưởng lên chỉ tiêu đáp ứng của mục nhập đầu vào.

Hoạt ảnh: tạo một frame trong vòng 10ms

Mục tiêu:

  • Tạo từng frame trong hoạt ảnh trong vòng 10ms hoặc ít hơn. Về mặt kỹ thuật, mức tối đa cho từng frame là 16ms (1000ms / 60 frame mỗi giây ~ 16ms), nhưng các trình duyệt cần khoảng 6ms để render (kết xuất) từng frame, vì thế hướng dẫn đưa ra con số 10ms mỗi frame.
  • Hướng đến mục tiêu cho trải nghiệm thị giác mượt mà (smoothness). Người dùng sẽ để ý khi tốc độ frame thay đổi.

Hướng dẫn:

  • Trong các điểm áp lực cao như hoạt ảnh, quan trọng là không làm điều gì hết khi bạn có thể, và tối thiểu hóa việc phải làm khi bạn không thể. Bất cứ khi nào có thể, sử dụng phản hồi 100ms để tính toán trước công việc quan trọng, nặng nhọc vì thế mà bạn có khả năng tối đa hóa cơ hội đạt được 60fps.
  • Bạn có thể tham khảo thêm các bài viết về hiệu suất kết xuất với nhiều chiến lược tối ưu hóa hoạt ảnh khác nhau.
  • Nhận biết tất cả các kiểu hoạt ảnh khác nhau. Hoạt ảnh không chỉ là hiệu ứng UI (giao diện người dùng) lạ mắt. Các tương tác sau đều có thể được xem là hoạt ảnh: (1) Hoạt ảnh hiển thị. Chẳng hạn như các chỉ thị vào ra, tweens và tải; (2) Cuộn. Điều này bao gồm flinging, nghĩa là khi người dùng cuộn trang, và để đó, rồi trang tiếp tục cuộn; (3) Kéo thả. Hoạt ảnh thường theo sau các tương tác của người dùng, chẳng hạn như xoay bản đồ hoặc chủ động dùng hai ngón tay mở rộng ra (pinching) để zoom (phóng to).

Idle (nhàn rỗi): Tối đa thời gian nhàn rỗi

Mục tiêu: Tối đa hóa thời gian nhàn rỗi để tăng khả năng cho thời gian phản hồi của trang đáp ứng mục nhập của người dùng ở mốc dưới 50ms.

Hướng dẫn:

  • Sử dụng thời gian nhàn rỗi để hoàn thành nốt công việc bị trì hoãn. Lấy ví dụ, với lần tải trang đầu tiên (initial page load), bạn hãy tải ít dữ liệu nhất có thể, sau đó sử dụng thời gian rảnh rỗi để tải phần còn lại.
  • Thực hiện công việc trong thời gian rảnh rỗi trong vòng 50ms hoặc ít hơn. Bất cứ tác vụ nào dài hơn thì bạn sẽ gặp phải nguy cơ can thiệp vào khả năng phản hồi của ứng dụng cho mục nhập của người dùng trong thời gian khuyến nghị là 50ms.
  • Nếu người dùng tương tác với trang trong thời gian rảnh rỗi, tương tác của người dùng phải luôn luôn có được ưu tiên cao nhất và được phép làm gián đoạn công việc dành cho thời giản rảnh rỗi (idle time work).

Load (tải): Phân phối nội dung và giúp trang có khả năng tương tác trong vòng từ 5 giây trở xuống

Khi trang của bạn chậm, sự tập trung chú ý của người dùng sẽ bị phân tán, và người dùng xem nhiệm vụ đang thực hiện coi như hỏng. Các website tải nhanh có session trung bình dài hơn, tỷ lệ bounce rate (thoát trang sau lần đầu truy cập) thấp hơn, và quảng cáo có khả năng được xem nhiều hơn. Bạn có thể tìm hiểu thêm các bài viết về cách độ trễ trên di động ảnh hưởng đến doanh thu của các nhà xuất bản.

Mục tiêu:

  • Tối ưu hóa tốc độ tải tương ứng với khả năng của thiết bị và kết nối mạng mà người dùng của bạn sử dụng để truy cập trang web. Hiện tại mục tiêu hợp lý cho lần tải đầu tiên là việc tải trang cũng như khả năng tương tác phải thực hiện được trong vòng từ 5 giây trở xuống trên thiết bị di động tầm trung với kết nối 3G chậm. Nhưng bạn cần ý thức rằng các mục tiêu này có thể thay đổi theo thời gian.
  • Với lần tải kế tiếp (ít nhiều đã được cache sẵn một số tài nguyên), mục tiêu cần nhắm đến hợp lý là tải trang dưới 2 giây. Nhưng mục tiêu này cũng có thể thay đổi theo thời gian.
các chỉ số tốc độ
Hình 3. Từng chỉ số tốc độ đại diện cho một pha khác nhau trong nhận thức của người dùng về trải nghiệm tải trang

Hướng dẫn:

  • Kiểm tra hiệu suất trang của bạn trên thiết bị di động và kết nối mạng chiếm đa số. Nếu doanh nghiệp của bạn có thông tin về thiết bị và mạng kết nối cụ thể mà người dùng sử dụng, bạn có thể kết hợp chúng để thết lập mục tiêu hiệu suất tải trang cho riêng mình. Nếu không, Mobile Economy 2017 gợi ý rằng một lựa chọn căn bản có tính toàn cầu là thiết bị di động Android tầm trung, chẳng hạn như Moto G4, và kết nối mạng 3G chậm (được định nghĩa là 400ms RTT và tốc độ 400kp/s). Kết hợp này có sẵn trên WebPageTest.
  • Cần phải ghi nhớ rằng, mặc dù các thiết bị di động điển hình của người dùng có thể nói rằng nó đang trên kết nối 2G, 3G, hoặc 4G, nhưng trong thực tế tốc độ kết nối hiệu quả (effective coneection speed) thường thấp hơn đáng kể, nguyên nhân là do các gói dữ liệu bị mất và mạng biến thiên thay đổi.
  • Tập trung vào việc tối ưu hóa cho tuyến hiển thị quan trọng để ngăn quá trình render (kết xuất) bị chặn.
  • Bạn không cần phải tải mọi thứ trong vòng dưới 5 giây để tạo ra nhận thức cho người dùng là quá trình tải đã hoàn tất. Hãy thực hiện kiểu render lũy tiến và làm một số việc khác ở chế độ background (nền). Trì hoãn tải các tài nguyên không quan trọng đem đến các khoảng thời gian rảnh rỗi nhiều hơn.
  • Nhận biết các yếu tố ảnh hưởng đến hiệu suất tải trang: (1) Tốc độ mạng và độ trễ, (2) Phần cứng (ví dụ CPU chậm hơn), (3) Giải phóng bộ nhớ cache, (4) Sự khác biệt giữa L2/L3 caching, (5) Phân tích cú pháp JavaScript.

Các công cụ dùng cho việc đo đạc RAIL

Có một số công cụ giúp bạn tự động đo đạc RAIL. Sử dụng công cụ nào còn tùy thuộc vào kiểu thông tin mà bạn cần, và quy trình làm việc (workflow) mà bạn ưa thích:

  • Chrome DevTools. Công cụ dành cho lập trình viên được tích hợp sẵn vào bên trong trình duyệt Google Chrome. Cung cấp các phân tích sâu trên mọi khía cạnh diễn ra khi trang của bạn tải hoặc chạy.
  • Lighthouse. Được tích hợp vào trong Chrome DevTools, dưới dạng Extension cho Chrome, cũng như module Node.js, và bên trong WebPageTest. Bạn đưa vào URL cần kiểm tra, sau đó nó sẽ giả lập một thiết bị tầm trung với kết nối 3G chậm, rồi chạy một loạt các kiểm tra trên trang, và cuối cùng đưa cho bạn một báo cáo về hiệu suất tải, cũng như các gợi ý làm thế nào để cải thiện. Nó cũng cung cấp các kiểm tra để cải thiện khả năng truy cập, giúp trang dễ dàng bảo trì hơn, đủ điều kiện là ứng dụng web lũy tiến (Progressive Web App), vân vân.
  • WebPageTest. Được tích hợp vào webpagetest.org/easy. Bạn đưa vào URL cần kiểm tra, nó tải trang trên thiết bị Moto G4 thật với kết nối 3G chậm, và sau đó gửi cho bạn bản báo cáo chi tiết về hiệu suất tải của trang. Bạn cũng có thể tùy chỉnh để nó tích hợp cả kiểm tra Lighthouse vào đấy.

Phần bên dưới cung cấp cho bạn nhiều thông tin hơn về cách sử dụng từng công cụ để đo đạc RAIL.

Chrome DevTools

Panel Performance là khu vực chính dùng để phân tích các chỉ số RAIL của bạn. Bạn có thể tìm hiểu trước các bài viết về phân tích hiệu suất Runtime để quen thuộc với giao diện người dùng (UI) của panel Performance. Quy trình làm việc và Giao diện người dùng để phân tích hiệu suất tải gần như là tương tự, sự khác biệt chỉ là cách bắt đầu và kết thúc ghi (recording).

Các tính năng sau của DevTools là đặc biệt liên quan:

  • Điều chỉnh CPU (Throttle your CPU) của bạn để mô phỏng thiết bị có cấu hình yếu (less-powerful device).
  • Điều chỉnh mạng (Throttle the network) để mô phỏng các kết nối chậm hơn (slower connections).
  • Xem các hoạt động của luồng chính (View main thread activity) để xem từng sự kiện xuất hiện trên luồng chính trong khi bạn ghi lại.
  • Xem các hoạt động của luồng chính trong một bảng (View main thread activities in a table) để sắp xếp các hoạt động dựa trên tiêu chí cái nào chiếm nhiều thời gian nhất.
  • Phân tích frame trên giây (FPS) để đo đạc xem liệu hoạt ảnh của bạn thực sự chạy trơn tru hay không.
  • Giám sát việc sử dụng CPU, kích thước heap JS, DOM node, layout trên giây và nhiều thứ khác nữa trong thời gian thực (real-time) với Performance Monitor.
  • Hình ảnh hóa các yêu cầu mạng (Visualize network requests) xuất hiện khi bạn bắt đầu tiến hành ghi với khu vực Network.
  • Chụp màn hình trong khi ghi (Capture screenshots while recording) để phát lại chính xác trang trông như thế nào khi trang tải, hoặc một hoạt ảnh được kích hoạt, vân vân.
  • Xem các tương tác (View interactions) để nhanh chóng xác định điều gì xảy ra trên trang sau khi một người dùng tương tác với nó.
  • Phát hiện các vấn đề về cuộn chuột trong thời gian thực (Find scroll performance issues in real-time) bằng cách highlight (làm nổi bật) trang bất cứ khi nào một trình lắng nghe rắc rối tiềm năng được kích hoạt.

Lighthouse

Nếu vẫn chưa biết cách cài đặt và chạy Lighthouse bạn hãy tham khảo các hướng dẫn trên mạng.

báo cáo hiệu suất của Lighthouse
Hình 4. Một ví dụ về báo cáo của Lighthouse

Các kiểm tra sau đặc biệt có liên quan:

Phản hồi (response):

  • Ước tính độ trễ mục nhập. Ước tính xem ứng dụng của bạn mất bao lâu để phản hồi lại tương tác đầu vào của người dùng, dựa trên thời gian rảnh rỗi của luồng chính.
  • Sử dụng trình lắng nghe sự kiện bị động để cải thiện cuộn chuột.

Tải (load):

  • Đăng ký Service Worker. Một service worker có thể cache 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 cho việc tìm nạp các tài nguyên luân chuyển qua mạng.
  • Tốc độ tải trang đủ nhanh trên 3G.
  • First Meaningful Paint. Đo thời điểm trang xuất hiện với đầy đủ ý nghĩa.
  • First CPU Idle. Đánh dấu thời điểm đầu tiên khi mà luồng chính trên trang đủ rảnh rỗi để xử lý các mục nhập đầu vào.
  • Time To Interactive. Đo thời điểm mà người dùng có thể tương tác ổn định với tất cả phần tử trên trang.
  • Chỉ số tốc độ nhận thức (Perceptual Speed Index)
  • Giảm các tài nguyên chặn hiển thị
  • Các ảnh dưới màn hình đầu tiên (offscreen). Bạn nên Trì hoãn tải ảnh nằm dưới màn hình đầu tiên cho đến khi chúng thực sự cần dùng đến.
  • Sử dụng hình ảnh có kích cỡ chính xác. Bạn không nên phục vụ các ảnh có kích cỡ lớn hơn đáng kể so với kích cỡ được kết xuất trong viewport (khung nhìn trình duyệt) của thiết bị di động.
  • Chuỗi các yêu cầu quan trọng. Hình ảnh hóa cho Tuyến hiển thị quan trọng (Critical Rendering Path).
  • Sử dụng HTTP/2
  • Tối ưu hóa ảnh
  • Cho phép bật nén văn bản
  • Tránh tải trọng mạng quá lớn
  • Sử dụng kích thước DOM quá lớn. Giảm dung lượng mạng bằng cách chỉ chuyển đi các node DOM thực sự cần thiết cho quá trình kết xuất trang.

WebPageTest

Nhập URL của bạn vào webpagetest.org/easy để nhận báo cáo về cách trang tải trên thiết bị Android thực tầm trung (real mid-range) với kết nối 3G chậm.

Báo cáo của WebPageTest
Hình 5. Ví dụ về báo cáo của WebPageTest

Tổng kết

RAIL như thấu kính giúp bạn săm soi vào trải nghiệm của người dùng trên website như một hành trình bao gồm các tương tác riêng biệt. Hiểu rõ cách nhận thức của người dùng về trang web của bạn, qua đó giúp thiết lập các mục tiêu hiệu suất có ảnh hưởng lớn nhất cho trải nghiệm của người dùng.

  • Tập trung vào người dùng.
  • Phản hồi cho mục nhập của người dùng dưới 100ms.
  • Tạo ra các frame dưới 10ms cho các hoạt ảnh.
  • Tối đa hóa thời gian rảnh rỗi của luồng chính.
  • Tải nội dung có khả năng tương tác trong vòng 5000ms.

(Dịch từ bài viết: Measure Performance with the RAIL Model, các tác giả: Meggin Keaney, Addy Osmani, Kayce Basques, Jason Miller, trang: Google Developers)

Leave a Comment