Quan niệm sai lầm thường gặp về cách tối ưu hoá LCP

Việc cải thiện Thời gian hiển thị nội dung lớn nhất (LCP) của một trang có thể phức tạp, thường liên quan đến nhiều phần chuyển động và sự đánh đổi. Bài đăng này xem xét dữ liệu thực tế từ các lượt tải trang thực trên web để xác định những khía cạnh mà nhà phát triển nên tập trung vào để tối ưu hoá.

Đối với hầu hết các trang trên web, phần tử LCP là một hình ảnh. Do đó, bạn có thể giả định rằng cách tốt nhất để cải thiện LCP là tối ưu hoá hình ảnh LCP.

Trong khoảng 5 năm kể từ khi LCP được giới thiệu, đó thường là lời khuyên hàng đầu. Đảm bảo hình ảnh có kích thước phù hợp và được nén đủ mức, đồng thời có thể sử dụng định dạng hình ảnh thế kỷ 21 trong khi bạn ở đó. Lighthouse thậm chí còn có 3 bài kiểm tra khác nhau để đưa ra các đề xuất này.

Ba quy trình kiểm tra tối ưu hoá hình ảnh trong báo cáo Lighthouse
Ba quy trình kiểm tra tối ưu hoá hình ảnh trong một báo cáo Lighthouse.

Một phần lý do khiến đây là lời khuyên phổ biến là vì dễ đo lường số byte thừa và dễ đề xuất các công cụ nén hình ảnh. Tuỳ thuộc vào quy trình xây dựng và triển khai, bạn cũng có thể dễ dàng triển khai tính năng này.

Nếu có, hãy làm điều đó! Việc gửi ít byte hơn cho người dùng hầu như luôn là một chiến thắng. Có nhiều trang web trên web vẫn đang phân phát hình ảnh có kích thước lớn không cần thiết mà ngay cả việc nén cơ bản cũng có thể khắc phục.

Tuy nhiên, khi bắt đầu xem xét dữ liệu hiệu suất thực tế của người dùng trong Chrome để biết thời gian LCP thường mất bao lâu, chúng tôi nhận thấy thời gian tải hình ảnh hầu như không bao giờ là nút thắt cổ chai.

Thay vào đó, các phần khác của LCP là vấn đề lớn hơn nhiều.

Bảng chi tiết về các phần phụ của LCP

Để hiểu rõ những cơ hội lớn nhất để cải thiện LCP, chúng tôi đã xem xét dữ liệu từ các phần phụ của LCP, như mô tả trong bài viết Tối ưu hoá LCP.

Mặc dù mỗi trang và mỗi khung có thể sử dụng một phương pháp khác nhau để tải và hiển thị phần tử trở thành phần tử LCP của trang, nhưng mỗi trang đều có thể được chia thành các phần phụ sau:

Thông tin chi tiết về LCP cho thấy 4 phần phụ

Trích dẫn từ bài viết đó, các phần phụ là:

Thời gian cho byte đầu tiên (TTFB)
Thời gian từ khi người dùng bắt đầu tải trang cho đến khi trình duyệt nhận được byte đầu tiên của phản hồi tài liệu HTML.
Độ trễ khi tải tài nguyên
Thời gian giữa TTFB và thời điểm trình duyệt bắt đầu tải tài nguyên LCP. Nếu phần tử LCP không yêu cầu tải tài nguyên để hiển thị, thì thời gian này là 0.
Thời lượng tải tài nguyên
Khoảng thời gian cần thiết để tải chính tài nguyên LCP. Nếu phần tử LCP không yêu cầu tải tài nguyên để hiển thị, thì thời gian này là 0.
Độ trễ khi hiển thị phần tử
Thời gian từ khi tài nguyên LCP tải xong đến khi phần tử LCP hiển thị đầy đủ.

Dữ liệu hiệu suất thực tế của tính năng chỉ đường

Biểu đồ thanh trực quan hoá sự khác biệt về thời gian trong mỗi phần phụ của LCP, được nhóm thành các nhóm LCP là tốt, cần cải thiện và không tốt. TTFB và độ trễ tải tăng nhanh về thời lượng, trong khi thời lượng tải và độ trễ hiển thị vẫn ngắn. Dữ liệu được tái hiện trong bảng dưới đây

