Hiệu suất của các khung hiện đại theo chỉ số INP mới

Tìm hiểu mức độ ảnh hưởng của chỉ số INP mới đối với trải nghiệm của các trang web được xây dựng bằng khung và thư viện JavaScript.

Leena Sohoni
Leena Sohoni
Keen Yee Liau
Keen Yee Liau

Gần đây, Chrome đã ra mắt một chỉ số về khả năng phản hồi thử nghiệm mới trong báo cáo Báo cáo trải nghiệm người dùng trên Chrome. Chỉ số này (hiện được gọi là Lượt tương tác đến nội dung hiển thị tiếp theo (INP)) đo lường khả năng phản hồi tổng thể đối với các tương tác của người dùng trên trang. Hôm nay, chúng tôi muốn chia sẻ thông tin chi tiết về vị trí của các trang web được xây dựng bằng các khung JavaScript hiện đại liên quan đến chỉ số này. Chúng ta sẽ thảo luận về lý do INP có liên quan đến các khung và cách Aurora và các khung đang hoạt động để tối ưu hoá khả năng phản hồi.

Thông tin khái quát

Chrome sử dụng Độ trễ đầu vào đầu tiên (FID) trong Chỉ số quan trọng chính của trang web (CWV) để đo lường khả năng phản hồi khi tải của các trang web. FID đo lường thời gian chờ từ lượt tương tác đầu tiên của người dùng cho đến thời điểm trình duyệt có thể xử lý các trình xử lý sự kiện được kết nối với lượt tương tác đó. Chỉ số này không bao gồm thời gian xử lý trình xử lý sự kiện, xử lý các lượt tương tác tiếp theo trên cùng một trang hoặc vẽ khung hình tiếp theo sau khi các lệnh gọi lại sự kiện chạy. Tuy nhiên, khả năng thích ứng là yếu tố quan trọng đối với trải nghiệm người dùng trong suốt vòng đời của trang vì người dùng dành khoảng 90% thời gian trên một trang sau khi trang đó tải xong.

INP đo lường thời gian mà một trang web cần để phản hồi hoạt động tương tác của người dùng, tính từ thời điểm người dùng bắt đầu tương tác cho đến thời điểm khung hình tiếp theo được vẽ trên màn hình. Với INP, chúng tôi hy vọng có thể cung cấp một chỉ số tổng hợp cho độ trễ nhận thấy được của tất cả các lượt tương tác trong vòng đời của trang. Chúng tôi tin rằng INP sẽ cung cấp thông tin ước tính chính xác hơn về tốc độ tải và khả năng phản hồi trong thời gian chạy của các trang web.

Vì FID chỉ đo lường độ trễ đầu vào của lượt tương tác đầu tiên, nên có thể các nhà phát triển web chưa chủ động tối ưu hoá các lượt tương tác tiếp theo trong quá trình cải thiện CWV. Do đó, các trang web, đặc biệt là những trang web có mức độ tương tác cao, sẽ phải bắt đầu nỗ lực để đạt được kết quả tốt về chỉ số này.

Vai trò của khung

Vì nhiều trang web dựa vào JavaScript để cung cấp tính tương tác, nên điểm INP chủ yếu chịu ảnh hưởng của lượng JavaScript được xử lý trên luồng chính. Khung JavaScript là một phần thiết yếu của quá trình phát triển web giao diện người dùng hiện đại, đồng thời cung cấp cho nhà phát triển các tính năng trừu tượng có giá trị để định tuyến, xử lý sự kiện và phân chia mã JavaScript. Do đó, các thuộc tính này đóng vai trò trung tâm trong việc tối ưu hoá khả năng thích ứng và trải nghiệm người dùng của những trang web sử dụng các thuộc tính này.

Các khung có thể đã thực hiện các bước để cải thiện khả năng phản hồi bằng cách cải thiện FID cho trang web trước đó. Tuy nhiên, giờ đây, họ sẽ phải phân tích dữ liệu chỉ số về khả năng thích ứng hiện có và nỗ lực giải quyết mọi vấn đề đã xác định. Nhìn chung, INP có xu hướng có tỷ lệ vượt qua thấp hơn và sự khác biệt trong quá trình đo lường đòi hỏi phải tối ưu hoá thêm mã. Bảng sau đây tóm tắt lý do.

