Tối ưu LCP: 4 bước cải thiện tốc độ tải website

Đừng vội chỉ nén ảnh hay cắt bớt vài tệp JavaScript. Tối ưu LCP hiệu quả bắt đầu bằng việc xác định chính xác nút thắt nằm ở đâu, sau đó xử lý theo đúng thứ tự ưu tiên.

LCP là gì và vì sao doanh nghiệp cần quan tâm?

LCP là viết tắt của Largest Contentful Paint, một trong ba chỉ số Core Web Vitals. Chỉ số này đo thời gian từ lúc người dùng bắt đầu tải trang đến khi hình ảnh lớn nhất hoặc khối văn bản lớn nhất trong vùng hiển thị hoàn tất việc dựng trên màn hình.

Mục tiêu được khuyến nghị là LCP không quá 2,5 giây ở ít nhất 75% lượt truy cập. Điều này rất quan trọng: website không được đánh giá bằng một lần kiểm tra có kết quả đẹp, mà bằng trải nghiệm của phần lớn người dùng thực tế.

Hãy hình dung bạn có 36 lượt truy cập được xếp từ nhanh đến chậm. Giá trị phần trăm thứ 75 chính là lượt thứ 27. Nếu lượt thứ 27 vẫn vượt quá 2,5 giây, trang chưa đạt mức tốt, dù nhiều lượt truy cập đầu tiên có thể cực kỳ nhanh.

Đây là điểm khiến nhiều đội ngũ tối ưu sai hướng. Nếu bạn chỉ làm các lượt tải vốn đã nhanh nhanh hơn nữa, LCP ở phần trăm thứ 75 có thể không thay đổi. Tương tự, cải thiện nhẹ các lượt tải rất chậm nhưng chưa đủ đưa chúng qua ngưỡng tốt cũng không tạo khác biệt đáng kể.

Muốn điểm LCP tiến bộ, bạn cần cải thiện trải nghiệm cho đủ nhiều người dùng để tối thiểu 75% lượt truy cập nằm trong ngưỡng mục tiêu. Vì vậy, hãy ưu tiên các thay đổi có tác động rộng trên toàn bộ website trước khi xử lý những tình huống quá riêng lẻ.

Đừng coi LCP chỉ là vấn đề hình ảnh

LCP thường là chỉ số khó cải thiện nhất trong Core Web Vitals. Dữ liệu đánh giá hiệu năng cho thấy nhiều website đạt mức tốt với CLS và FID dễ hơn, trong khi LCP vẫn là điểm nghẽn phổ biến.

Nguyên nhân không nằm ở một lỗi đơn lẻ. Hiệu năng tải trang phụ thuộc vào máy chủ, phản hồi HTML, CSS, JavaScript, ảnh, phông chữ, thứ tự tải tài nguyên, bộ nhớ đệm và vị trí mạng. Khi thiếu cách phân tích rõ ràng, bạn có thể bỏ nhiều công sức vào một việc gần như không ảnh hưởng đến kết quả cuối cùng.

Ví dụ, giảm dung lượng ảnh chỉ tác động trực tiếp đến thời gian tải ảnh. Nếu ảnh đã tải xong nhưng giao diện vẫn chờ JavaScript tạo nội dung, hoặc bị stylesheet chặn dựng trang, LCP vẫn không giảm. Thời gian chỉ chuyển từ phần tải tài nguyên sang phần chờ dựng phần tử.

Vì vậy, câu hỏi đúng không phải là “làm sao nén ảnh hơn nữa?”, mà là “thành phần nào đang chiếm phần lớn thời gian LCP của trang?”.

Phân rã LCP thành 4 phần để tìm nút thắt

Với một trang thông thường, bạn chỉ cần tập trung vào hai tài nguyên cốt lõi: tài liệu HTML ban đầu và tài nguyên cần để hiển thị phần tử LCP. Tài nguyên đó có thể là ảnh hero, ảnh sản phẩm, ảnh bài viết hoặc phông chữ web nếu phần tử LCP là văn bản.

