Hướng đến chỉ số phản hồi tốt hơn

Tìm hiểu ý kiến của chúng tôi về việc đo lường khả năng phản hồi và gửi ý kiến phản hồi cho chúng tôi.

Trong nhóm Chỉ số tốc độ của Chrome, chúng tôi đang tìm hiểu sâu hơn về tốc độ phản hồi của các trang web đối với hoạt động đầu vào của người dùng. Chúng tôi muốn chia sẻ một số ý tưởng để cải thiện các chỉ số về khả năng phản hồi và lắng nghe ý kiến phản hồi của bạn.

Bài đăng này sẽ bao gồm hai chủ đề chính:

1. Xem lại chỉ số phản hồi hiện tại của chúng tôi, Thời gian phản hồi lần tương tác đầu tiên (FID) và giải thích lý do chúng tôi chọn FID thay vì một số giải pháp thay thế.
2. Trình bày một số điểm cải tiến mà chúng tôi đang cân nhắc để nắm bắt tốt hơn độ trễ từ đầu đến cuối của từng sự kiện riêng lẻ. Những điểm cải tiến này cũng nhằm giúp bạn hiểu rõ hơn về khả năng thích ứng tổng thể của trang trong suốt thời gian hoạt động.

Độ trễ đầu vào đầu tiên là gì?

Chỉ số Thời gian phản hồi lần tương tác đầu tiên (FID) đo lường thời gian trình duyệt cần để bắt đầu xử lý lượt tương tác đầu tiên của người dùng trên một trang. Cụ thể, chỉ số này đo lường sự khác biệt giữa thời điểm người dùng tương tác với thiết bị và thời điểm trình duyệt thực sự có thể bắt đầu xử lý trình xử lý sự kiện. FID chỉ được đo lường cho các lượt nhấn và lần nhấn phím, có nghĩa là FID chỉ xem xét lần xuất hiện đầu tiên của các sự kiện sau đây:

• click
• keydown
• mousedown
• pointerdown (chỉ khi đứng trước pointerup)

Sơ đồ dưới đây minh hoạ FID:

FID không bao gồm thời gian dành cho việc chạy các trình xử lý sự kiện đó, cũng như bất kỳ công việc nào mà trình duyệt thực hiện sau đó để cập nhật màn hình. Thuộc tính này đo khoảng thời gian mà luồng chính bận trước khi có cơ hội xử lý dữ liệu đầu vào. Thời gian chặn này thường do các tác vụ JavaScript dài gây ra, vì không thể dừng các tác vụ này bất cứ lúc nào, vì vậy, tác vụ hiện tại phải hoàn tất trước khi trình duyệt có thể bắt đầu xử lý đầu vào.

Tại sao chúng tôi chọn FID?

Chúng tôi tin rằng việc đo lường trải nghiệm thực tế của người dùng là rất quan trọng để đảm bảo rằng những cải tiến đối với chỉ số này mang lại lợi ích thực sự cho người dùng. Chúng tôi chọn đo lường FID vì chỉ số này thể hiện phần trải nghiệm người dùng khi người dùng quyết định tương tác với một trang web vừa được tải. FID ghi lại một số khoảng thời gian mà người dùng phải đợi để xem phản hồi từ hoạt động tương tác của họ với một trang web. Nói cách khác, FID là giới hạn thấp hơn về khoảng thời gian mà người dùng chờ sau khi tương tác.

Các chỉ số khác như Tổng thời gian chặn (TBT) và Thời gian tương tác (TTI) dựa trên các tác vụ dài và tương tự như FID, cũng đo lường thời gian chặn luồng chính trong quá trình tải. Vì các chỉ số này có thể được đo lường trong cả lĩnh vực thực tế và phòng thí nghiệm, nên nhiều nhà phát triển đã hỏi tại sao chúng tôi không ưu tiên sử dụng một trong những chỉ số này hơn FID.