FID (Thời gian phản hồi lần tương tác đầu tiên) INP
Đo lường Đo lường khoảng thời gian từ khi người dùng nhập dữ liệu đầu tiên cho đến thời điểm trình xử lý sự kiện tương ứng chạy. Đo lường độ trễ tương tác tổng thể bằng cách sử dụng độ trễ của
Tuỳ thuộc vào Luồng chính có sẵn để chạy trình xử lý sự kiện bắt buộc cho lượt tương tác đầu tiên. Luồng chính có thể bị chặn vì đang xử lý các tài nguyên khác trong quá trình tải trang ban đầu. Tình trạng sẵn có của luồng chính và kích thước của tập lệnh do trình xử lý sự kiện thực thi cho các lượt tương tác khác nhau, bao gồm cả lượt tương tác đầu tiên.
Nguyên nhân chính khiến điểm số thấp FID kém chủ yếu là do quá trình thực thi JavaScript nặng trên luồng chính. JavaScript xử lý sự kiện nặng và các tác vụ kết xuất khác sau khi chạy trình xử lý có thể dẫn đến INP kém.
Tối ưu hoá Bạn có thể tối ưu hoá FID bằng cách cải thiện quá trình tải tài nguyên khi tải trang và tối ưu hoá mã JavaScript. Tương tự như FID cho mọi lượt tương tác, cộng với việc sử dụng các mẫu kết xuất ưu tiên các bản cập nhật trải nghiệm người dùng chính so với các tác vụ kết xuất khác.
FID so với INP: Đo lường và tối ưu hoá

Nhóm Aurora trong Chrome hợp tác với các khung web nguồn mở để giúp nhà phát triển cải thiện nhiều khía cạnh của trải nghiệm người dùng, bao gồm cả hiệu suất và các chỉ số CWV. Khi ra mắt INP, chúng tôi muốn chuẩn bị cho sự thay đổi trong các chỉ số CWV đối với các trang web dựa trên khung. Chúng tôi đã thu thập dữ liệu dựa trên chỉ số phản hồi thử nghiệm trong báo cáo CrUX. Chúng tôi sẽ chia sẻ thông tin chi tiết và các việc cần làm để giúp bạn dễ dàng chuyển đổi sang chỉ số INP cho các trang web dựa trên khung.

Dữ liệu chỉ số về khả năng thích ứng thử nghiệm

INP dưới hoặc bằng 200 mili giây cho biết khả năng phản hồi tốt. Dữ liệu báo cáo CrUX và Báo cáo công nghệ CWV tháng 6 năm 2023 cung cấp cho chúng tôi những thông tin sau đây về khả năng thích ứng của các khung JavaScript phổ biến.

Công nghệ % Chuyền bóng
% Thiết bị di động Máy tính
Angular (phiên bản 2.0.0 trở lên) 28,6 83,6
Next.js 28,5 87,3
Nuxt.js 32.0 91,2
Preact 48,6 92,8
Vue (phiên bản 2.0.0 trở lên) 50,3 94,1
Lit 50 88,3
Báo cáo công nghệ CWV – Dữ liệu INP cho tháng 6 năm 2023

Bảng này cho biết tỷ lệ phần trăm nguồn gốc trên mỗi khung có điểm phản hồi tốt. Những con số này rất đáng khích lệ nhưng cũng cho thấy chúng ta còn nhiều điều phải cải thiện.

JavaScript ảnh hưởng như thế nào đến INP?

