Nội dung lớn nhất hiển thị (LCP) của một trang có thể phức tạp để cải thiện, thường liên quan đến nhiều phần di chuyển và sự đánh đổi. Bài đăng này xem xét dữ liệu trường từ lượt tải trang thực tế trên web để xác định nơi nhà phát triển nên tập trung nỗ lực tối ưu hoá.
Lời khuyên về LCP cổ điển: hãy giảm kích thước hình ảnh của bạn!
Đối với hầu hết các trang trên web, phần tử LCP là một hình ảnh. Khi đó, sẽ là bình thường khi cho rằng cách tốt nhất để cải thiện LCP là tối ưu hoá hình ảnh LCP của bạn.
Trong khoảng 5 năm trở lại đây kể từ khi ra mắt LCP, đó thường là nội dung tư vấn tiêu đề. Hãy đảm bảo hình ảnh của bạn có kích thước phù hợp và được nén vừa đủ, đồng thời có thể sử dụng định dạng hình ảnh của thế kỷ 21 khi sử dụng hình ảnh đó. Lighthouse thậm chí còn có 3 chế độ kiểm tra khác nhau để đưa ra những đề xuất này.
Một phần lý do tại sao đây là lời khuyên phổ biến như vậy là dễ dàng đo lường quá nhiều byte và các công cụ nén hình ảnh cũng dễ dàng đề xuất. Tuỳ thuộc vào quy trình xây dựng và triển khai, công cụ này cũng có thể dễ dàng triển khai.
Nếu có, hãy thực hiện ngay! Việc gửi ít byte hơn cho người dùng hầu như luôn mang lại lợi ích. Có nhiều trang web trên web vẫn đang phân phát những hình ảnh lớn không cần thiết mà ngay cả phương thức nén cơ bản cũng có thể khắc phục được.
Tuy nhiên, khi bắt đầu xem xét dữ liệu hiệu suất của trường cho người dùng trong Chrome để biết mức độ dành cho LCP, chúng tôi nhận thấy rằng thời gian tải hình ảnh xuống gần như chưa bao giờ là điểm tắc nghẽn.
Thay vào đó, các phần khác của LCP là một vấn đề lớn hơn nhiều.
Phân tích chi tiết phần phụ LCP
Để hiểu đâu là những lĩnh vực cơ hội lớn nhất giúp 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ư được mô tả trong bài viết Tối ưu hoá LCP.
Mặc dù mỗi trang và mọi khung đều có cách tải và hiển thị những mục sẽ trở thành phần tử LCP của trang theo một cách riêng, nhưng mỗi phần đều có thể được chia thành các phần phụ sau:
Trích dẫn từ bài viết đó, các phần phụ là:
- Thời gian cho byte đầu tiên (TTFB)
- Khoảng thời gian từ khi người dùng bắt đầu tải trang cho đến khi trình duyệt nhận byte đầu tiên của phản hồi tài liệu HTML.
- Độ trễ khi tải tài nguyên
- Khoảng thời gian từ lúc TTFB đến khi 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 để kết xuất, 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 LCP (Nội dung lớn nhất hiển thị)
phần tử không yêu cầu tải tài nguyên để kết xuất, thời gian này là
0. - Độ trễ hiển thị phần tử
- Khoảng thời gian từ khi tài nguyên LCP tải xong cho đến khi phần tử LCP kết xuất đầy đủ.
Dữ liệu thực tế về hiệu suất điều hướng
| Xếp hạng LCP (Nội dung lớn nhất hiển thị) | 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ễ khi hiển thị (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 |
Đối với bài đăng này, chúng tôi sử dụng dữ liệu trong các thao tác điều hướng trang có LCP hình ảnh tài nguyên phụ trong Chrome để xem các phần phụ 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 xét dữ liệu thực địa để biết người dùng thực dành thời gian ở đâu trong khi chờ LCP của trang.
Tương tự 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 từng nguồn gốc trong tập dữ liệu CrUX, dẫn đến việc phân phối 4 giá trị p75 (một giá trị cho mỗi phần phụ). Để tóm tắt những cách 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 từng phần trong số 4 phần phụ LCP.
Cuối cùng, chúng tôi phân chia các nguồn gốc thành các nhóm dựa trên mức độ "tốt", "cần cải thiện" hay "kém" LCP ở phân vị thứ 75. Điều này giúp cho thấy điểm 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 với dữ liệu
Thời lượng tải là thông tin đo lường thời gian cần thiết để tìm nạp tài nguyên LCP, trong trường hợp này là một hình ảnh. Thời gian này thường tỷ lệ thuận với số byte trong hình ảnh, do đó tất cả lời khuyên về hiệu suất nên giảm số byte đó.
Khi xem xét thời gian trong các biểu đồ trước, có một điều nổi bật là không có nhiều thời gian dành cho thời lượng tải hình ảnh. Trên thực tế, đó là phần con LCP ngắn nhất trong tất cả các nhóm LCP. Thời lượng tải dài hơn đối với các nguồn gốc LCP kém so với các nguồn gốc LCP tốt, nhưng đó vẫn không phải là nơi dành phần lớn thời gian.
Phần lớn các nguồn gốc có LCP kém dành ít hơn 10% thời gian LCP p75 của họ để tải hình ảnh LCP xuống.
Có, bạn nên đảm bảo hình ảnh của mình được tối ưu hoá, nhưng đó chỉ là một phần trong việc cải thiện LCP. Dữ liệu này rõ ràng rằng đối với nguồn gốc điển hình trên web, mức tăng tiềm năng tính bằng mili giây của LCP tổng thể là rất nhỏ bất kể phương thức nén có tinh vi đến mức nào.
Một điều bất ngờ cuối cùng: thời lượng tải chậm trước đây thường bị cho là do thiết bị di động và chất lượng của mạng di động. Chúng tôi đã từng dự kiến rằng 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 như một máy tính để bàn khi kết nối có dây. Dữ liệu cho thấy bây giờ không còn đúng nữa. Đối với các nguồn gốc có LCP thấp, 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 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 có yêu cầu mạng, TTFB sẽ luôn mất một khoảng thời gian. Cần 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 thế giới thực. Ngay cả nguồn gốc trung vị có LCP tốt cũng dành hơn nửa giây cho TTFB ở phân vị thứ 75.
Tuy nhiên, sự chênh lệch giữa nguồn gốc LCP tốt và kém của TTFB 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, p75 TTFB 2.270 mili giây một mình gần như đảm bảo rằng LCP p75 không thể nhanh hơn LCP 2,5 giây "tốt" ngưỡng. Ngay cả khi giảm vừa phải tỷ lệ phần trăm trong khoảng thời gian đó cũng có nghĩa là LCP tăng đáng kể.
Có thể bạn sẽ không vượt qua được vật lý, nhưng có những điều có thể làm được. 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 tiếp cận gần hơn với họ.
Để biết thêm thông tin, hãy xem hướng dẫn Tối ưu hoá TTFB.
Độ trễ tải tài nguyên, nguyên nhân LCP chậm bị bỏ qua
Nếu TTFB có thể được cải thiện nhưng bất kỳ cải tiến nào bị ràng buộc bởi vật lý, độ trễ tải tài nguyên có thể được loại bỏ, trên thực tế chỉ bị ràng buộc bởi kiến trúc phân phát của bạn.
Phần phụ này đo thời gian từ khi xuất hiện byte đầu tiên của phản hồi HTML (TTFB) cho đến khi trình duyệt bắt đầu yêu cầu hình ảnh LCP. Trong nhiều năm qua, chúng tôi đã tập trung vào thời gian cần thiết để tải hình ảnh LCP xuống, nhưng chúng tôi 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 dành gần 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, trong đó chờ 1,3 giây giữa thời điểm TTFB và yêu cầu hình ảnh. Nghĩa là hơn một nửa ngân sách LCP 2,5 giây được chia thành 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. Nói một cách đơn giản hơn, đó là một trang tải biểu định kiểu mà sau khi trình duyệt thực hiện bố cục, sẽ đặt mộ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 thậm chí biết bắt đầu tải hình ảnh LCP xuống.
Sử dụng dữ liệu thu thập thông tin công khai của tính năng Lưu trữ HTTP, ghi lại "trình khởi tạo" chuỗi 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.
Điều quan trọng là thông báo cho trình duyệt biết LCP càng sớm càng tốt để trình duyệt có thể bắt đầu tải LCP, ngay cả trước khi có chỗ cho LCP trong bố cục của trang. Bạn có thể sử dụng một số công cụ để 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ẻ này và bắt đầu tải thẻ xuống, hoặc sử dụng 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 thực hiện nhiều yêu cầu trong khi tải trang, vì trình duyệt thường sẽ không biết phần tử LCP là gì cho đến khi nhiều tài nguyên trong số đó đã tải và bố cục đã xảy ra. Việc chú thích phần tử LCP có thể có bằng thuộc tính fetchpriority="high" (và đảm bảo tránh loading="lazy") sẽ giúp trình duyệt hiểu rõ để bắt đầu tải tài nguyên ngay lập tức.
Đọc lời khuyên khác về cách tối ưu hóa độ trễ tải.
Độ trễ khi hiển thị
Độ trễ hiển thị đo lường khoảng thời gian kể từ khi trình duyệt tải và sẵn sàng hình ảnh LCP, nhưng vì lý do nào đó sẽ có độ trễ trước khi hình ảnh 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 một số trường hợp khác, đó có thể là lựa chọn giao diện người dùng để hiển thị phần tử bị ẩn.
Đối với nguồn gốc thông thường trên web, có vẻ như không có cơ hội lớn về độ trễ hiển thị, nhưng trong quá trình tối ưu hoá, đôi khi, bạn có thể tạo độ trễ hiển thị so với thời gian trước đó 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 bị trễ tải lâu nữa. Tuy nhiên, nếu trang đó chưa sẵn sàng hiển thị hình ảnh – chẳng hạn như từ một biểu định kiểu chặn hiển thị lớn hoặc một ứng dụng hiển thị 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ị bất cứ nội dung nào – LCP sẽ vẫn chậm hơn so với bình thường và thời gian chờ đợi hiện sẽ hiển thị dưới dạng độ trễ hiển thị. Đây là lý do khiến tính năng hiển thị phía máy chủ hoặc HTML tĩnh thường có lợi thế hơn so với LCP.
Nếu nội dung của bạn bị ảnh hưởng, hãy đọc thêm lời khuyên về cách tối ưu hoá độ trễ hiển thị.
Hãy kiểm tra tất cả các phần phụ đó
Rõ ràng là để tối ưu hoá LCP một cách hiệu quả, nhà phát triển cần xem xét toàn bộ tải trang, chứ không chỉ tập trung vào việc tối ưu hoá hình ảnh. Kiểm tra từng phần thời gian đối với LCP, vì 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ụ 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ả các dữ liệu này, nhưng có các mục nhập cho TTFB và LCP, vì vậy, hãy bắt đầu. Chúng tôi hy vọng sau này sẽ đưa dữ liệu dùng cho bài đăng này vào CrUX. Vì vậy, hãy chú ý theo dõi để biết thêm tin tức về chủ đề đó.
Để kiểm thử các phần phụ LCP trên máy, hãy thử dùng tiện ích Chỉ số quan trọng đối với trang web hoặc đoạn mã JavaScript trong bài viết này. Lighthouse cũng bao gồm thông tin chi tiết trong "phần tử Thời gian hiển thị nội dung lớn nhất" kiểm tra. Bạn có thể xem thêm lời khuyên về phần phụ LCP trong bảng điều khiển Hiệu suất Công cụ cho nhà phát triển (sắp ra mắt).