Từ đó, LCP có thể được chia thành bốn phần không chồng lấn lên nhau. Tổng thời gian của bốn phần này chính là LCP hoàn chỉnh.

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

Nguyên tắc thực 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 để dựng nội dung lớn nhất, đồng thời giảm tối đa mọi khoảng chờ khác. Một trang được tối ưu tốt thường dành khoảng 80% thời gian cho HTML và tài nguyên LCP, còn các độ trễ phát hiện và dựng nên chiếm phần nhỏ hơn nhiều.

Dữ liệu kiểm thử quy mô lớn cho thấy độ trễ bắt đầu tải tài nguyên thường là một nút thắt lớn hơn dự đoán. Điều đó gợi ý rằng nhiều website chưa giúp trình duyệt phát hiện và ưu tiên đúng tài nguyên LCP đủ sớm.

Tuy nhiên, dữ liệu phòng thí nghiệm không thay thế được dữ liệu người dùng thực tế. Mỗi lượt truy cập ngoài thực tế có thiết bị, mạng, vị trí địa lý và trạng thái bộ nhớ đệm khác nhau. Bạn nên dùng dữ liệu thực tế để quyết định những thay đổi liên quan đến máy chủ, CDN và mạng.

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

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 tải của ảnh LCP với tài nguyên phụ đầu tiên.
   • Nếu stylesheet hoặc phông chữ bắt đầu tải sớm hơn đáng kể so với ảnh LCP, trang đang có độ trễ tải tài nguyên cần xử lý.
   • Mục tiêu là ảnh hoặc tài nguyên LCP nên bắt đầu tải cùng lúc với các tài nguyên quan trọng đầu tiên sau khi HTML được nhận.
2. Không dùng tải lười cho ảnh LCP.
   • Tải lười phù hợp với nội dung nằm ngoài vùng nhìn thấy ban đầu.
   • Đặt tải lười cho ảnh lớn nhất ở đầu trang sẽ tạo ra độ trễ không cần thiết và làm LCP xấu đi.
3. Dùng preload hoặc fetchpriority khi cần.
   • Preload giúp trình duyệt phát hiện ảnh từ HTML mà không cần chờ JavaScript hoặc một yêu cầu API.
   • Thuộc tính fetchpriority mức cao giúp trình duyệt hiểu rằng đây là yêu cầu cần được ưu tiên.

Preload đặc biệt hữu ích khi ảnh LCP chỉ được xác định sau khi JavaScript chạy, chẳng hạn ảnh trong thư viện ảnh sản phẩm hoặc nội dung được lấy từ dữ liệu API. Khi URL ảnh đã có thể biết trước, hãy đưa nó vào HTML để trình duyệt bắt đầu tải càng sớm càng tốt.

1.2 Loại bỏ độ trễ dựng phần tử sau khi tài nguyên tải xong

1. Kiểm tra xem điều gì đang chặn ảnh hoặc văn bản LCP xuất hiện.
   • Nguyên nhân có thể là CSS chặn dựng trang, JavaScript lớn hoặc công cụ thử nghiệm giao diện đang cố tình ẩn nội dung.
   • Nếu tài nguyên đã tải xong mà LCP vẫn muộn, nén ảnh sẽ không giải quyết phần vấn đề này.
2. Giảm khối lượng JavaScript chặn hiển thị.
   • Thu gọn mã và loại bỏ mã không dùng có thể giảm thời gian tải script.
   • Đây là một cải thiện hữu ích, nhưng chưa đủ nếu ứng dụng vẫn phụ thuộc hoàn toàn vào dựng giao diện ở phía trình duyệt.
3. Đưa phần tử quan trọng vào HTML ban đầu.
   • Dựng phía máy chủ hoặc tạo sẵn trang tĩnh giúp HTML đã chứa markup cần thiết khi đến trình duyệt.
   • Khi đó, JavaScript vẫn có thể tải để bổ sung tương tác, nhưng không còn là rào cản để hiển thị phần nội dung lớn nhất.

