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

Tìm hiểu cách chỉ số INP mới ảnh hưởng đến trải nghiệm của những trang web được tạo bằng khung và thư viện JavaScript.

Leena Sohoni
Leena Sohoni
Addy OSmani
Addy OSmani
Keen Yee Liau
Keen Yee Liau

Gần đây, Chrome đã giới thiệu chỉ số 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 với 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 lượt 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ề mối quan hệ giữa các trang web được tạo bằng khung JavaScript hiện đại. Chúng ta sẽ thảo luận về lý do INP liên quan đến khung làm việc, cũng như cách Aurora và các khung làm việc đ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 Thời gian phản hồi lần tương tác đầu tiên (FID) trong Các chỉ số quan trọng về trang web (CWV) để đo lường khả năng phản hồi khi tải của 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 đến thời điểm trình duyệt có thể xử lý những trình xử lý sự kiện được kết nối với lượt tương tác đó. Thời gian này không bao gồm thời gian để xử lý các trình xử lý sự kiện, xử lý các hoạt động 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 đóng vai trò 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.

INP đo lường thời gian mà một trang web cần để phản hồi các hoạt động tương tác của người dùng kể từ khi người dùng bắt đầu tương tác cho đến khi khung tiếp theo được hiển thị trên màn hình. Với INP, chúng tôi hy vọng có thể đo lường tổng hợp độ trễ dự kiến 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 số liệu ước tính chính xác hơn về khả năng tải và phản hồi trong thời gian chạy của 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ó khả năng 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 có mức độ tương tác cao, sẽ phải bắt đầu nỗ lực để đạt được tốt chỉ số này.

Vai trò của khung

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

Khung có thể đã thực hiện các bước để tăng khả năng phản hồi tốt hơn bằng cách cải thiện FID cho các trang web sớm hơn. Tuy nhiên, giờ đây, họ sẽ phải phân tích dữ liệu chỉ số phản hồi hiện có và tìm cách khắc phục mọi sự thiếu hụt được xác định. Nhìn chung, INP thường có tỷ lệ truyền thấp hơn và sự khác biệt trong quy trình đo lường yêu cầu phải tối ưu hoá mã bổ sung. 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ừ lần đầu tiên người dùng nhập vào đến khi 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
Phụ thuộc vào Khả năng sử dụng luồng chính để chạy trình xử lý sự kiện cần thiết 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 lượt tải trang ban đầu. Kích thước và khả năng sử dụng của luồng chính của tập lệnh được trình xử lý sự kiện thực thi cho nhiều lượt tương tác, bao gồm cả lượt tương tác đầu tiên.
Nguyên nhân chính khiến điểm số kém FID kém chủ yếu là do 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ụ hiển thị 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 khả năng tải tài nguyên khi tải trang và tối ưu hoá mã JavaScript. Tương tự như FID đối với 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 chính về trải nghiệm người dùng so với các tác vụ hiển thị khác.
FID so với INP: Đo lường và tối ưu hoá

Nhóm Aurora trong Chrome phối hợp 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ả chỉ số hiệu suất và CWV. Với sự ra mắt của INP, chúng ta muốn chuẩn bị cho sự thay đổi về chỉ số CWV cho trang web dựa trên khung. Chúng tôi đã thu thập dữ liệu dựa trên chỉ số thử nghiệm về khả năng phản hồi trong các báo cáo CrUX. Chúng tôi sẽ chia sẻ thông tin chi tiết và các mục hành động để giúp quá trình chuyển đổi sang chỉ số INP diễn ra dễ dàng hơn cho các trang web dựa trên khung.

Dữ liệu chỉ số về khả năng phản hồi thử nghiệm

INP dưới hoặc bằng 200 mili giây cho thấy tốc độ phản hồi tốt. Dữ liệu báo cáo CrUX và Báo cáo về công nghệ CWV vào 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 phản hồi của các khung JavaScript phổ biến.

