Tối ưu hoá thời gian phản hồi lần tương tác đầu tiên

Cách phản hồi tương tác của người dùng nhanh hơn.

Addy Osmani

Houssein Djirdeh

Tôi đã nhấp vào nhưng không có gì xảy ra! Tại sao tôi không thể tương tác với trang này? 😢

Nội dung đầu tiên hiển thị (FCP) và Nội dung lớn nhất Thời gian hiển thị (LCP) là hai chỉ số đo lường thời gian cần thiết để nội dung hiển thị trực quan (hiển thị) trên một trang. Mặc dù quan trọng, thời gian sơn không thể hiện tải khả năng phản hồi: hoặc tốc độ trang phản hồi với tương tác của người dùng.

Độ trễ đầu vào lần đầu (FID) là một chỉ số Core Web Vitals, ghi nhận dữ liệu ấn tượng đầu tiên về khả năng tương tác và khả năng phản hồi của trang web. Chỉ số này đo lường thời gian kể từ khi người dùng tương tác lần đầu với một trang vào thời điểm trình duyệt thực sự có thể phản hồi trang đó tương tác. FID là một chỉ số trường và không thể được mô phỏng trong môi trường phòng thí nghiệm. Bạn phải có tương tác thực của người dùng để đo lường độ trễ phản hồi.

Để giúp dự đoán FID trong phòng thí nghiệm này, chúng tôi đề xuất Tổng thời gian chặn (TBT). Chúng đo lường những yếu tố khác nhau, nhưng mức cải thiện về TBT thường tương ứng với mức cải thiện về FID (Độ trễ đầu vào đầu tiên).

Nguyên nhân chính gây ra FID kém là quá trình thực thi JavaScript nặng. Tối ưu hoá cách phân tích cú pháp JavaScript, biên dịch và thực thi trên trang web của bạn sẽ trực tiếp giảm FID.

Thực thi JavaScript nặng

Trình duyệt không thể phản hồi hầu hết hoạt động đầu vào của người dùng trong khi thực thi JavaScript trên luồng chính. Nói cách khác, trình duyệt không thể phản hồi hoạt động tương tác của người dùng trong khi luồng chính đang bận. Cách cải thiện:

• Chia nhỏ những việc cần làm dài
• Tối ưu hoá trang của bạn để sẵn sàng tương tác
• Sử dụng trình chạy web
• Giảm thời gian thực thi JavaScript

Chia nhỏ những việc cần làm dài

Nếu bạn đã cố gắng giảm lượng JavaScript tải trên một trang, thì việc này có thể sẽ hữu ích khi chia nhỏ mã chạy trong thời gian dài thành các tác vụ nhỏ hơn, không đồng bộ.

Tác vụ dài là khoảng thời gian thực thi JavaScript mà người dùng có thể thấy giao diện người dùng không phản hồi. Bất kỳ đoạn mã nào chặn luồng chính trong 50 mili giây trở lên đều có thể đặc trưng là Nhiệm vụ dài. Việc cần làm dài là dấu hiệu của có thể khiến JavaScript trống (đang tải và thực thi nhiều hơn mức người dùng có thể cần ngay bây giờ). Việc chia nhỏ các tác vụ dài có thể làm giảm độ trễ đầu vào trên trang web của bạn.

FID sẽ cải thiện đáng kể khi bạn áp dụng các phương pháp hay nhất như tách mã và chia nhỏ Nhiệm vụ dài. Mặc dù TBT không phải là một chỉ số thực tế, nhưng nó rất hữu ích trong việc kiểm tra tiến trình hướng tới mục tiêu cuối cùng cải thiện cả Thời gian tương tác (TTI) và FID.

Tối ưu hoá trang của bạn để sẵn sàng tương tác

Có một số nguyên nhân phổ biến dẫn đến điểm FID và TBT thấp trong các ứng dụng web phụ thuộc nhiều vào JavaScript:

Quá trình thực thi tập lệnh của bên thứ nhất có thể trì hoãn mức độ sẵn sàng tương tác

• Việc tăng kích thước JavaScript, thời gian thực thi lớn và phân đoạn không hiệu quả có thể làm chậm tốc độ có thể phản hồi với hoạt động đầu vào của người dùng cũng như tác động đến FID, TBT và TTI. Tải dần mã và có thể giúp lan toả bài tập này và cải thiện mức độ sẵn sàng tương tác.
• Các ứng dụng được kết xuất phía máy chủ có thể trông giống như các pixel được vẽ trên màn hình nhanh chóng, nhưng hãy coi chừng các hoạt động tương tác của người dùng sẽ bị chặn bởi các lượt thực thi tập lệnh lớn (ví dụ: tái cấp nước để kết nối trình nghe sự kiện). Quá trình này có thể mất vài trăm mili giây, đôi khi vài giây nếu phân tách mã dựa trên tuyến đang được sử dụng. Cân nhắc thay đổi thêm logic phía máy chủ hoặc tạo thêm nội dung theo phương thức tĩnh trong thời gian xây dựng.

