Tối ưu LCP: Quy trình 4 bước cải thiện Core Web Vitals

Nếu bạn đang đầu tư SEO, quảng cáo hoặc phát triển website bán hàng, LCP là chỉ số cần được nhìn như một vấn đề vận hành thực tế. Khách truy cập cần thấy nội dung chính của trang sớm, thay vì chờ ảnh banner, sản phẩm nổi bật hoặc tiêu đề lớn xuất hiện sau hàng loạt tài nguyên phụ.

LCP là gì và mức nào được xem là tốt?

LCP, viết tắt của Largest Contentful Paint, đo khoảng thời gian từ lúc một trang bắt đầu tải đến khi hình ảnh hoặc khối văn bản lớn nhất trong vùng nhìn thấy được hiển thị hoàn chỉnh. Trên một trang thương mại điện tử, đó thường là ảnh sản phẩm chính hoặc banner đầu trang. Trên trang giới thiệu dịch vụ, đó có thể là hình ảnh lớn hoặc tiêu đề chính.

Mục tiêu cần hướng đến là LCP không quá 2,5 giây tại phân vị thứ 75 của toàn bộ lượt truy cập. Điều này có nghĩa là ít nhất 75% lượt truy cập thực tế cần có trải nghiệm hiển thị nội dung lớn nhất trong ngưỡng tốt.

Đừng chỉ nhìn vào mức trung bình. Hãy hình dung bạn có 36 lượt tải trang, xếp từ nhanh đến chậm. Giá trị ở vị trí thứ 27 chính là phân vị thứ 75. Nếu giá trị này gần 3 giây, trang vẫn cần cải thiện, dù rất nhiều lượt truy cập đầu tiên đã tải nhanh.

Đây là điểm quan trọng nhất khi lập kế hoạch tối ưu. Nếu bạn chỉ làm các lượt tải nhanh nhanh hơn, điểm LCP phân vị 75 có thể không đổi. Tương tự, nếu bạn chỉ làm nhóm tải rất chậm bớt chậm nhưng vẫn nằm ngoài ngưỡng tốt, kết quả đánh giá cũng có thể không cải thiện.

Muốn dịch chuyển điểm số, bạn cần cải thiện trải nghiệm cho một tập đủ lớn người dùng. Các tối ưu dùng chung cho toàn bộ website thường hiệu quả hơn việc chỉ nhắm vào một nhóm thiết bị hoặc một tình huống hiếm gặp, trừ khi dữ liệu cho thấy có lỗi cụ thể cần xử lý riêng.

Vì sao LCP thường khó tối ưu hơn các chỉ số khác?

LCP là chỉ số mà nhiều website gặp khó khăn nhất trong nhóm Core Web Vitals. Dữ liệu được đề cập cho thấy chỉ 52,7% website đạt ngưỡng LCP tốt, thấp hơn đáng kể so với CLS và FID tại thời điểm khảo sát.

Nguyên nhân là tốc độ tải không phụ thuộc vào riêng dung lượng ảnh. Một trang có thể bị chậm do máy chủ phản hồi lâu, do ảnh chính được phát hiện quá muộn, do JavaScript chặn quá trình hiển thị, do CSS quá lớn, hoặc do cách ứng dụng tạo nội dung trên trình duyệt.

Thay vì tìm một mẹo chung như nén ảnh rồi chờ kết quả, bạn cần tách LCP thành các phần có thể đo lường. Khi biết chính xác thời gian bị tiêu ở đâu, bạn mới tránh được tình trạng tối ưu nhiều nhưng điểm số gần như không thay đổi.

Tách LCP thành bốn phần để tìm đúng điểm nghẽn

Với một trang có phần tử LCP là ảnh, bạn chỉ cần tập trung vào hai tài nguyên quan trọng: tài liệu HTML ban đầu và tài nguyên cần thiết để hiển thị phần tử LCP. Nếu phần tử lớn nhất là văn bản dùng phông chữ web, phông chữ đó cũng có thể là tài nguyên quan trọng cần theo dõi.

Thành phần	Ý nghĩa	Dấu hiệu cần xử lý
TTFB	Thời gian từ lúc bắt đầu tải đến khi trình duyệt nhận byte đầu tiên của HTML	Máy chủ, mạng hoặc CDN phản hồi chậm
Độ trễ tải tài nguyên LCP	Khoảng từ TTFB đến lúc trình duyệt bắt đầu tải ảnh hoặc phông chữ LCP	Tài nguyên được phát hiện muộn hoặc có ưu tiên thấp
Thời gian tải tài nguyên LCP	Thời gian tải chính tệp ảnh, phông chữ hoặc tài nguyên cần thiết	Tệp quá nặng, định dạng chưa tốt, CDN hoặc bộ nhớ đệm chưa phù hợp
Độ trễ hiển thị phần tử	Khoảng từ khi tài nguyên tải xong đến khi phần tử thực sự xuất hiện	JavaScript, CSS hoặc logic giao diện đang chặn hiển thị

