Cách redBus cải thiện khả năng tương tác với thời gian hiển thị tiếp theo (INP) của trang web và tăng doanh số thêm 7%

Hoạt động tối ưu hoá INP đã giúp redBus tăng doanh số thêm khoảng 7%

Amit Kumar

Saurabh Rajpal

Web và các chức năng của web đang phát triển với tốc độ nhanh chóng. Giờ đây, bạn có thể xây dựng trải nghiệm phong phú và đầy đủ tính năng trên web. Các tính năng này có thể đạt được nhiều khả năng của các ứng dụng gốc.

JavaScript là yếu tố chính thúc đẩy tương tác trên web, nhưng nếu không được sử dụng cẩn thận, các hoạt động tương tác có thể trở nên chậm và khiến người dùng cảm thấy trang web của bạn không phản hồi hoặc hoàn toàn bị hỏng. Rất may, chỉ số Lượt tương tác với Nội dung hiển thị tiếp theo (INP) đã được tạo để giải quyết vấn đề cụ thể này về trải nghiệm người dùng.

INP đo lường tất cả các lượt tương tác được thực hiện với một trang trong suốt vòng đời của trang và báo cáo một giá trị duy nhất đại diện cho tốc độ phản hồi hoạt động đầu vào của người dùng của trang web. Nói một cách đơn giản, nếu INP của một trang bằng hoặc thấp hơn ngưỡng tốt, thì tất cả các lượt tương tác được thực hiện với một trang có thể được xem là nhanh một cách đáng tin cậy.

redBus, một trang web đặt vé và đặt xe xe buýt có trụ sở tại Ấn Độ, đã nỗ lực đáng kể để cải thiện INP trên trang web của họ, ngay cả trong thời điểm đây vẫn còn được xem là chỉ số thử nghiệm. Nhờ những nỗ lực của mình, họ đã tăng doanh số bán hàng thêm 7%, minh hoạ một lần nữa mối quan hệ giữa hiệu suất web và tình trạng kinh doanh. Sau đây là những việc mà redBus đã làm để cải thiện INP của trang web.

Mục tiêu hàng đầu

Khi redBus bắt đầu tối ưu hoá INP của trang web, họ đã xác định ba mục tiêu:

1. Cung cấp trải nghiệm người dùng tốt hơn cho người dùng bằng cách tập trung vào độ trễ tương tác bất kể tốc độ mạng và khả năng của thiết bị.
2. Tối ưu hoá trang web để lượt tương tác diễn ra nhanh nhất có thể.
3. Đảm bảo rằng phản hồi từ API của họ nhẹ nhất có thể để đảm bảo chuyển dữ liệu nhanh chóng đến giao diện người dùng.

Hành trình

RedBus đã phân loại độ trễ tương tác theo 2 cách:

1. Độ trễ tương tác do việc chặn JavaScript trên ứng dụng. Khi các lượt tương tác sử dụng quá nhiều JavaScript chặn luồng chính, quá trình hiển thị sẽ bị trì hoãn và điều này ảnh hưởng đến INP của trang.
2. Độ trễ mạng do lệnh gọi API gây ra. Mặc dù hoạt động mạng không phải là hoạt động mà INP đo lường, nhưng hoạt động tương tác phụ thuộc vào lệnh gọi đến một API từ xa có thể bị chậm trên các mạng chậm hơn hoặc nếu yêu cầu dẫn đến phản hồi lớn.

Ban đầu RedBus khá tự tin rằng INP sẽ mang lại hiệu quả cho trang web của họ, nhưng dữ liệu Giám sát người dùng thực (rum) cho chỉ số này tại phân vị thứ 95 lại cho thấy một câu chuyện khác.

Cách RedBus đo lường INP

RedBus dựa vào thư viện JavaScript web-vitals do Google tạo để theo dõi không chỉ INP mà còn theo dõi mọi chỉ số quan trọng về trải nghiệm người dùng cho tất cả các trang trên trang web của họ. Ngoài thư viện JavaScript web-vitals, redBus còn sử dụng ELK để phân tích dữ liệu INP được thu thập trên giao diện người dùng.

Tuy nhiên, cách bạn theo dõi INP của trang web trong trường có thể khá khác với cách redBus tiếp cận vấn đề. Bạn nên đọc bài viết về cách tìm các lượt tương tác có tốc độ chậm trong thực tế để biết cách hiệu quả nhất nhằm theo dõi INP cho trang web của bạn và sau đó là cách tái hiện các lượt tương tác đó trong phòng thí nghiệm trước khi bắt đầu tối ưu hoá hoạt động tương tác.

Khi redBus có sẵn một hệ thống để theo dõi INP, họ có thể phân tích dữ liệu để hiểu rõ hơn về vị trí hiện diện tương tác chậm.

Ảnh chụp màn hình về hệ thống ghi nhật ký mà redBus sử dụng để phân tích các giá trị INP được thu thập từ trường này. (Nhấp vào để xem phiên bản có độ phân giải cao hơn của hình ảnh này.)

Trường hợp sử dụng

Khi người dùng tìm giá vé trên trang web redBus, họ có thể thay đổi ngày trên trang tìm kiếm để lọc giá vé đã chọn theo điểm đến mong muốn. Quá trình tương tác để thay đổi ngày trên trang này diễn ra chậm và là nguyên nhân dẫn đến INP thấp.