Dưới đây là điểm TBT trước và sau khi tối ưu hoá việc tải tập lệnh của bên thứ nhất cho một . Bằng cách di chuyển hoạt động tải (và thực thi) tập lệnh tốn kém cho một thành phần không thiết yếu ra khỏi đường dẫn quan trọng, người dùng đã có thể tương tác với trang nhanh hơn nhiều.

Việc tìm nạp dữ liệu có thể tác động đến nhiều khía cạnh của mức độ sẵn sàng tương tác

• Việc chờ đợi một luồng tìm nạp theo tầng (ví dụ: JavaScript và tìm nạp dữ liệu cho các thành phần) có thể ảnh hưởng đến độ trễ tương tác. Vì vậy, bạn cần giảm thiểu sự phụ thuộc vào hoạt động tìm nạp dữ liệu theo tầng.
• Các kho dữ liệu lớn cùng dòng có thể đẩy nhanh thời gian phân tích cú pháp HTML và ảnh hưởng đến cả việc hiển thị và tương tác chỉ số. Cố gắng giảm thiểu lượng dữ liệu cần được xử lý ở phía máy khách.

Quá trình thực thi tập lệnh của bên thứ ba cũng có thể trì hoãn độ trễ tương tác

• Nhiều trang web bao gồm thẻ và công cụ phân tích của bên thứ ba có thể khiến mạng bận và làm cho luồng chính không phản hồi định kỳ, ảnh hưởng đến độ trễ tương tác. Khám phá tải mã của bên thứ ba theo yêu cầu (ví dụ: có thể không tải các quảng cáo dưới màn hình đầu tiên đó cho đến khi họ sẽ cuộn gần hơn đến khung nhìn).
• Trong một số trường hợp, tập lệnh của bên thứ ba có thể giành trước tập lệnh của bên thứ nhất về mức độ ưu tiên và băng thông trên luồng chính, đồng thời làm trì hoãn việc một trang sẵn sàng tương tác trong bao lâu. Cố gắng ưu tiên tải những nội dung mà bạn cho rằng sẽ mang lại giá trị cao nhất cho người dùng trước.

Sử dụng trình chạy web

Luồng chính bị chặn là một trong những nguyên nhân chính gây ra độ trễ đầu vào. Web trình thực thi giúp bạn chạy JavaScript trên một luồng ở chế độ nền. Việc di chuyển các thao tác không phải giao diện người dùng sang một luồng worker riêng biệt có thể cắt bỏ lệnh chính thời gian chặn luồng và do đó cải thiện FID.

Hãy cân nhắc sử dụng các thư viện sau để giúp bạn dễ dàng sử dụng trình chạy web trên trang web của mình hơn:

• Comlink: Thư viện trợ giúp trừu tượng postMessage để dễ sử dụng hơn
• Workway: Một trình xuất trình chạy web dành cho nhiều mục đích
• Workerize: Di chuyển mô-đun vào web worker

Giảm thời gian thực thi JavaScript

Việc giới hạn số lượng JavaScript trên trang của bạn sẽ giúp giảm lượng thời gian mà trình duyệt cần dành thời gian thực thi mã JavaScript. Công cụ này giúp tăng tốc độ mà trình duyệt có thể bắt đầu phản hồi với bất kỳ tương tác của người dùng.

Cách giảm số lượng JavaScript được thực thi trên trang của bạn:

• Trì hoãn JavaScript không dùng
• Giảm thiểu polyfill không dùng đến

Trì hoãn JavaScript không dùng

Theo mặc định, tất cả JavaScript đều đang chặn hiển thị. Khi trình duyệt gặp một thẻ tập lệnh liên kết đến tệp JavaScript bên ngoài, tệp này phải tạm dừng những gì đang thực hiện và tải xuống, phân tích cú pháp, biên dịch và thực thi JavaScript đó. Do đó, bạn chỉ nên tải mã cần thiết cho trang hoặc phản hồi hoạt động đầu vào của người dùng.

Thẻ Phạm vi bao phủ trong Chrome Công cụ cho nhà phát triển có thể cho bạn biết lượng JavaScript hiện không được sử dụng trên trang web của bạn.