Có một vài lý do cho việc này. Có lẽ lý do quan trọng nhất là các chỉ số này không trực tiếp đo lường trải nghiệm người dùng. Tất cả các chỉ số này đo lường tốc độ JavaScript chạy trên trang. Mặc dù JavaScript chạy trong thời gian dài thường gây ra sự cố cho trang web, nhưng các tác vụ này không nhất thiết ảnh hưởng đến trải nghiệm người dùng nếu người dùng không tương tác với trang khi chúng xảy ra. Một trang có thể có điểm số cao trên TBT và TTI nhưng lại có điểm số chậm hoặc có thể có điểm số thấp trong khi người dùng cảm thấy nhanh. Theo kinh nghiệm của chúng tôi, các phương pháp đo lường gián tiếp này tạo ra các chỉ số phù hợp với một số trang web nhưng không phù hợp với hầu hết các trang web. Tóm lại, thực tế thì các nhiệm vụ dài và TTI không tập trung vào người dùng khiến những ứng viên này yếu hơn.

Mặc dù đo lường trong phòng thí nghiệm chắc chắn quan trọng và là một công cụ vô giá để chẩn đoán, nhưng điều thực sự quan trọng là cách người dùng trải nghiệm các trang web. Bằng cách có một chỉ số tập trung vào người dùng phản ánh điều kiện thực tế của người dùng, bạn đảm bảo thu được thông tin có ý nghĩa về trải nghiệm. Chúng tôi quyết định bắt đầu với một phần nhỏ trải nghiệm đó, mặc dù chúng tôi biết rằng phần này không đại diện cho toàn bộ trải nghiệm. Đây là lý do tại sao chúng tôi đang cố gắng thu thập khoảng thời gian lớn hơn mà người dùng chờ xử lý thông tin đầu vào của họ.

Chúng tôi đang xem xét những cải tiến nào?

Chúng tôi muốn phát triển một chỉ số mới để mở rộng khả năng đo lường FID hiện nay, nhưng vẫn duy trì được mối liên kết chặt chẽ với trải nghiệm người dùng.

Chúng ta muốn chỉ số mới:

1. Xem xét khả năng thích ứng của tất cả hoạt động đầu vào của người dùng (không chỉ hoạt động đầu tiên)
2. Ghi lại toàn bộ thời lượng của từng sự kiện (không chỉ độ trễ).
3. Nhóm các sự kiện xảy ra với nhau trong cùng một hoạt động tương tác logic của người dùng và xác định độ trễ của lượt tương tác đó làm thời lượng tối đa của tất cả sự kiện tương tác.
4. Tạo điểm tổng hợp cho tất cả các lượt tương tác xảy ra trên trang, trong toàn bộ vòng đời của trang đó.

Để thành công, chúng ta có thể chắc chắn khẳng định rằng nếu một trang web đạt điểm thấp trong chỉ số mới này, tức là trang web đó sẽ không phản hồi nhanh chóng với các tương tác của người dùng.

Ghi lại toàn bộ thời lượng sự kiện

Cải thiện rõ ràng đầu tiên là cố gắng thu thập độ trễ từ đầu đến cuối của một sự kiện. Như đã đề cập ở trên, FID chỉ ghi lại phần độ trễ của sự kiện đầu vào. Khoảng thời gian này không tính đến thời gian cần thiết để trình duyệt thực sự xử lý các trình xử lý sự kiện.

Một sự kiện có các giai đoạn khác nhau, như được minh họa trong sơ đồ này:

Sau đây là các bước mà Chrome sẽ thực hiện để xử lý thông tin đầu vào:

1. Hoạt động đầu vào từ người dùng diễn ra. Thời điểm diễn ra sự kiện này là timeStamp của sự kiện.
2. Trình duyệt thực hiện thử nghiệm lượt truy cập để quyết định xem một sự kiện sẽ thuộc về khung HTML nào (khung chính hoặc một số iframe). Sau đó, trình duyệt gửi sự kiện đến quy trình kết xuất đồ hoạ thích hợp chịu trách nhiệm về khung HTML đó.
3. Trình kết xuất nhận được sự kiện và đưa sự kiện vào hàng đợi để có thể xử lý khi có thể.
4. Trình kết xuất xử lý sự kiện bằng cách chạy các trình xử lý. Các trình xử lý này có thể đưa thêm công việc không đồng bộ vào hàng đợi, chẳng hạn như setTimeout và các lần tìm nạp, trong quá trình xử lý đầu vào. Nhưng tại thời điểm này, công việc đồng bộ đã hoàn tất.
5. Một khung được vẽ lên màn hình để phản ánh kết quả chạy của trình xử lý sự kiện. Lưu ý rằng mọi tác vụ không đồng bộ được trình xử lý sự kiện đưa vào hàng đợi có thể vẫn chưa hoàn tất.