Các giá trị INP trong thực tế có mối tương quan tốt với Tổng thời gian chặn (TBT) được quan sát trong phòng thí nghiệm. Điều này có thể ngụ ý rằng mọi tập lệnh chặn luồng chính trong thời gian dài đều không tốt cho INP. Việc thực thi JavaScript nặng sau bất kỳ lượt tương tác nào có thể chặn luồng chính trong một khoảng thời gian dài và trì hoãn phản hồi đối với lượt tương tác đó. Sau đây là một số nguyên nhân phổ biến dẫn đến việc chặn tập lệnh:

  • JavaScript chưa được tối ưu hoá: Mã thừa hoặc chiến lược phân tách và tải mã kém có thể khiến JavaScript bị phình to và chặn luồng chính trong thời gian dài. Tính năng phân tách mã, tải dần và chia các tác vụ dài có thể cải thiện đáng kể thời gian phản hồi.

  • Tập lệnh của bên thứ ba: Tập lệnh của bên thứ ba (đôi khi không bắt buộc phải xử lý một lượt tương tác (ví dụ: tập lệnh quảng cáo)) có thể chặn luồng chính và gây ra độ trễ không cần thiết. Việc ưu tiên các tập lệnh thiết yếu có thể giúp giảm tác động tiêu cực của các tập lệnh bên thứ ba.

  • Nhiều trình xử lý sự kiện: Nhiều trình xử lý sự kiện liên kết với mọi lượt tương tác, mỗi trình xử lý chạy một tập lệnh khác nhau, có thể can thiệp lẫn nhau và cộng lại gây ra độ trễ lâu. Một số tác vụ trong số này có thể không cần thiết và có thể được lên lịch trên một worker web hoặc khi trình duyệt ở trạng thái rảnh.

  • Chi phí khung khi xử lý sự kiện: Khung có thể có các tính năng/ngữ pháp bổ sung để xử lý sự kiện. Ví dụ: Vue sử dụng v-on để đính kèm trình nghe sự kiện vào các phần tử, trong khi Angular gói trình xử lý sự kiện của người dùng. Để triển khai các tính năng này, bạn cần thêm mã khung trên JavaScript cơ bản.

  • Hydration (Tái tạo): Khi sử dụng khung JavaScript, không có gì lạ khi máy chủ tạo HTML ban đầu cho một trang, sau đó cần được bổ sung trình xử lý sự kiện và trạng thái ứng dụng để có thể tương tác trong trình duyệt web. Chúng tôi gọi quá trình này là hydrat hoá. Đây có thể là một quá trình nặng trong quá trình tải, tuỳ thuộc vào thời gian JavaScript cần để tải và hoàn tất quá trình hydrat hoá. Điều này cũng có thể khiến các trang trông có vẻ tương tác khi thực tế không phải vậy. Thông thường, quá trình hydrat hoá diễn ra tự động trong quá trình tải trang hoặc tải từng phần (ví dụ: khi người dùng tương tác) và có thể ảnh hưởng đến INP hoặc thời gian xử lý do việc lên lịch tác vụ. Trong các thư viện như React, bạn có thể tận dụng useTransition để một phần kết xuất thành phần nằm trong khung tiếp theo và mọi hiệu ứng phụ tốn kém hơn sẽ được chuyển sang các khung trong tương lai. Do đó, các nội dung cập nhật trong quá trình chuyển đổi dẫn đến các nội dung cập nhật cấp thiết hơn như lượt nhấp có thể là một mẫu phù hợp với INP.

  • Tải trước: Việc tải trước tích cực các tài nguyên cần thiết cho các thao tác điều hướng tiếp theo có thể giúp cải thiện hiệu suất nếu được thực hiện đúng cách. Tuy nhiên, nếu tải trước và hiển thị đồng bộ các tuyến SPA, bạn có thể ảnh hưởng tiêu cực đến INP vì tất cả các lượt kết xuất tốn kém này đều cố gắng hoàn tất trong một khung hình. Hãy so sánh điều này với việc không tải trước tuyến đường của bạn mà thay vào đó là bắt đầu công việc cần thiết (ví dụ: fetch()) và bỏ chặn sơn. Bạn nên kiểm tra lại xem phương pháp của khung để tải trước có mang lại trải nghiệm người dùng tối ưu hay không và mức độ tác động của phương pháp này đến INP (nếu có).

Từ giờ trở đi, để có điểm INP cao, nhà phát triển sẽ phải tập trung xem xét mã thực thi sau mỗi lượt tương tác trên trang và tối ưu hoá chiến lược phân đoạn, tái tạo, tải cũng như kích thước của mỗi bản cập nhật render() cho cả tập lệnh của bên thứ nhất và bên thứ ba,

Aurora và các khung xử lý vấn đề INP như thế nào?