Điểm xếp hạng LCP TTFB (mili giây) Độ trễ khi tải hình ảnh (mili giây) Thời lượng tải hình ảnh (mili giây) Độ trễ kết xuất (mili giây)
Tốt 600 350 160 230
Cần cải thiện 1.360 720 270 310
Kém 2.270 1.290 350 360

Trong bài đăng này, chúng tôi đã sử dụng dữ liệu từ các thao tác điều hướng trang có LCP hình ảnh tài nguyên phụ trong Chrome để xem xét các phần phụ của LCP. Chúng tôi đã xem xét loại dữ liệu này trước đây, nhưng chưa bao giờ xem dữ liệu thực địa để biết người dùng thực đang dành thời gian cho việc gì trong khi chờ LCP của trang.

Giống như với Core Web Vitals, chúng tôi đã lấy phân vị thứ 75 (p75) của mỗi phần phụ LCP cho mỗi nguồn gốc trong tập dữ liệu CrUX, dẫn đến 4 phân phối giá trị p75 (mỗi phần phụ có một giá trị). Để tóm tắt các mức phân phối này, chúng tôi đã lấy giá trị trung bình của các giá trị đó trên tất cả các nguồn gốc cho mỗi phần phụ của LCP.

Cuối cùng, chúng tôi chia các nguồn gốc thành các nhóm dựa trên việc chúng có LCP "tốt", "cần cải thiện" hay "kém" ở phân vị thứ 75 hay không. Điều này giúp cho thấy sự khác biệt giữa một nguồn gốc có LCP tốt so với một nguồn gốc có LCP kém.

Giảm kích thước hình ảnh LCP? Lần này có dữ liệu

Thời lượng tải là thước đo thời gian cần thiết để tìm nạp tài nguyên LCP, trong trường hợp này là hình ảnh. Thời gian này thường tỷ lệ với số byte trong hình ảnh, do đó, tất cả các đề xuất về hiệu suất đều nhằm giảm số byte đó.

Khi xem xét thời gian trong các biểu đồ trước, một điều nổi bật là thời gian tải hình ảnh không mất nhiều thời gian. Trên thực tế, đây là phần phụ LCP ngắn nhất trong tất cả các bộ chứa LCP. Thời lượng tải lâu hơn đối với các nguồn có LCP kém so với các nguồn có LCP tốt, nhưng đó vẫn chưa phải là nơi thời gian được chi tiêu nhiều nhất.

Hầu hết các nguồn có LCP kém đều dành chưa đến 10% thời gian LCP p75 để tải hình ảnh LCP xuống.

Có, bạn nên đảm bảo hình ảnh được tối ưu hoá, nhưng đó chỉ là một phần của việc cải thiện LCP. Và rõ ràng là từ dữ liệu này, đối với nguồn gốc thông thường trên web, mức tăng tiềm năng về mili giây cho LCP nói chung là nhỏ, bất kể lược đồ nén phức tạp đến mức nào.

Một điều bất ngờ cuối cùng: thời gian tải chậm từng được cho là do thiết bị di động và chất lượng mạng di động. Trước đây, chúng ta có thể dự kiến một chiếc điện thoại thông thường sẽ mất nhiều thời gian hơn nhiều lần để tải cùng một hình ảnh xuống so với máy tính để bàn khi kết nối có dây. Dữ liệu cho thấy điều này không còn đúng nữa. Đối với các nguồn gốc có LCP kém, thời lượng tải hình ảnh p75 trung bình trên thiết bị di động chỉ chậm hơn 20% so với trên máy tính.

Thời gian cho byte đầu tiên (TTFB)

Đối với các thao tác điều hướng tạo yêu cầu mạng, TTFB sẽ luôn mất một khoảng thời gian. Phải mất một khoảng thời gian để tra cứu DNS và bắt đầu kết nối. Và bạn không thể đánh bại vật lý: một yêu cầu phải đi qua thế giới thực qua dây và cáp quang để đến máy chủ, sau đó phản hồi phải quay lại. Ngay cả nguồn gốc trung bình có LCP tốt cũng mất hơn nửa giây cho TTFB ở phân vị thứ 75.