Bốn phần này không chồng lấp và cộng lại thành tổng LCP. Mục tiêu hợp lý trên một trang được tối ưu tốt là dành phần lớn thời gian cho các yêu cầu mạng thực sự cần thiết, còn mọi khoảng chờ khác cần được giảm tối đa.

Một nguyên tắc thực hành hữu ích là khoảng 80% tổng thời gian dành cho việc nhận HTML và tải tài nguyên LCP, còn tối đa khoảng 20% dành cho độ trễ phát hiện và độ trễ hiển thị. Nếu hai phần chờ này chiếm đa số, bạn đang có cơ hội cải thiện lớn mà chưa cần thay đổi hạ tầng phức tạp.

Đây cũng là lý do việc tối ưu ảnh có thể không tạo ra kết quả. Nếu bạn làm ảnh tải xong sớm hơn nhưng JavaScript vẫn buộc trang chờ trước khi render, thời gian tiết kiệm ở phần tải ảnh chỉ chuyển sang phần chờ hiển thị. Tổng LCP không thay đổi.

Quy trình 4 bước tối ưu LCP

Hãy triển khai theo đúng thứ tự dưới đây. Hai bước đầu thường dễ tạo tác động lớn hơn vì chúng loại bỏ thời gian chờ không cần thiết, thay vì chỉ giảm vài kilobyte tài nguyên.

1.1 Ưu tiên để tài nguyên LCP bắt đầu tải ngay

1. So sánh thời điểm bắt đầu yêu cầu của ảnh LCP với tài nguyên phụ đầu tiên.
   • Nếu stylesheet, phông chữ hoặc tệp khác bắt đầu tải trước ảnh LCP khá lâu, ảnh chính đang bị phát hiện quá muộn.
   • Trong DevTools, bạn có thể kiểm tra biểu đồ thác nước để xác định thời điểm yêu cầu ảnh chính được khởi tạo.
2. Dùng preload khi ảnh LCP không thể được phát hiện trực tiếp từ HTML.
   • Đặt liên kết tải trước trong phần đầu HTML để trình duyệt biết URL ảnh trước khi JavaScript hoặc yêu cầu API hoàn thành.
   • Thiết lập tài nguyên tải trước là ảnh để trình duyệt xử lý đúng loại tài nguyên.
3. Đặt fetchpriority cao cho ảnh LCP khi phù hợp.
   • Thuộc tính này cho trình duyệt biết ảnh là tài nguyên quan trọng và cần được ưu tiên cao hơn.
   • Đây là lựa chọn đặc biệt hữu ích khi ảnh nằm trong HTML nhưng trình duyệt chưa xem nó là nội dung trong vùng nhìn thấy.
4. Không dùng lazy loading cho ảnh LCP.
   • Lazy loading cố ý trì hoãn ảnh và luôn tạo thêm độ trễ tải tài nguyên.
   • Chỉ nên lazy load ảnh nằm ngoài vùng nhìn thấy ban đầu, không áp dụng cho banner hoặc ảnh sản phẩm chính.

Với ảnh được tạo từ JavaScript sau khi gọi API, preload thường là cách khả thi để trình duyệt bắt đầu tải sớm. Khi ảnh đã có trong HTML, fetchpriority cao có thể là giải pháp gọn hơn và dễ quản lý hơn.

1.2 Loại bỏ mọi thứ đang chặn phần tử LCP hiển thị

1. Kiểm tra độ trễ giữa lúc tài nguyên tải xong và lúc ảnh xuất hiện.
   • Nếu ảnh đã tải xong nhưng vẫn chưa hiển thị, vấn đề không nằm ở dung lượng ảnh.
   • CSS chặn render, JavaScript chặn luồng chính hoặc công cụ thử nghiệm giao diện có thể là nguyên nhân.
2. Giảm tải JavaScript bằng cách rút gọn và loại bỏ mã không dùng.
   • Rút gọn mã và loại bỏ phần mã không được sử dụng giúp giảm thời gian tải script.
   • Tuy nhiên, giảm kích thước script chỉ là cải thiện một phần nếu logic trang vẫn phụ thuộc vào JavaScript để tạo nội dung chính.