Ngoài ra, khi người dùng cuộn qua giá vé, giá vé bổ sung sẽ được tải từng phần từ API. Mặc dù việc cuộn không được tính đến cách đo INP, nhưng trình nghe sự kiện scroll tự lên lịch nhiều công việc phải chạy trên luồng chính. Công việc này đã gây ra tranh chấp trên luồng chính, làm tăng độ trễ tương tác, dẫn đến INP thấp trên trang tìm kiếm.

Hành vi tải từng phần dùng để tải giá vé bổ sung từ API khi cuộn. (Nhấp vào để xem phiên bản có độ phân giải cao hơn của video này.)

Cách redBus tối ưu hoá INP cho trang tìm kiếm

Để cải thiện INP của trang tìm kiếm, redBus đã thực hiện một số tối ưu hoá:

• Trình xử lý sự kiện scroll đã được gỡ bỏ để giảm số lần lệnh gọi lại sự kiện sẽ kích hoạt trong một khoảng thời gian nhất định. Bằng cách giảm tần suất chạy lệnh gọi lại sự kiện scroll, luồng chính có thể phản hồi nhanh hơn với các lượt tương tác của người dùng trên trang tìm kiếm.
• Công việc kết xuất thu được được ưu tiên bằng cách sử dụng lệnh gọi lại requestAnimationFrame. requestAnimationFrame cho trình duyệt biết rằng công việc trong lệnh gọi lại phải được thực hiện trước khung hình tiếp theo.

Trước: trình xử lý cuộn kích hoạt mà không áp dụng cho lệnh gọi lại sự kiện. Hiện có một số lượng đáng kể các tác vụ chặn trên luồng chính, điều này sẽ làm chậm trễ các hoạt động tương tác.

Sau: trình xử lý cuộn kích hoạt có áp dụng chế độ gỡ bỏ. Lệnh gọi lại sự kiện cuộn sẽ kích hoạt ít thường xuyên hơn, giúp luồng chính có nhiều cơ hội hơn để phản hồi hoạt động tương tác của người dùng.

Ngoài ra, chúng tôi đã tối ưu hoá thêm sau đây cho trang kết quả tìm kiếm:

• Các lô kết quả mới đã được tìm nạp từ thẻ thứ hai đến thẻ cuối cùng trên trang kết quả tìm kiếm để cải thiện trải nghiệm người dùng và hiệu suất hình ảnh bằng cách kích hoạt tính năng tải từng phần sớm hơn.
• Trong mỗi lệnh gọi mạng, có ít kết quả hơn được tìm nạp trong khi tải từng phần. Bằng cách giảm số lượt tìm nạp từ 30 xuống còn 10 kết quả, phạm vi INP giảm từ 870 xuống 900 xuống còn 350 đến 370 đã được quan sát thấy.

Hành vi tải từng phần dùng để tải giá vé bổ sung từ API khi cuộn. (Nhấp vào để xem phiên bản có độ phân giải cao hơn của video này.)

Mặc dù những thay đổi này đã cải thiện đáng kể INP của trang tìm kiếm, nhưng vẫn có vấn đề là sự kiện change trên các trường nhập dữ liệu của trang tìm kiếm sẽ gọi một hàm giảm tốn kém để cập nhật giao diện người dùng. Điều này dẫn đến việc kết xuất lại giao diện người dùng một cách không cần thiết, làm ảnh hưởng đến INP của trang.

Các giá trị INP được báo cáo trong bảng điều khiển khi người dùng nhập vào một trường nhập dữ liệu. Kết quả giá trị INP là 344 được quan sát trong môi trường phòng thí nghiệm nằm trong ngưỡng "cần cải thiện". (Nhấp vào để xem phiên bản có độ phân giải cao hơn của video này.)

Để tối ưu hoá hoạt động tương tác này, redBus đã quản lý trạng thái của các thành phần đầu vào một cách cục bộ và chỉ đồng bộ hoá trạng thái đó với cửa hàng Redux khi sự kiện blur của dữ liệu đầu vào được kích hoạt. Thay đổi này đã làm giảm số lần kết xuất lại và loại bỏ hoạt động kết xuất lại không mong muốn trên giao diện người dùng bằng cách gọi trình giảm tần suất ít hơn.

Cải thiện INP do gọi bộ giảm tần suất ít hơn khi thay đổi trường nhập dữ liệu. (Nhấp vào để xem phiên bản có độ phân giải cao hơn của video này.)

Nhờ thay đổi này, INP của trang đã cải thiện 72%, giúp mang lại trải nghiệm người dùng nhanh hơn và mượt mà hơn. Điều này giúp tăng khả năng tương tác của người dùng.

Tác động đối với công việc kinh doanh

Mối quan hệ giữa tình trạng kinh doanh và hiệu suất trang rất phổ biến. Mặc dù INP là một chỉ số tương đối mới so với các Chỉ số quan trọng về trang web khác, nhưng redBus nhận thấy kết quả kinh doanh khả quan hơn bằng cách tập trung vào việc cải thiện chỉ số hiệu suất quan trọng lấy người dùng làm trung tâm này. Kết quả là doanh số bán hàng tăng 7%.

Tóm lại, INP đã giúp vẽ nên bức tranh về các vấn đề về hiệu suất trong thời gian chạy trên trang web redBus. Với kiến thức cần cải thiện, redBus đã có thể quan sát vấn đề, tái tạo vấn đề và sử dụng thông tin quan trọng đó để tối ưu hoá có lợi cho redBus và hoạt động kinh doanh của nó.