Thời gian giữa các bước (1) và (3) ở trên là độ trễ của một sự kiện, là chỉ số FID đo lường.

Thời gian giữa các bước (1) đến (5) ở trên là thời lượng của một sự kiện. Đây là chỉ số mới của chúng tôi sẽ đo lường.

Thời lượng của sự kiện bao gồm độ trễ, nhưng cũng bao gồm tác vụ diễn ra trong trình xử lý sự kiện và công việc mà trình duyệt cần thực hiện để vẽ khung hình tiếp theo sau khi các trình xử lý đó chạy. Thời lượng của một sự kiện hiện có trong Event Timing API thông qua thuộc tính duration của mục nhập.

Nhóm sự kiện thành lượt tương tác

Việc mở rộng số liệu đo lường chỉ số từ độ trễ thành thời lượng là bước đầu tiên phù hợp, nhưng vẫn để lại một khoảng trống nghiêm trọng trong chỉ số: chỉ số này tập trung vào các sự kiện riêng lẻ chứ không phải trải nghiệm người dùng khi tương tác với trang.

Nhiều sự kiện có thể kích hoạt do một lượt tương tác của người dùng và việc đo lường riêng từng sự kiện sẽ không giúp bạn hình dung rõ ràng về trải nghiệm người dùng. Chúng tôi muốn đảm bảo chỉ số của mình thu được toàn bộ khoảng thời gian mà người dùng phải chờ phản hồi khi nhấn, nhấn phím, cuộn và kéo một cách chính xác nhất có thể. Vì vậy, chúng tôi sẽ giới thiệu khái niệm lượt tương tác để đo lường độ trễ của từng lượt tương tác.

Loại tương tác

Bảng sau đây liệt kê 4 hoạt động tương tác mà chúng tôi muốn xác định cùng với các sự kiện DOM mà các sự kiện này được liên kết. Xin lưu ý rằng tập hợp này không giống với tập hợp tất cả sự kiện được gửi khi người dùng tương tác. Chẳng hạn như khi người dùng cuộn, một sự kiện cuộn sẽ được gửi đi, nhưng sự kiện này xảy ra sau khi màn hình được cập nhật để phản ánh hoạt động cuộn. Vì vậy, chúng tôi không coi đây là một phần của độ trễ tương tác.

Ba tương tác đầu tiên nêu trên (bàn phím, nhấn và kéo) hiện thuộc phạm vi điều chỉnh của FID. Đối với chỉ số mới về khả năng phản hồi, chúng tôi cũng muốn đưa tính năng cuộn vào, vì thao tác cuộn cực kỳ phổ biến trên web và là một khía cạnh quan trọng ảnh hưởng đến cảm nhận của người dùng đối với khả năng phản hồi của trang.

Bàn phím

Hoạt động tương tác với bàn phím bao gồm hai phần: khi người dùng nhấn phím và khi họ thả phím ra. Có 3 sự kiện liên quan đến hoạt động tương tác này của người dùng: keydown, keyup và keypress. Sơ đồ dưới đây minh hoạ độ trễ và thời lượng của keydown và keyup cho một tương tác với bàn phím:

Trong biểu đồ trên, thời lượng sẽ rời rạc vì khung của các bản cập nhật keydown được hiển thị trước khi keyup xảy ra, nhưng không phải lúc nào cũng như vậy. Ngoài ra, hãy lưu ý rằng một khung hình có thể xuất hiện ở giữa một tác vụ trong quy trình kết xuất đồ hoạ, vì các bước cuối cùng cần thiết để tạo khung đó được thực hiện bên ngoài quy trình kết xuất.