Tuy nhiên, sự chênh lệch về TTFB giữa nguồn gốc LCP tốt và kém cho thấy cơ hội cải thiện. Đối với ít nhất một nửa số nguồn gốc có LCP kém, chỉ riêng TTFB p75 là 2.270 mili giây gần như đảm bảo rằng LCP p75 không thể nhanh hơn ngưỡng "tốt" là 2,5 giây. Ngay cả khi thời gian đó giảm đi một tỷ lệ phần trăm vừa phải, thì LCP cũng sẽ cải thiện đáng kể.

Bạn có thể không thể đánh bại vật lý, nhưng có một số việc bạn có thể làm. Ví dụ: nếu người dùng thường ở vị trí rất khác với máy chủ của bạn, thì CDN có thể giúp nội dung của bạn đến gần họ hơn.

Để biết thêm thông tin, hãy xem Hướng dẫn tối ưu hoá TTFB.

Độ trễ khi tải tài nguyên, nguyên nhân thường bị bỏ qua gây ra LCP chậm

Nếu có thể cải thiện TTFB nhưng mọi điểm cải thiện đều bị ràng buộc bởi vật lý, thì độ trễ tải tài nguyên có thể bị loại bỏ, trong thực tế chỉ bị ràng buộc bởi cấu trúc phân phát của bạn.

Phần phụ này đo thời gian từ khi byte đầu tiên của phản hồi HTML (TTFB) đến khi trình duyệt bắt đầu yêu cầu hình ảnh LCP. Chúng tôi đã tập trung vào thời gian tải hình ảnh LCP trong nhiều năm, nhưng thường bỏ qua thời gian lãng phí trước khi trình duyệt được yêu cầu bắt đầu tải xuống.

Trang web trung bình có LCP kém mất gần gấp 4 lần thời gian chờ để bắt đầu tải hình ảnh LCP xuống so với thời gian thực sự tải hình ảnh xuống, chờ 1,3 giây giữa TTFB và yêu cầu hình ảnh. Đó là hơn một nửa ngân sách LCP 2,5 giây đã bị mất trong một phần phụ.

Chuỗi phần phụ thuộc là một lý do phổ biến gây ra độ trễ tải lâu. Ở phía đơn giản hơn là một trang tải một trang tính kiểu. Sau khi trình duyệt bố cục, trang tính kiểu này sẽ đặt hình nền sẽ trở thành LCP. Tất cả các bước đó phải diễn ra trước khi trình duyệt biết bắt đầu tải hình ảnh LCP xuống.

Khi sử dụng dữ liệu thu thập thông tin công khai của Kho lưu trữ HTTP (ghi lại chuỗi "trình khởi tạo" của các yêu cầu mạng từ tài liệu HTML đến hình ảnh LCP), bạn có thể thấy mối tương quan rõ ràng giữa độ dài chuỗi yêu cầu với LCP chậm hơn.

Biểu đồ trực quan hoá mối quan hệ của các chuỗi yêu cầu phụ thuộc với LCP. LCP trung bình tăng từ 2.150 mili giây khi không có yêu cầu phụ thuộc, lên 2.540 mili giây khi có 1 yêu cầu phụ thuộc và lên 2.850 mili giây khi có 2 yêu cầu phụ thuộc
Mối quan hệ của các chuỗi yêu cầu phụ thuộc với LCP.

Điều quan trọng là phải cho trình duyệt biết càng sớm càng tốt về LCP để trình duyệt có thể bắt đầu tải, ngay cả trước khi có vị trí cho LCP trong bố cục của trang. Có một số công cụ có thể giúp bạn thực hiện việc này, chẳng hạn như thẻ <img> cổ điển trong HTML để trình quét tải trước có thể nhanh chóng tìm thấy thẻ đó và bắt đầu tải thẻ đó xuống, hoặc thẻ <link rel="preload"> (hoặc tiêu đề HTTP) cho những hình ảnh không phải là <img>.