Công nghệ Tỷ lệ chuyền bóng
% Thiết bị di động Máy tính
Angular (v2.0.0 trở lên) 28,6 83,6
Next.js 28,5 87,3
Nuxt.js 32 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 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 khả quan nhưng cho chúng tôi biết rằng vẫn còn nhiều khả năng cần cải thiện.

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

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

  • JavaScript không được tối ưu hoá: Mã dư thừa hoặc chiến lược tải và phân tách mã kém có thể khiến JavaScript trở nên cồng kềnh và chặn chuỗi chính trong thời gian dài. Việc phân tách mã, tải tăng dần và chia nhỏ 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: Các tập lệnh của bên thứ ba (đôi khi không bắt buộc phải dùng để xử lý một lượt tương tác (ví dụ: tập lệnh quảng cáo)) có thể chặn chuỗi chính và gây ra sự chậm trễ không cần thiết. Việc ưu tiên các tập lệnh quan trọng có thể giúp giảm tác động tiêu cực của các tập lệnh của bên thứ ba.

  • Nhiều trình xử lý sự kiện: Nhiều trình xử lý sự kiện được 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ể ảnh hưởng lẫn nhau và gây chậm trễ trong thời gian dài. 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 thông qua trình thực thi 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ó thêm tính năng/cú pháp để 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 các trình xử lý sự kiện người dùng. Việc triển khai các tính năng này yêu cầu mã khung bổ sung cao hơn JavaScript vanilla.

  • Hydration: Khi sử dụng khung JavaScript, việc máy chủ tạo HTML ban đầu cho một trang sau đó cần được tăng cường bằng các trình xử lý sự kiện và trạng thái ứng dụng để có thể tương tác được trong trình duyệt web. Chúng tôi gọi quá trình này là quá trình hydrat hoá. Đây có thể là một quá trình nặng nề trong quá trình tải, tuỳ thuộc vào thời gian tải JavaScript và quá trình hydrat nước kết thúc. Điều này cũng có thể dẫn đến việc các trang trông có vẻ tương tác nhưng thực tế thì không. Thông thường, quá trình hydrat hoá diễn ra tự động trong quá trình tải trang hoặc 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 của quá trình kết xuất thành phần nằm trong khung hình tiếp theo và mọi hiệu ứng phụ tốn kém hơn sẽ bị để lại các khung hình trong tương lai. Do đó, các bản cập nhật trong quá trình chuyển đổi giúp cập nhật khẩn cấp hơn như nhấp chuột có thể là một mẫu hình tốt cho INP.

  • Tìm nạp trước: Tìm nạp trước linh hoạt các tài nguyên cần thiết cho các lần điều hướng tiếp theo có thể mang lại hiệu quả cao nếu được thực hiện đúng cách. Tuy nhiên, nếu tìm nạp trước và kết xuất các tuyến SPA một cách đồng bộ, thì bạn có thể ảnh hưởng tiêu cực đến INP vì tất cả quá trình kết xuất tốn kém này đều cố gắng hoàn tất trong một khung duy nhất. Ngược lại, việc này với việc không tìm nạp trước tuyến đường của bạn mà thay vào đó, khởi động 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 tìm nạp trước của khung ứng dụng có đang cung cấp trải nghiệm người dùng tối ưu hay không và mức độ (nếu có) của điều này có thể ảnh hưởng đến INP.

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

Aurora và các khuôn khổ giải quyết các vấn đề liên quan đến INP như thế nào?

Aurora hoạt động với các khung thiết kế 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 đã hợp tác với Next.js, Nuxt.js, Gatsby và Angular về các giải pháp cung cấp các giải pháp mặc định hiệu quả trong khung để tối ưu hoá hiệu suất. Sau đây là những điểm nổi bật về 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 Next.js Script giúp giải quyết các vấn đề gây ra do việc tải tập lệnh của bên thứ ba không hiệu quả. Tính năng Phân đoạn chi tiết đã được ra mắt trong Next.js để cho phép các phân đoạn có kích thước nhỏ hơn cho mã được chia sẻ. Điều này giúp giảm số lượng mã thông thường 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 làm việ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á những điểm cải tiến về khả năng hiển thị và hydrat hoá phía máy chủ. Chúng tôi cũng dự định xem xét các hoạt động tinh chỉnh trong quá trình 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 cách 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 chương trình đang nghĩ đến việc cải thiện INP như thế nào?

React và Next.js

Tính năng cắt 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 chế độ 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ộ. Hoạt động này được thực hiện theo các phần nhỏ và có thể gây gián đoạn tại bất cứ thời điểm 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 với các thao tác nhấn phím, hiệu ứng di chuột trong quá trình chuyển đổi và các lượt nhấp. Điều này cũng giúp đảm bảo khả năng thích ứng của ứng dụng ngay cả với các hiệu ứng 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 để chuyển đổi tuyến đường. Điều này cho phép chủ sở hữu trang web Next.js áp dụng tính năng cắt lát thời gian React và cải thiện khả năng phản hồi của các chuyển đổi tuyến.

Angular

Nhóm Angular đang tìm hiểu một số ý tưởng cũng sẽ giúp ích cho INP:

  • Không có 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ể kết xuất nội dung.
  • Hydration (Lượng nước uống): Lượng nước uống kiểu đảo để giới hạn lượng ứng dụng cần được đánh thức để tương tác.
  • Giảm mức 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ề những thay đổi.
  • Phân tách mã chi tiết hơn: Thu nhỏ gói ban đầu.
  • Hỗ trợ tốt hơn cho các chỉ báo tải: Ví dụ như trong quá trình kết xuất lại SSR, trong khi điều hướng tuyến đường và trong hoạt động tải từng phần.
  • Công cụ phân tích tài nguyên: Các công cụ cho nhà phát triển tốt hơn để hiểu chi phí tương tác, đặc biệt là xoay quanh chi phí phát hiện thay đổi cho các tương tác cụ thể.

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

Kết luận

Chúng tôi hy vọng điểm INP sẽ cung cấp la bàn tốt 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 các nhà phát triển khung vào 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 về 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 giúp cải thiện INP theo mặc định.

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