keydown và keypress xảy ra khi người dùng nhấn phím, trong khi keyup xảy ra khi người dùng nhả khoá. Nhìn chung, quá trình cập nhật nội dung chính diễn ra khi người dùng nhấn phím: văn bản xuất hiện trên màn hình hoặc hiệu ứng đối tượng sửa đổi được áp dụng. Tuy nhiên, chúng tôi muốn ghi lại các trường hợp hiếm gặp hơn, trong đó keyup cũng sẽ hiển thị nội dung cập nhật thú vị về giao diện người dùng, vì vậy, chúng ta muốn xem xét tổng thời gian thực hiện.

Để nắm bắt tổng thời gian cần để tương tác với bàn phím, chúng ta có thể tính toán thời lượng tối đa của các sự kiện keydown và keyup.

Nhấn

Một hoạt động tương tác quan trọng khác của người dùng là khi người dùng nhấn hoặc nhấp vào một trang web. Tương tự như keypress, một số sự kiện được kích hoạt khi người dùng nhấn xuống và một số khác khi người dùng thả ra, như minh hoạ trong biểu đồ ở trên. Hãy lưu ý rằng các sự kiện liên quan đến một lần nhấn trên máy tính và thiết bị di động hơi khác một chút.

Đối với một lượt nhấn hoặc lượt nhấp, bản phát hành thường là yếu tố kích hoạt phần lớn các phản ứng. Tuy nhiên, cũng như các hoạt động tương tác với bàn phím, chúng ta muốn ghi lại toàn bộ lượt tương tác. Và trong trường hợp này thì điều quan trọng hơn là phải làm như vậy vì việc có một số bản cập nhật giao diện người dùng khi nhấn nút thực sự không phải là điều bất thường.

Chúng tôi muốn tính cả thời lượng của sự kiện cho tất cả các sự kiện này, nhưng vì nhiều sự kiện trong số đó trùng lặp hoàn toàn, nên chúng ta chỉ cần đo lường pointerdown, pointerup và click để tính toàn bộ lượt tương tác.

Phương trình lực cản

Chúng tôi cũng quyết định sử dụng tính năng kéo vì nó có các sự kiện liên quan tương tự và vì nó thường dẫn đến các cập nhật quan trọng về giao diện người dùng cho các trang web. Nhưng đối với chỉ số, chúng tôi dự định chỉ xem xét điểm bắt đầu kéo và kết thúc kéo – phần đầu và cuối của quá trình kéo. Điều này giúp bạn dễ dàng giải thích, cũng như làm cho độ trễ có thể so sánh với các tương tác khác được xem xét. Điều này phù hợp với quyết định loại trừ các sự kiện liên tục của chúng tôi (chẳng hạn như mouseover).

Chúng tôi cũng không xem xét các lệnh kéo được triển khai thông qua API kéo và thả vì chúng chỉ hoạt động trên máy tính.

Thao tác cuộn

Một trong những hình thức phổ biến nhất để tương tác với trang web là thông qua thao tác cuộn. Đối với chỉ số mới, chúng tôi muốn đo lường độ trễ đối với hoạt động tương tác cuộn ban đầu của người dùng. Cụ thể, chúng tôi quan tâm đến phản ứng ban đầu của trình duyệt với việc người dùng yêu cầu cuộn. Chúng ta sẽ không đề cập đến toàn bộ trải nghiệm cuộn. Điều này nghĩa là thao tác cuộn sẽ tạo ra nhiều khung và chúng ta sẽ tập trung vào khung hình đầu tiên được tạo ra dưới dạng phản ứng với thao tác cuộn.

Tại sao chỉ là câu đầu tiên? Thứ nhất, các khung hình tiếp theo có thể được chụp bằng một đề xuất về độ mượt riêng biệt. Nghĩa là, sau khi người dùng thấy kết quả đầu tiên của việc cuộn, bạn cần đo lường phần còn lại theo cách cảm nhận được trải nghiệm cuộn mượt mà. Do đó, chúng tôi cho rằng nỗ lực về độ mượt mà có thể nắm bắt tốt hơn điều này. Vì vậy, cũng như với FID, chúng ta chọn tập trung vào trải nghiệm người dùng riêng biệt: trải nghiệm người dùng có các thời điểm rõ ràng liên quan đến trải nghiệm đó và chúng ta có thể dễ dàng tính toán độ trễ. Thao tác cuộn tổng thể là một trải nghiệm liên tục, vì vậy, chúng tôi không có ý định đo lường tất cả hoạt động đó trong chỉ số này.