3. Đưa nội dung LCP vào HTML phản hồi từ máy chủ.
   • Server-side rendering hoặc tạo trước trang tĩnh giúp trình duyệt nhận sẵn phần đánh dấu của ảnh và nội dung chính.
   • Khi đó, trình duyệt không phải chờ ứng dụng JavaScript tải xong mới biết cần hiển thị phần tử nào.
4. Tránh logic bắt ảnh chính phải chờ toàn bộ thư viện ảnh.
   • Trong một thư viện ảnh, việc đợi mọi ảnh thu nhỏ tải xong rồi mới làm ảnh chính xuất hiện có thể tạo trải nghiệm rất chậm trên mạng yếu.
   • Ảnh chính nên được hiển thị ngay khi sẵn sàng, thay vì bị buộc chờ các tài nguyên ít quan trọng hơn.

Điểm cần nhớ là “giảm thời gian chặn” chưa đủ tốt bằng “không để chặn”. Nếu nội dung lớn nhất của trang vẫn được dựng hoàn toàn ở phía trình duyệt, LCP có thể tiếp tục phụ thuộc vào JavaScript dù ảnh đã tải rất nhanh.

1.3 Giảm thời gian tải tệp LCP mà không giảm chất lượng cần thiết

1. Chọn định dạng ảnh hiện đại và đúng kích thước hiển thị.
   • AVIF hoặc WebP có thể nhẹ hơn JPEG trong nhiều trường hợp, trong khi JPEG vẫn là phương án dự phòng cho khả năng tương thích rộng.
   • Không tải ảnh rộng 1.600 pixel nếu ảnh chỉ hiển thị khoảng 372 pixel, kể cả trên màn hình có mật độ điểm ảnh cao.
2. Cung cấp nhiều phiên bản ảnh bằng phần tử picture.
   • Trình duyệt sẽ tự chọn định dạng và kích thước phù hợp với khả năng hỗ trợ cùng kích thước màn hình.
   • Bạn cần cân bằng giữa việc tạo nhiều biến thể ảnh và hiệu quả bộ nhớ đệm tại các điểm biên CDN.
3. Đồng bộ cách ưu tiên với tệp ảnh thực tế được trình duyệt chọn.
   • Nếu bạn preload JPEG nhưng phần tử picture cuối cùng chọn AVIF, trình duyệt có thể tải cả hai tệp.
   • Trong tình huống này, đặt fetchpriority trực tiếp trên thẻ ảnh giúp trình duyệt ưu tiên đúng phiên bản được chọn.
4. Tối ưu CSS có thể chặn việc render ảnh.
   • Khi ảnh đã rất nhẹ, stylesheet có thể trở thành tài nguyên chặn render mới.
   • Giảm CSS không dùng, cân nhắc Critical CSS và giữ stylesheet nhỏ hơn tài nguyên LCP khi có thể.

Việc nhúng toàn bộ CSS vào HTML có thể giúp lần truy cập đầu nhanh hơn, nhưng có thể làm giảm lợi ích bộ nhớ đệm ở những lần truy cập sau. Vì vậy, giải pháp phù hợp không phải lúc nào cũng là nhúng mọi thứ, mà là giảm phần CSS cần thiết và tránh để nó trở thành nút thắt mới.

1.4 Giảm TTFB để toàn bộ chuỗi tải bắt đầu sớm hơn

1. Đưa máy chủ và nội dung đến gần người dùng bằng CDN.
   • TTFB tốt giúp trình duyệt bắt đầu khám phá HTML và các tài nguyên tiếp theo sớm hơn.
   • Mọi cải thiện ở TTFB sẽ tác động trực tiếp đến tất cả giai đoạn phía sau.
2. Cấu hình bộ nhớ đệm cho HTML và ảnh khi phù hợp.
   • Bộ nhớ đệm ở trình duyệt hỗ trợ lượt truy cập lặp lại của cùng người dùng.
   • Bộ nhớ đệm tại CDN hỗ trợ nhiều người dùng trong cùng khu vực địa lý cùng truy cập các tài nguyên giống nhau.
3. Đánh giá hạ tầng bằng dữ liệu người dùng thực tế.
   • Hiệu quả máy chủ, CDN và mạng phụ thuộc vào vị trí, hành vi truy cập và tỷ lệ trúng bộ nhớ đệm.
   • Dữ liệu mô phỏng trong môi trường thử nghiệm hữu ích để chẩn đoán, nhưng không đủ để kết luận toàn bộ hiệu năng thực tế.