Điều quan trọng là giúp trình duyệt xác định tài nguyên nào cần ưu tiên. Điều này đặc biệt đúng nếu trang của bạn đang tạo nhiều yêu cầu trong khi tải trang, vì trình duyệt thường sẽ không biết thành phần LCP sẽ là gì cho đến khi nhiều tài nguyên đó đã tải và bố cục đã xuất hiện. Việc chú thích phần tử LCP có thể có bằng thuộc tính fetchpriority="high" (và nhớ tránh loading="lazy") sẽ giúp trình duyệt biết rõ để bắt đầu tải tài nguyên ngay lập tức.

Hãy đọc các lời khuyên khác về cách tối ưu hoá độ trễ tải.

Độ trễ khi kết xuất

Độ trễ kết xuất đo lường thời gian từ khi trình duyệt tải và sẵn sàng hình ảnh LCP, nhưng vì lý do nào đó, hình ảnh này bị trễ trước khi hiển thị trên màn hình. Đôi khi, đây là một tác vụ dài chặn luồng chính khi hình ảnh đã sẵn sàng, trong các trường hợp khác, đây có thể là một lựa chọn trên giao diện người dùng để hiển thị một phần tử ẩn.

Đối với nguồn gốc thông thường trên web, có vẻ như không có cơ hội bị trễ kết xuất lớn, nhưng trong quá trình tối ưu hoá, đôi khi bạn có thể tạo độ trễ kết xuất ngoài thời gian đã dành cho các phần phụ khác. Ví dụ: nếu một trang bắt đầu tải trước hình ảnh LCP để hình ảnh đó có sẵn nhanh chóng, thì sẽ không còn độ trễ tải lâu nữa. Tuy nhiên, nếu chính trang đó chưa sẵn sàng hiển thị hình ảnh (chẳng hạn như từ một trang tính kiểu lớn chặn kết xuất hoặc ứng dụng kết xuất phía máy khách phải hoàn tất việc tải tất cả JavaScript trước khi có thể hiển thị nội dung nào), thì LCP vẫn sẽ chậm hơn mức cần thiết và thời gian chờ hiện sẽ xuất hiện dưới dạng độ trễ kết xuất. Đó là lý do tại sao tính năng kết xuất phía máy chủ hoặc HTML tĩnh thường có lợi thế về LCP.

Nếu nội dung của bạn bị ảnh hưởng, hãy đọc các lời khuyên khác về cách tối ưu hoá độ trễ kết xuất.

Kiểm tra tất cả các phần phụ đó

Rõ ràng là để tối ưu hoá hiệu quả LCP, nhà phát triển cần xem xét toàn diện quá trình tải trang, chứ không chỉ tập trung vào việc tối ưu hoá hình ảnh. Hãy kiểm tra mọi phần của thời gian tải LCP, vì có thể có nhiều cơ hội cải thiện hơn.

Để thu thập dữ liệu này trong trường, bản dựng phân bổ của thư viện web-vitals sẽ bao gồm thời gian cho các phần phụ của LCP. Báo cáo trải nghiệm người dùng trên Chrome (CrUX) chưa bao gồm tất cả dữ liệu này, nhưng có các mục nhập cho TTFB và LCP, vì vậy, đây là một điểm khởi đầu. Chúng tôi hy vọng có thể đưa dữ liệu dùng cho bài đăng này vào CrUX trong tương lai. Hãy chú ý theo dõi để biết thêm tin tức về việc này.

Để kiểm thử các phần phụ của LCP trên máy, hãy thử tiện ích Web Vitals hoặc mảnh JavaScript trong bài viết này. Lighthouse cũng cung cấp thông tin chi tiết trong quy trình kiểm tra "Thành phần Thời gian hiển thị nội dung lớn nhất". Hãy tìm thêm lời khuyên về các phần phụ của LCP trong bảng điều khiển Hiệu suất của Công cụ cho nhà phát triển (sẽ ra mắt trong thời gian sắp tới).