Cách giảm bớt JavaScript không dùng đến:

• Chia mã thành nhiều phần
• Trì hoãn mọi JavaScript không quan trọng, kể cả tập lệnh bên thứ ba, bằng cách sử dụng async hoặc defer

Phân tách mã là khái niệm chia một gói JavaScript lớn thành các phần nhỏ hơn có thể tải theo điều kiện (còn gọi là tải từng phần). Hầu hết các trình duyệt mới đều hỗ trợ cú pháp nhập động, cho phép tìm nạp mô-đun theo yêu cầu:

import('module.js').then((module) => {
  // Do something with the module.
});

Tự động nhập JavaScript trên một số tương tác nhất định của người dùng (chẳng hạn như thay đổi tuyến hoặc hiển thị cửa sổ phụ) sẽ đảm bảo mã không dùng cho lần tải trang ban đầu chỉ được tìm nạp khi cần thiết.

Ngoài việc hỗ trợ trình duyệt chung, cú pháp nhập động có thể được sử dụng trong nhiều bản dựng khác nhau hệ thống.

• Nếu bạn sử dụng webpack, Tổng hợp, hoặc Parcel như một bộ gói mô-đun, hãy tận dụng tính năng hỗ trợ nhập linh động.
• Khung phía máy khách, chẳng hạn như Phản ứng, Angular và Vue cung cấp các đối tượng trừu tượng để dễ dàng tải từng phần ở cấp thành phần.

Ngoài việc phân tách mã, hãy luôn sử dụng chế độ không đồng bộ hoặc trì hoãn các tập lệnh không cần thiết cho đường dẫn quan trọng hoặc nội dung trong màn hình đầu tiên.

<script defer src="…"></script>
<script async src="…"></script>

Trừ phi có lý do cụ thể để từ chối, tất cả tập lệnh bên thứ ba đều phải được tải bằng defer hoặc async theo mặc định.

Giảm thiểu polyfill không dùng đến

Nếu bạn viết mã bằng cú pháp JavaScript hiện đại và tham chiếu các API trình duyệt hiện đại, bạn sẽ cần phải chuyển đổi mã đó và đưa vào các đoạn mã polyfill để hoạt động trong các trình duyệt cũ hơn.

Một trong những vấn đề chính về hiệu suất khi thêm đoạn mã polyfill và mã được chuyển mã vào trang web của bạn là các trình duyệt mới hơn không cần phải tải xuống nếu không cần. Để cắt giảm JavaScript kích thước ứng dụng của bạn, giảm thiểu các polyfill không dùng đến nhiều nhất có thể và hạn chế việc sử dụng chúng ở môi trường cần thiết.

Cách tối ưu hoá việc sử dụng đoạn mã polyfill trên trang web của bạn:

• Nếu bạn sử dụng Babel làm bộ phiên dịch, hãy sử dụng @babel/preset-env để chỉ bao gồm các đoạn mã polyfill cần thiết cho các trình duyệt mà bạn dự định nhắm mục tiêu. Đối với Squarespace 7.9, hãy bật Lựa chọn bugfixes để cắt giảm thêm trên bất kỳ đoạn mã polyfill không cần thiết

• Sử dụng mẫu mô-đun/không mô-đun để phân phối 2 gói riêng biệt (cũng @babel/preset-env hỗ trợ điều này qua target.esmodules)

  <script type="module" src="modern.js"></script>
  <script nomodule src="legacy.js" defer></script>
  

  Nhiều tính năng ECMAScript mới được biên dịch bằng adb đã được hỗ trợ trong các môi trường hỗ trợ các mô-đun JavaScript. Bằng cách này, bạn sẽ đơn giản hoá quy trình đảm bảo rằng chỉ sử dụng mã đã dịch cho các trình duyệt thực sự cần mã đó.

Công cụ dành cho nhà phát triển

Có một số công cụ giúp đo lường và gỡ lỗi FID:

• Lighthouse 6.0 không bao gồm hỗ trợ cho FID vì đây là chỉ số trường. Tuy nhiên, Chặn hoàn toàn Bạn có thể dùng thời gian (TBT) làm proxy. Các phương pháp tối ưu hoá giúp cải thiện TBT cũng cải thiện FID trong lĩnh vực này.

  

• Báo cáo trải nghiệm người dùng trên Chrome cung cấp các giá trị FID thực tế được tổng hợp ở cấp độ gốc

Cảm ơn Philip Walton, Kayce Basques, Ilya Grigorik và Annie Sullivan vì những bài đánh giá của họ.