Đây là khác biệt then chốt giữa việc “giảm thời gian chặn” và “loại bỏ rào cản chặn LCP”. Nếu trình duyệt phải chờ ứng dụng JavaScript tạo ảnh hero, tốc độ tải ảnh có nhanh hơn cũng chưa chắc làm trải nghiệm nhanh hơn.

1.3 Giảm thời gian tải tài nguyên LCP mà không làm giảm chất lượng

1. Phục vụ đúng định dạng và đúng kích thước ảnh.
   • Ảnh JPEG kích thước 1.600 pixel nhưng chỉ hiển thị khoảng 372 pixel là sự lãng phí băng thông đáng kể.
   • AVIF và WebP có thể là lựa chọn hiệu quả hơn, đồng thời JPEG vẫn có thể được giữ làm phương án tương thích.
2. Dùng ảnh đáp ứng theo thiết bị và khả năng trình duyệt.
   • Phần tử picture cho phép khai báo nhiều nguồn ảnh để trình duyệt chọn định dạng và kích thước phù hợp.
   • Không nên tạo quá nhiều biến thể vô tội vạ, vì lợi ích giảm dung lượng cần được cân bằng với hiệu quả bộ nhớ đệm tại CDN.
3. Đồng bộ chiến lược ưu tiên với ảnh thực tế được chọn.
   • Nếu preload một tệp JPEG nhưng phần tử picture cuối cùng lại dùng AVIF, trình duyệt có thể tải cả hai tệp.
   • Trong trường hợp ảnh đáp ứng nhiều định dạng, đặt fetchpriority trực tiếp lên thẻ ảnh thường sạch hơn và tránh tải trùng.

Bên cạnh ảnh, nguyên tắc này cũng áp dụng với phông chữ web. Nếu phần tử LCP là văn bản và phông chữ cần tải trước khi nó có thể được dựng, phông chữ đó trở thành tài nguyên LCP cần được ưu tiên, tối ưu dung lượng và phân phối hiệu quả.

1.4 Cải thiện TTFB sau khi đã xử lý các nút thắt dễ hơn

1. Đưa HTML ban đầu đến gần người dùng hơn.
   • CDN giúp phân phối phản hồi từ vị trí địa lý gần hơn, từ đó giảm thời gian nhận byte đầu tiên.
   • TTFB tốt tạo lợi ích dây chuyền vì trình duyệt không thể phát hiện các tài nguyên tiếp theo trước khi nhận HTML.
2. Thiết lập bộ nhớ đệm phù hợp cho HTML và tài nguyên tĩnh.
   • Bộ nhớ đệm trong trình duyệt cải thiện các lượt truy cập lặp lại của cùng một người dùng.
   • Bộ nhớ đệm trên CDN cải thiện trải nghiệm cho nhiều người dùng trong cùng khu vực khi họ yêu cầu các tài nguyên giống nhau.
3. Ra quyết định máy chủ dựa trên dữ liệu thực tế.
   • Hiệu quả CDN và mạng phụ thuộc vào tỷ lệ trúng bộ nhớ đệm cùng hành vi sử dụng thật.
   • Đừng chỉ dựa vào một mô phỏng trong môi trường kiểm thử để đưa ra thay đổi hạ tầng lớn.

Một ví dụ thực tế: thư viện ảnh tải chậm vì đâu?

Hãy xét một trang có ảnh chính và nhiều ảnh thu nhỏ, mô hình phổ biến ở trang thương mại điện tử, bài viết và landing page. Trang đồng thời tải hai phông chữ web, Bootstrap, JavaScript và lấy danh sách ảnh từ một yêu cầu dữ liệu.

Ban đầu, ảnh LCP chỉ bắt đầu tải sau khi tệp JavaScript chính hoàn tất và yêu cầu dữ liệu ảnh trả về. Đây là độ trễ tải tài nguyên rõ ràng. Thêm preload giúp ảnh được phát hiện sớm hơn, nhưng trình duyệt vẫn có thể gán mức ưu tiên thấp nếu ảnh chưa xuất hiện trong vùng nhìn thấy tại thời điểm đó.