Một ví dụ chẩn đoán LCP trên trang có thư viện ảnh

Một trang mẫu có ảnh chính, nhiều ảnh thu nhỏ, hai phông chữ web và Bootstrap cho thấy một tình huống rất phổ biến. Nội dung văn bản xuất hiện trước, khu vực ảnh để trống trong một lúc, rồi tất cả ảnh cùng hiện lên sau khi hoàn tất tải.

Khi đo trong DevTools, phần lớn thời gian nằm ở độ trễ tải tài nguyên LCP. Biểu đồ thác nước cho thấy phông chữ và stylesheet tải trước, sau đó JavaScript tải xong mới gọi API lấy danh sách ảnh. Ảnh LCP chỉ bắt đầu tải sau khi yêu cầu API hoàn thành.

Bước đầu tiên là đưa URL ảnh vào HTML bằng preload. Ảnh bắt đầu tải sớm hơn, nhưng vẫn có thể đứng sau phông chữ và CSS vì trình duyệt gán ưu tiên thấp. Sau khi thêm fetchpriority cao, ảnh bắt đầu tải đồng thời với những tài nguyên đầu tiên và độ trễ tải giảm rõ rệt.

Tiếp theo, phần tử ảnh được chuyển từ cơ chế dựng phía trình duyệt sang HTML sẵn có. Kết quả là ảnh hiển thị ngay khi tải xong, thay vì chờ toàn bộ ảnh trong thư viện hoàn thành. Độ trễ render vì thế giảm mạnh.

Cuối cùng, ảnh JPEG quá lớn được thay bằng các phiên bản AVIF, WebP và JPEG ở nhiều kích thước. Khi dùng phần tử picture, cần bỏ preload không khớp để tránh tải trùng. Đặt fetchpriority trên thẻ ảnh giúp trình duyệt ưu tiên đúng tệp AVIF hoặc WebP mà nó thực sự chọn.

Những sai lầm khiến tối ưu LCP không mang lại kết quả

• Chỉ nén ảnh mà không đo phần nào đang chậm. Ảnh nhẹ hơn không giúp nếu JavaScript hoặc CSS vẫn chặn render.
• Lazy load ảnh đầu trang. Đây là cách trực tiếp tạo độ trễ cho tài nguyên cần xuất hiện sớm nhất.
• Preload sai tệp ảnh. Preload JPEG trong khi trình duyệt chọn AVIF khiến trang tải dư một tài nguyên.
• Đẩy preload lên đầu HTML để “lách” ưu tiên. Cách này có thể thay đổi thứ tự tải, nhưng không giải quyết đúng vấn đề về mức ưu tiên tài nguyên.
• Chờ mọi ảnh hoặc mọi thành phần phụ sẵn sàng. Nội dung chính cần xuất hiện ngay khi có thể, không nên bị ràng buộc bởi phần giao diện ít quan trọng.
• Ra quyết định hạ tầng chỉ bằng dữ liệu mô phỏng. CDN, máy chủ và bộ nhớ đệm cần được đánh giá thêm qua dữ liệu người dùng thực tế.

FAQ

Ảnh LCP có phải lúc nào cũng là ảnh banner không?

Không. Phần tử LCP là hình ảnh hoặc khối văn bản lớn nhất trong vùng nhìn thấy ban đầu. Tùy bố cục trang, đó có thể là ảnh sản phẩm, ảnh bài viết, tiêu đề lớn hoặc một khối nội dung văn bản.

Có nên preload tất cả ảnh đầu trang không?

Không nên. Bạn chỉ nên ưu tiên tài nguyên thực sự quyết định LCP, vì preload quá nhiều có thể tạo cạnh tranh băng thông với các tài nguyên quan trọng khác. Hãy xác định ảnh hoặc phông chữ cần thiết cho phần tử lớn nhất trước.

Server-side rendering có luôn cần thiết để cải thiện LCP không?

Không phải trong mọi trường hợp. Nhưng nếu phần tử LCP chỉ được tạo sau khi JavaScript tải và chạy xong, server-side rendering hoặc tạo trước trang tĩnh là hướng xử lý mạnh để loại bỏ độ trễ render do JavaScript gây ra.

Nếu website của bạn cần vừa hiển thị nội dung chủ đạo nhanh vừa duy trì nền tảng kỹ thuật dễ mở rộng, đội ngũ [thiết kế website và SEO của MintStack](https://mintstack.vn) có thể hỗ trợ bạn đánh giá và xử lý các điểm nghẽn hiệu năng theo dữ liệu thực tế.