Vậy tại sao lại đo lường lượt cuộn? Hiệu suất cuộn mà chúng tôi thu thập được trong Chrome cho thấy việc cuộn thường rất nhanh. Tuy nhiên, chúng tôi vẫn muốn đưa độ trễ cuộn ban đầu vào chỉ số mới vì nhiều lý do. Thứ nhất, cuộn nhanh chỉ vì đã được tối ưu hoá rất nhiều vì nó rất quan trọng. Nhưng vẫn có nhiều cách để một trang web bỏ qua một số mức tăng hiệu suất mà trình duyệt cung cấp. Cách phổ biến nhất trong Chrome là buộc thực hiện thao tác cuộn trên luồng chính. Vì vậy, chỉ số của chúng ta có thể cho biết thời điểm điều này xảy ra và gây ra hiệu suất cuộn kém cho người dùng. Thứ hai, bạn không nên bỏ qua thao tác cuộn quá quan trọng. Chúng tôi lo lắng rằng nếu loại trừ thao tác cuộn thì chúng ta sẽ có một điểm mù lớn và hiệu suất cuộn có thể giảm theo thời gian mà các nhà phát triển web không nhận ra đúng cách.

Có một số sự kiện sẽ được gửi khi người dùng cuộn, chẳng hạn như touchstart, touchmove và scroll. Ngoại trừ sự kiện cuộn, điều này phần lớn phụ thuộc vào thiết bị dùng để cuộn: sự kiện chạm sẽ được gửi khi cuộn bằng ngón tay trên thiết bị di động, trong khi sự kiện con lăn chuột xảy ra khi cuộn bằng con lăn chuột. Các sự kiện cuộn được kích hoạt sau khi lần cuộn đầu tiên hoàn tất. Nhìn chung, không có sự kiện DOM nào chặn thao tác cuộn, trừ phi trang web sử dụng trình nghe sự kiện không thụ động. Chúng tôi coi thao tác cuộn được tách riêng khỏi Sự kiện DOM hoàn toàn. Những gì chúng ta muốn đo lường là khoảng thời gian từ khi người dùng di chuyển đủ để tạo một cử chỉ cuộn cho đến khi khung hình đầu tiên cho thấy thao tác cuộn đó diễn ra.

Cách xác định độ trễ của một lượt tương tác?

Như chúng tôi đã lưu ý ở trên, các tương tác có thành phần "xuống" và "lên" cần được xem xét riêng biệt để tránh phân bổ thời gian người dùng nhấn ngón tay xuống.

Đối với các loại tương tác này, chúng tôi muốn độ trễ bao gồm khoảng thời gian của tất cả sự kiện liên quan đến các sự kiện đó. Vì thời lượng sự kiện cho mỗi phần "xuống" và "lên" của hoạt động tương tác có thể trùng lặp, nên định nghĩa đơn giản nhất về độ trễ tương tác giúp đạt được thời lượng này là thời lượng tối đa của bất kỳ sự kiện nào được liên kết với sự kiện đó. Xem lại sơ đồ bàn phím ở phần trước, đây sẽ là thời lượng keydown, vì thời lượng này dài hơn keyup:

Thời lượng keydown và keyup cũng có thể trùng lặp. Điều này có thể xảy ra, chẳng hạn như khi khung hiển thị cho cả hai sự kiện giống nhau, như trong sơ đồ sau:

Phương pháp này có những ưu và nhược điểm sau đây khi sử dụng mức tối đa. Chúng tôi muốn lắng nghe ý kiến phản hồi của bạn:

• Ưu điểm: Phù hợp với cách chúng tôi dự định đo lường hoạt động cuộn, ở chỗ nó chỉ đo lường một giá trị thời lượng duy nhất.
• Ưu điểm: nhằm giảm nhiễu trong các trường hợp như tương tác với bàn phím, trong đó keyup thường không làm gì và người dùng có thể thực thi thao tác nhấn và thả phím nhanh hoặc chậm.
• Nhược điểm: Không nắm bắt toàn bộ thời gian chờ của người dùng. Ví dụ: thuộc tính này sẽ ghi lại điểm bắt đầu hoặc kết thúc của quá trình kéo, chứ không ghi lại cả hai.