Khi thêm fetchpriority mức cao, ảnh có thể bắt đầu tải cùng lúc với những tài nguyên quan trọng khác. Nhưng trang vẫn chưa nhanh nếu mã JavaScript đợi tất cả ảnh tải xong rồi mới cho toàn bộ thư viện xuất hiện. Cách làm này có thể tạo hiệu ứng đẹp trên mạng nhanh, nhưng gây chờ đợi khó chịu trên mạng chậm.

Giải pháp là để markup ảnh có mặt ngay trong HTML phản hồi từ máy chủ. Khi đó, từng ảnh có thể xuất hiện ngay sau khi tải xong thay vì phải đợi cả nhóm. Bước tiếp theo là thay ảnh quá lớn bằng các phiên bản AVIF, WebP và JPEG có kích thước phù hợp, rồi để trình duyệt chọn tệp tối ưu theo màn hình và khả năng hỗ trợ.

Bài học ở đây rất rõ: một thay đổi đơn lẻ không đảm bảo LCP giảm. Bạn cần đo lại sau từng bước, vì khi một nút thắt được loại bỏ, nút thắt khác có thể trở nên rõ hơn. Chẳng hạn, sau khi ảnh tải rất nhanh, stylesheet có thể trở thành phần mới chặn việc dựng ảnh.

Những sai lầm thường gặp khi tối ưu LCP

• Chỉ tối ưu ảnh: Ảnh nhẹ hơn không giúp nếu JavaScript hoặc CSS vẫn chặn hiển thị.
• Đặt tải lười cho ảnh đầu trang: Điều này trì hoãn chính tài nguyên quan trọng nhất.
• Preload sai phiên bản ảnh: Tải trước JPEG nhưng hiển thị AVIF khiến trang tải trùng tệp.
• Đưa quá nhiều CSS vào HTML: Nhúng CSS có thể hỗ trợ lượt tải đầu, nhưng có thể làm bất lợi cho các lượt truy cập lặp lại.
• Chỉ nhìn dữ liệu phòng thí nghiệm: Các thay đổi về CDN, bộ nhớ đệm và máy chủ cần được xác nhận bằng dữ liệu người dùng thực tế.
• Tối ưu nhóm người dùng vốn đã nhanh: Điểm phần trăm thứ 75 không đổi nếu nhóm người dùng đang gần ngưỡng hoặc vượt ngưỡng vẫn không được cải thiện đủ.

FAQ

LCP bao nhiêu là tốt?

LCP được xem là tốt khi không quá 2,5 giây ở ít nhất 75% lượt truy cập. Bạn nên theo dõi phân phối dữ liệu thay vì chỉ nhìn một kết quả kiểm tra đơn lẻ.

Ảnh LCP có nên dùng tải lười không?

Không nên. Ảnh LCP là nội dung quan trọng trong vùng hiển thị đầu tiên, vì vậy cần được phát hiện và bắt đầu tải sớm nhất có thể.

Khi nào nên dùng preload và fetchpriority?

Preload phù hợp khi trình duyệt khó phát hiện sớm URL tài nguyên LCP, đặc biệt khi ảnh được tạo qua JavaScript. Fetchpriority phù hợp để báo rõ mức ưu tiên cao cho ảnh quan trọng, nhất là khi dùng ảnh đáp ứng với nhiều nguồn.

Tại sao LCP vẫn chậm dù ảnh đã được nén?

Nguyên nhân có thể nằm ở độ trễ phát hiện ảnh, JavaScript dựng giao diện phía trình duyệt, CSS chặn dựng hoặc TTFB cao. Hãy phân tích bốn thành phần của LCP trước khi quyết định tiếp tục giảm dung lượng ảnh.

Nếu website của bạn cần được kiểm tra cấu trúc tải trang, ưu tiên tài nguyên và khả năng dựng nội dung quan trọng, dịch vụ thiết kế website chuẩn hiệu năng của MintStack có thể giúp bạn biến các chỉ số kỹ thuật thành trải nghiệm nhanh hơn cho khách hàng.