Aurora hoạt động với các khung bằng cách kết hợp các phương pháp hay nhất để cung cấp các giải pháp tích hợp sẵn cho các vấn đề thường gặp. Chúng tôi đã làm việc với Next.js, Nuxt.js, Gatsby và Angular về các giải pháp cung cấp các giá trị mặc định mạnh mẽ trong khung để tối ưu hoá hiệu suất. Sau đây là những điểm nổi bật trong công việc của chúng tôi trong bối cảnh này:

  • React và Next.js: Thành phần tập lệnh Next.js giúp giải quyết các vấn đề phát sinh do việc tải tập lệnh của bên thứ ba không hiệu quả. Tính năng chia nhỏ chi tiết được giới thiệu trong Next.js để cho phép chia nhỏ mã dùng chung thành các phần có kích thước nhỏ hơn. Điều này giúp giảm lượng mã chung không dùng đến được tải xuống trên tất cả các trang. Chúng tôi cũng đang hợp tác với Next.js để cung cấp dữ liệu INP trong dịch vụ Analytics của họ.

  • Angular: Aurora đang hợp tác với nhóm Angular để khám phá các điểm cải tiến về kết xuất phía máy chủ và tính năng hydrat hoá. Chúng tôi cũng dự định xem xét các điểm tinh chỉnh trong việc xử lý sự kiện và phát hiện thay đổi để cải thiện INP.

  • Vue và Nuxt.js: Chúng tôi đang khám phá các phương pháp cộng tác, chủ yếu liên quan đến việc tải và hiển thị tập lệnh.

Các khung đang suy nghĩ như thế nào về việc cải thiện INP?

React và Next.js

Tính năng chia nhỏ thời gian của React.js, được triển khai thông qua startTransitionSuspense, cho phép bạn chọn sử dụng tính năng hydrat hoá có chọn lọc hoặc tăng dần. Điều này có nghĩa là quá trình hydrat hoá không phải là một khối đồng bộ. Quá trình này được thực hiện theo các lát nhỏ có thể bị gián đoạn bất cứ lúc nào.

Điều này sẽ giúp cải thiện INP và cho phép bạn phản hồi nhanh hơn các thao tác nhấn phím, hiệu ứng di chuột trong quá trình chuyển đổi và lượt nhấp. Điều này cũng giúp ứng dụng React luôn thích ứng ngay cả khi chuyển đổi lớn như tự động hoàn thành.

Next.js đã triển khai một khung định tuyến mới sử dụng startTransition theo mặc định cho các lượt chuyển đổi tuyến. Điều này cho phép chủ sở hữu trang web Next.js sử dụng tính năng cắt thời gian React và cải thiện khả năng phản hồi của các lượt chuyển đổi tuyến.

Angular

Nhóm Angular đang khám phá một số ý tưởng cũng sẽ giúp ích cho INP:

  • Không phân vùng: Giảm kích thước gói ban đầu và mã bắt buộc phải tải trước khi ứng dụng có thể hiển thị bất kỳ nội dung nào.
  • Hydration: Chế độ hydrat hoá kiểu đảo để giới hạn lượng ứng dụng cần được đánh thức để tương tác.
  • Giảm hao tổn của CD: Ví dụ: giảm chi phí phát hiện thay đổi, tìm cách kiểm tra ít ứng dụng hơn và tận dụng các tín hiệu phản ứng về nội dung đã thay đổi.
  • Chia mã chi tiết hơn: Làm cho gói ban đầu nhỏ hơn.
  • Hỗ trợ tốt hơn cho chỉ báo tải: Ví dụ: trong quá trình kết xuất lại SSR, trong quá trình điều hướng tuyến và trong các thao tác tải lười.
  • Công cụ phân tích tài nguyên: Các công cụ phát triển hiệu quả hơn để hiểu rõ chi phí tương tác, đặc biệt là chi phí phát hiện thay đổi cho các lượt tương tác cụ thể.

Thông qua những điểm cải tiến này, chúng tôi có thể giải quyết nhiều vấn đề dẫn đến trải nghiệm người dùng và khả năng phản hồi kém, đồng thời cải thiện chỉ số CWV và chỉ số INP mới cho các trang web dựa trên khung.

Kết luận

Chúng tôi dự kiến điểm INP sẽ cung cấp thông tin hữu ích hơn cho các trang web để cải thiện khả năng phản hồi và hiệu suất trong tương lai. Chúng tôi sẽ xây dựng dựa trên hướng dẫn hiện có về INP để cung cấp thêm các mẹo hữu ích cho nhà phát triển khung trong năm 2023. Chúng tôi hy vọng đạt được điều này bằng cách:

  • Tạo kênh để dễ dàng truy cập vào dữ liệu thực địa trên INP cho các khung và nhà phát triển web.
  • Làm việc với các khung để xây dựng các tính năng sẽ cải thiện INP theo mặc định.

Chúng tôi hoan nghênh ý kiến phản hồi của người dùng khung khi họ bắt đầu hành trình tối ưu hoá INP.