Đối với thao tác cuộn (chỉ có một sự kiện liên quan), chúng tôi muốn xác định độ trễ là thời gian trình duyệt cần để tạo khung hình đầu tiên sau khi cuộn. Điều này nghĩa là độ trễ là khoảng delta giữa sự kiện timeStamp của sự kiện DOM đầu tiên (như touchmove, nếu sử dụng ngón tay) đủ lớn để kích hoạt thao tác cuộn và nội dung hiển thị đầu tiên phản ánh quá trình cuộn đang diễn ra.

Tổng hợp tất cả lượt tương tác trên mỗi trang

Sau khi đã xác định độ trễ của một lượt tương tác là gì, chúng tôi sẽ cần tính toán giá trị tổng hợp cho một lượt tải trang có thể có nhiều lượt tương tác của người dùng. Khi có giá trị tổng hợp, chúng tôi có thể:

• Mối tương quan của biểu mẫu với các chỉ số kinh doanh.
• Đánh giá mối tương quan với các chỉ số khác về hiệu suất. Lý tưởng nhất là chỉ số mới của chúng ta sẽ đủ độc lập để tăng thêm giá trị cho các chỉ số hiện có.
• Dễ dàng trình bày các giá trị trong công cụ theo cách dễ hiểu.

Để thực hiện việc tổng hợp này, chúng tôi cần trả lời hai câu hỏi:

1. Chúng tôi cố gắng tổng hợp những số liệu nào?
2. Làm cách nào để tổng hợp các số liệu đó?

Chúng tôi đang khám phá và đánh giá một số lựa chọn. Chúng tôi hoan nghênh ý kiến của bạn về dữ liệu tổng hợp này.

Một lựa chọn là xác định ngân sách cho độ trễ của một lượt tương tác. Ngân sách này có thể phụ thuộc vào loại (cuộn, bàn phím, nhấn hoặc kéo). Ví dụ: nếu ngân sách cho lần nhấn là 100 mili giây và độ trễ của một lần nhấn là 150 mili giây, thì khoản tiền vượt ngân sách cho lần tương tác đó sẽ là 50 mili giây. Sau đó, chúng ta có thể tính toán độ trễ tối đa vượt quá ngân sách cho bất kỳ tương tác nào của người dùng trên trang.

Một lựa chọn khác là tính toán độ trễ trung bình hoặc trung bình của các lượt tương tác trong suốt thời gian hoạt động của trang. Vì vậy, nếu chúng tôi có độ trễ là 80 mili giây, 90 mili giây và 100 mili giây, thì độ trễ trung bình cho trang sẽ là 90 mili giây. Chúng tôi cũng có thể xem xét "vượt quá ngân sách" trung bình hoặc trung bình để tính đến các kỳ vọng khác nhau tùy thuộc vào loại tương tác.

Điều này trông như thế nào trên API hiệu suất web?

Thời gian sự kiện thiếu thông tin gì?

Rất tiếc, không phải tất cả các ý tưởng được trình bày trong bài đăng này đều có thể được ghi lại bằng API Thời gian sự kiện. Cụ thể, không có cách nào đơn giản để biết các sự kiện liên quan đến một tương tác nhất định của người dùng với API. Để làm điều này, chúng tôi đề xuất thêm interactionID vào API.

Một nhược điểm khác của API Thời gian sự kiện là không có cách nào để đo lường lượt tương tác cuộn, vì vậy, chúng tôi đang tìm cách bật các phép đo này (thông qua Thời gian sự kiện hoặc một API riêng).

Bạn có thể thử những gì ngay bây giờ?

Hiện tại, bạn vẫn có thể tính toán độ trễ tối đa cho các thao tác nhấn/kéo và tương tác với bàn phím. Đoạn mã sau đây sẽ tạo ra hai chỉ số này.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

Ý kiến phản hồi

Hãy cho chúng tôi biết ý kiến của bạn về những ý tưởng này qua email: web-vitals-feedback@googlegroups.com!