Tối ưu LCP: 12 nguyên nhân khiến LCP cao và thứ tự xử lý

Bạn đã đổi ảnh hero sang WebP, bật CDN, xóa bớt plugin rồi kiểm tra lại PageSpeed. Chỉ số LCP vẫn đỏ.

Đây là lúc nên dừng việc tối ưu theo cảm tính.

LCP không chỉ phụ thuộc vào dung lượng hình ảnh. Một trang có thể tải ảnh chỉ trong 300 mili giây nhưng vẫn mất hơn 4 giây mới hiển thị ảnh đó. Thời gian còn lại có thể nằm ở máy chủ phản hồi chậm, trình duyệt phát hiện ảnh quá muộn, JavaScript chiếm luồng xử lý chính hoặc hiệu ứng đầu trang giữ nội dung ở trạng thái ẩn.

Cách tối ưu LCP hiệu quả là tìm đúng giai đoạn đang chậm, xử lý nguyên nhân lớn nhất trước rồi đo lại trong cùng điều kiện.

Có thể hình dung website giống một sân khấu. Ảnh hero hoặc tiêu đề lớn là diễn viên chính. LCP đo xem từ lúc khán giả bước vào đến lúc diễn viên chính xuất hiện mất bao lâu. Diễn viên có thể đã tới nơi, nhưng nếu cửa nhà hát mở chậm, đạo cụ chưa được tìm thấy hoặc tấm rèm vẫn đóng thì khán giả vẫn phải chờ. Tối ưu LCP là tìm đúng lý do khiến tấm rèm chưa mở, không phải chỉ làm cho trang phục của diễn viên nhẹ hơn.

Tóm tắt nhanh: Trả lời nhanh: LCP tốt cần đạt không quá 2,5 giây ở ít nhất 75% lượt truy cập thực tế. Nếu LCP cao, hãy xác định LCP element, chia thời gian thành bốn phần gồm TTFB, thời gian chờ tải tài nguyên, thời gian tải tài nguyên và thời gian chờ hiển thị. Đừng nén ảnh, preload tài nguyên hay hoãn JavaScript hàng loạt khi chưa biết điểm nghẽn nằm ở đâu.

Xem tiêu chuẩn LCP không quá 2,5 giây

LCP cao phải làm sao? Bắt đầu bằng quy trình 7 bước

Nếu chỉ nhớ một phần trong bài này, hãy nhớ quy trình sau:

1. Xác nhận vấn đề bằng dữ liệu người dùng thật.
2. Khoanh vùng mobile, desktop, URL hoặc nhóm trang bị ảnh hưởng.
3. Tái hiện vấn đề trong môi trường kiểm tra có thể lặp lại.
4. Tìm đúng phần tử được trình duyệt xác định là LCP.
5. Chia thời gian LCP thành bốn giai đoạn.
6. Sửa giai đoạn chiếm nhiều thời gian nhất.
7. Đo lại ngay trong phòng kiểm tra và theo dõi dữ liệu thực tế sau khi triển khai.

Thứ tự này giúp đội ngũ tránh một tình huống rất phổ biến: mất nhiều giờ nén ảnh, đổi hosting hoặc cài thêm plugin nhưng chỉ số gần như không thay đổi.

Bước 1: Xác nhận người dùng thật có gặp vấn đề hay không

Mở PageSpeed Insights và kiểm tra phần dữ liệu người dùng thực tế. Nếu URL có đủ dữ liệu, công cụ sẽ cho biết LCP ở percentile 75, nghĩa là mốc mà 75% lượt truy cập đạt bằng hoặc tốt hơn.

Hãy tách mobile và desktop. Một trang có thể đạt LCP tốt trên máy tính nhưng chậm rõ rệt trên điện thoại do mạng yếu hơn, bộ xử lý chậm hơn hoặc tải sai ảnh desktop trên màn hình nhỏ.

Nếu một URL chưa đủ dữ liệu, PageSpeed Insights có thể hiển thị dữ liệu cấp origin. Đừng vội kết luận rằng mọi trang đều có cùng lỗi. Trang chủ, trang dịch vụ, bài blog và trang sản phẩm có thể dùng những cấu trúc hoàn toàn khác nhau.

Bước 2: Khoanh vùng lỗi theo URL và template

Tạo một bảng nhỏ với bốn cột:

URL hoặc template · LCP mobile · LCP desktop · LCP element dự kiến

Trang chủ ·  ·  · Hero image

Trang dịch vụ ·  ·  · H1 hoặc banner

Bài blog ·  ·  · Ảnh đại diện hoặc H1

Landing page ·  ·  · Hero image hoặc video poster

Nếu chỉ trang chủ chậm, hãy tập trung vào hero, slider và script chỉ xuất hiện ở trang chủ. Nếu cả website cùng chậm, cần kiểm tra hạ tầng dùng chung như máy chủ, font, JavaScript toàn cục và hệ thống quản lý thẻ.

Bước 3: Tái hiện vấn đề trong cùng một điều kiện

Một lần chạy Lighthouse chưa đủ để kết luận. Tốc độ mạng, bộ nhớ đệm, vị trí máy chủ và tác vụ nền trên thiết bị đều có thể làm kết quả thay đổi.

Khi so sánh trước và sau, cần giữ nguyên:

• URL.
• Loại thiết bị.
• Kích thước màn hình.
• Cấu hình mạng và CPU.
• Vị trí kiểm tra.
• Trạng thái cold cache hoặc warm cache.

Chạy từ ba đến năm lần và lấy giá trị trung vị. Việc này không thay thế dữ liệu người dùng thật, nhưng giúp đánh giá thay đổi vừa triển khai có tạo ra kết quả nhất quán hay không.

Bước 4: Tìm đúng LCP element

LCP element là phần tử nội dung lớn nhất được hiển thị trong vùng nhìn thấy ban đầu. Nó thường là:

• Ảnh hero.
• Ảnh nền của banner.
• Ảnh poster của video.
• Tiêu đề H1 hoặc một khối văn bản lớn.

Mở Chrome DevTools, chọn Performance, ghi lại quá trình tải trang rồi mở mục Insights. Tại đây, Chrome có thể cho biết phần tử LCP, request liên quan và việc tài nguyên có được phát hiện đủ sớm hay không.

Nếu ảnh hero nhìn rất lớn nhưng DevTools lại xác định H1 là LCP, đừng tiếp tục tối ưu ảnh theo thói quen. Hãy kiểm tra font, CSS và JavaScript đang trì hoãn việc hiển thị tiêu đề.

Bước 5: Chia thời gian LCP thành bốn giai đoạn

Theo hướng dẫn của web.dev, LCP có thể được phân tích thành bốn phần:

1. TTFB: thời gian từ lúc bắt đầu điều hướng đến khi trình duyệt nhận byte đầu tiên của HTML.
2. Resource load delay: HTML đã bắt đầu về nhưng tài nguyên LCP chưa được yêu cầu.
3. Resource load duration: thời gian trình duyệt tải tài nguyên LCP.
4. Element render delay: tài nguyên đã sẵn sàng nhưng phần tử chưa được vẽ lên màn hình.

Hãy tưởng tượng bạn gọi một phần cơm:

• TTFB là thời gian nhân viên mới đến nhận món.
• Resource load delay là thời gian phiếu gọi món nằm trên bàn nhưng chưa được chuyển vào bếp.
• Resource load duration là thời gian đầu bếp nấu món.
• Element render delay là món đã nấu xong nhưng vẫn nằm trong bếp, chưa được mang ra bàn.

Nếu món chỉ mất ba phút để nấu nhưng phiếu gọi món bị để quên mười phút, đổi sang một đầu bếp nhanh hơn không giải quyết được vấn đề. Website cũng vậy.

Nếu LCP là một khối chữ và không cần tải tài nguyên riêng, thời gian sẽ tập trung nhiều hơn ở TTFB và thời gian chờ hiển thị.

Bước 6: Sửa phần chiếm nhiều thời gian nhất

Giả sử LCP hiện là 4,2 giây:

• TTFB: 0,7 giây.
• Chờ phát hiện ảnh: 1,8 giây.
• Tải ảnh: 0,5 giây.
• Chờ hiển thị: 1,2 giây.

Trong trường hợp này, nén ảnh thêm 30% chỉ tác động vào phần 0,5 giây. Cơ hội lớn hơn nằm ở việc giúp trình duyệt phát hiện ảnh sớm và loại bỏ tác vụ đang giữ ảnh chưa được hiển thị.

Nguyên tắc đơn giản là: sửa phần thời gian lớn nhất có bằng chứng, không sửa phần dễ nhìn thấy nhất.

Bước 7: Đo lại và theo dõi dữ liệu sau triển khai

Ngay sau khi sửa, chạy lại bài kiểm tra trong cùng điều kiện để phát hiện lỗi hồi quy. Sau đó theo dõi dữ liệu thực tế theo hai mốc:

• D7: kiểm tra triển khai, hiệu suất trong phòng kiểm tra, giao diện và tracking.
• D28: đánh giá xu hướng dữ liệu người dùng thật vì CrUX dùng cửa sổ dữ liệu luân phiên 28 ngày.

Không nên công bố “đã sửa xong Core Web Vitals” chỉ dựa trên một ảnh Lighthouse màu xanh.

Cách đọc bốn giai đoạn để biết phải sửa gì

TTFB cao: trang chưa kịp bắt đầu

TTFB cao nghĩa là trình duyệt mất nhiều thời gian chờ tài liệu HTML đầu tiên. Khi HTML chưa về, trình duyệt chưa thể biết cần tải CSS, font, JavaScript hay ảnh hero nào.

Dấu hiệu thường gặp:

• Có nhiều lần chuyển hướng trước URL cuối.
• Máy chủ xử lý động quá lâu.
• Cache không hoạt động.
• Máy chủ ở xa phần lớn người dùng.
• HTML có kích thước lớn hoặc chưa được nén.

Resource load delay cao: trình duyệt phát hiện tài nguyên quá muộn

Đây là khoảng thời gian rất dễ bị bỏ qua. Ảnh có thể nhẹ nhưng request bắt đầu quá trễ vì:

• Ảnh nằm trong CSS background.
• JavaScript phải chạy xong mới chèn ảnh.
• Ảnh bị gắn loading="lazy".
• Có quá nhiều request ưu tiên cao cạnh tranh với ảnh chính.
• Carousel chỉ tải slide đầu sau khi thư viện khởi tạo.

Resource load duration cao: tài nguyên thật sự tải chậm

Khi request bắt đầu sớm nhưng kéo dài, hãy kiểm tra:

• Kích thước pixel lớn hơn nhiều so với kích thước hiển thị.
• Tải ảnh desktop trên mobile.
• Dung lượng file cao.
• Định dạng chưa phù hợp.
• Image CDN hoặc cache chưa hoạt động.
• Tài nguyên nằm trên một host có kết nối chậm.

Element render delay cao: tài nguyên đã về nhưng người dùng vẫn chưa thấy

Nguyên nhân thường nằm ở luồng hiển thị:

• CSS chặn render.
• JavaScript đồng bộ hoặc long task.
• Hiệu ứng để hero ở opacity: 0.
• Font chưa tải xong và văn bản bị ẩn.
• Framework đang chờ hydration.
• Slider hoặc công cụ thử nghiệm A/B thay đổi nội dung đầu trang.

12 nguyên nhân khiến LCP cao và cách khắc phục

1. Chuỗi chuyển hướng làm tăng TTFB

Dấu hiệu

Network waterfall hiển thị một hoặc nhiều request 301, 302 hoặc 307 trước khi tải URL cuối.

Cách sửa

• Dùng trực tiếp URL đích trong internal link, sitemap và quảng cáo.
• Thống nhất HTTPS, www hoặc non-www.
• Loại bỏ chuỗi chuyển hướng qua nhiều phiên bản URL.
• Kiểm tra redirect do công cụ theo dõi hoặc rút gọn link tạo ra.

Cách kiểm tra lại

Request tài liệu đầu tiên phải đi thẳng đến URL chuẩn, hoặc chỉ còn một chuyển hướng thật sự cần thiết.

Ví dụ dễ hiểu: Bạn muốn đến nhà bạn A nhưng người thứ nhất đưa địa chỉ nhà B, tới nhà B lại được chỉ sang nhà C, rồi nhà C mới chỉ về nhà A. Mỗi lần vòng qua một địa chỉ là một lần mất thêm thời gian. Redirect chain hoạt động gần giống như vậy.

2. Máy chủ hoặc xử lý backend phản hồi chậm

Dấu hiệu

TTFB chiếm phần lớn LCP ở nhiều template, kể cả khi tài nguyên tĩnh tải nhanh.

Cách sửa

• Bật cache toàn trang nếu nội dung cho phép.
• Giảm truy vấn cơ sở dữ liệu và xử lý động không cần thiết.
• Kiểm tra tình trạng cold start của dịch vụ máy chủ.
• Đưa nội dung tĩnh đến gần người dùng bằng edge cache hoặc CDN phù hợp.
• Theo dõi TTFB theo từng khu vực thay vì chỉ đo tại một máy.

Lưu ý

Đổi hosting chỉ nên được thực hiện sau khi có bằng chứng cho thấy TTFB là điểm nghẽn. Nếu TTFB đã thấp, đổi máy chủ có thể tốn chi phí nhưng không làm LCP giảm đáng kể.

Ví dụ dễ hiểu: Khách đã ngồi vào bàn nhưng nhà bếp mất quá lâu mới nhận đơn. Lúc này vấn đề không nằm ở người bưng món, mà nằm ở khâu chuẩn bị phía sau.

3. HTML truyền về chậm hoặc có quá nhiều tài nguyên bắt đầu cùng lúc

Dấu hiệu

HTML lớn, chưa nén hoặc quá nhiều kết nối đến host bên thứ ba được tạo ngay khi trang bắt đầu tải.

Cách sửa

• Bật Brotli hoặc Gzip cho tài liệu văn bản.
• Giảm mã HTML không cần thiết.
• Chỉ dùng preconnect cho các nguồn thật sự quan trọng.
• Loại bỏ các kết nối bên thứ ba chưa cần trong màn hình đầu tiên.

Ví dụ dễ hiểu: Trước khi bắt đầu bài học, cô giáo phải phát sách cho cả lớp. Nếu sách tới muộn hoặc mỗi học sinh phải chạy sang một phòng khác để lấy sách, tiết học sẽ bắt đầu chậm dù mọi người đều đã ngồi sẵn.

4. Ảnh LCP nằm trong CSS background

Vì sao chậm

Với ảnh trong thẻ <img>, trình quét tải trước của trình duyệt có thể phát hiện URL ngay khi đọc HTML. Với ảnh nền, trình duyệt thường phải tải và phân tích CSS trước khi biết có tài nguyên cần tải.

Cách sửa ưu tiên

Nếu hình ảnh mang nội dung chính, cân nhắc dùng <picture> hoặc <img>:

<picture>

  <source

    media="(max-width: 767px)"

    srcset="/images/hero-mobile.avif"

    type="image/avif">

  <source

    srcset="/images/hero-desktop.avif"

    type="image/avif">

  <img

    src="/images/hero-desktop.webp"

    width="1440"

    height="800"

    alt="Đội ngũ Markdao phân tích hiệu suất website"

    fetchpriority="high">

</picture>

Nếu bắt buộc giữ CSS background, chỉ preload đúng ảnh được hiển thị ở viewport hiện tại. Đừng preload cả ảnh desktop và mobile trên mọi thiết bị.

Ví dụ dễ hiểu: Ảnh trong thẻ <img> giống như món đồ được đặt ngay trên bàn. Ảnh trong CSS background giống món đồ cất trong chiếc hộp nằm ở ngăn kéo thứ hai. Trình duyệt phải mở ngăn kéo và chiếc hộp trước khi biết bên trong có gì.

5. JavaScript chèn LCP element quá muộn

Dấu hiệu

Trong waterfall, request ảnh chỉ xuất hiện sau một file JavaScript hoặc sau khi component được khởi tạo.

Tình huống thường gặp

• Hero slider.
• Nội dung được lấy qua API.
• React hoặc Vue chỉ render phía client.
• Công cụ thử nghiệm A/B thay hero.
• Script cá nhân hóa nội dung.

Cách sửa

• Đặt nội dung quan trọng trong HTML ban đầu.
• Render phía máy chủ hoặc tạo sẵn HTML khi phù hợp.
• Không bắt người dùng chờ thư viện slider chỉ để xem slide đầu.
• Để thử nghiệm A/B thay đổi nội dung sau khi đã bảo đảm phần tử đầu tiên hiển thị ổn định.

Ví dụ dễ hiểu: Sân khấu đã sẵn sàng nhưng người phụ trách bắt cả khán phòng chờ một chiếc máy tự động kéo diễn viên ra. Nếu chiếc máy khởi động chậm, diễn viên cũng xuất hiện chậm dù đang đứng ngay sau rèm.

6. Ảnh LCP bị lazy-load hoặc không được ưu tiên

Lazy loading phù hợp với ảnh bên dưới màn hình đầu tiên. Nó không phù hợp với ảnh mà người dùng cần thấy ngay.

Cấu hình cần tránh

<img src="/images/hero.webp" loading="lazy" alt="...">

Cấu hình phù hợp hơn

<img

  src="/images/hero.webp"

  width="1440"

  height="800"

  loading="eager"

  fetchpriority="high"

  alt="...">

fetchpriority="high" là tín hiệu ưu tiên, không phải lệnh làm mọi ảnh tải nhanh hơn. Chỉ dùng cho một hoặc một số rất ít tài nguyên thật sự quan trọng. Nếu đặt tất cả ảnh ở mức ưu tiên cao, các request sẽ cạnh tranh với nhau và tín hiệu mất ý nghĩa.

Ví dụ dễ hiểu: Trong một hàng người, đánh dấu một người là “ưu tiên” sẽ giúp họ được phục vụ trước. Nếu tất cả đều mang thẻ ưu tiên, hàng đợi lại trở về như cũ.

‍

7. Mobile đang tải ảnh dành cho desktop

Một ảnh rộng 2.400 pixel có thể phù hợp với màn hình lớn nhưng lãng phí trên điện thoại rộng 390 pixel.

Cách sửa

• Cung cấp nhiều kích thước bằng srcset.
• Khai báo sizes đúng với chiều rộng hiển thị thực tế.
• Dùng ảnh cắt riêng cho mobile khi bố cục thay đổi.
• Kiểm tra request thực tế trong Network, không chỉ nhìn mã HTML.

<img

  src="/images/hero-1280.webp"

  srcset="

    /images/hero-640.webp 640w,

    /images/hero-960.webp 960w,

    /images/hero-1280.webp 1280w"

  sizes="100vw"

  width="1280"

  height="720"

  fetchpriority="high"

  alt="Quy trình kiểm tra tốc độ website">

Trong Webflow, cần kiểm tra URL ảnh mà trình duyệt thật sự chọn. Việc Webflow đã tạo responsive images không đồng nghĩa mọi ảnh custom, background hoặc ảnh chèn bằng script đều được xử lý đúng.

Ví dụ dễ hiểu: Đi dã ngoại một buổi nhưng mang theo cả chiếc tủ quần áo sẽ khiến bạn di chuyển nặng nề. Điện thoại tải ảnh desktop quá lớn cũng giống như vậy: nó phải mang nhiều dữ liệu hơn mức màn hình cần dùng.

8. Dung lượng và định dạng ảnh chưa phù hợp

Sau khi chắc chắn ảnh được phát hiện sớm và đúng kích thước, mới tập trung vào dung lượng.

Cách sửa

• Dùng AVIF hoặc WebP khi phù hợp với chất lượng hình ảnh.
• Giảm quality đến mức mắt thường khó nhận ra khác biệt.
• Loại bỏ metadata không cần thiết.
• Tránh dùng PNG cho ảnh chụp thông thường nếu không cần nền trong suốt.
• Đặt ngưỡng kiểm soát riêng cho từng loại ảnh thay vì dùng một con số cho cả website.

Một banner nhiều chi tiết và một hình minh họa phẳng không nên bị ép vào cùng một ngưỡng dung lượng.

Ví dụ dễ hiểu: Gửi một tấm ảnh gia đình chất lượng cao khác với gửi một biểu tượng chỉ có hai màu. Mỗi loại cần cách đóng gói khác nhau. Ép tất cả ảnh về cùng một mức dung lượng có thể làm ảnh quan trọng bị mờ mà tốc độ vẫn chưa được cải thiện đúng chỗ.

‍

9. Image CDN và cache chưa hoạt động đúng

Dấu hiệu

• Ảnh tải từ origin xa người dùng.
• Request lặp lại vẫn tải toàn bộ file.
• Header cache quá ngắn.
• Ảnh biến đổi theo kích thước nhưng không được cache ở edge.

Cách sửa

• Dùng image CDN có khả năng đổi kích thước và định dạng theo request.
• Thiết lập Cache-Control phù hợp cho tài nguyên có tên file phiên bản hóa.
• Kiểm tra thời gian DNS, kết nối, TLS và chờ phản hồi.
• So sánh lần tải đầu với lần tải lại.

Ví dụ dễ hiểu: Mua hàng từ kho gần nhà thường nhanh hơn chờ hàng đi từ một thành phố xa. CDN đặt bản sao hình ảnh gần người dùng để quãng đường vận chuyển dữ liệu ngắn hơn.

10. CSS và JavaScript chặn việc hiển thị

Dấu hiệu

Tài nguyên LCP đã tải xong nhưng vạch LCP xuất hiện muộn. Main thread bận xử lý stylesheet hoặc JavaScript trước khi vẽ phần tử.

Cách sửa

• Giữ CSS cần cho màn hình đầu tiên gọn và có thể tải sớm.
• Trì hoãn JavaScript không cần cho nội dung ban đầu.
• Xóa CSS, JavaScript không sử dụng.
• Chia nhỏ bundle lớn khi có thể.
• Kiểm tra thứ tự tải lại sau mỗi thay đổi.

Không nên sao chép toàn bộ CSS vào HTML dưới tên “Critical CSS”. Một khối CSS nội tuyến quá lớn làm HTML nặng hơn và khó duy trì. Chỉ giữ phần thật sự cần để hiển thị vùng đầu trang.

‍

Ví dụ dễ hiểu: Diễn viên đã đứng trước cửa sân khấu nhưng lối đi bị chặn bởi nhiều thùng đồ. Ảnh đã tải xong nhưng CSS và JavaScript vẫn bận cũng tạo ra tình huống tương tự.

11. Script bên thứ ba chiếm luồng xử lý chính

GTM, live chat, heatmap, trình phát video và công cụ thử nghiệm đều có thể tạo long task trước thời điểm LCP.

Cách kiểm tra

Trong Performance panel, xem các tác vụ dài xuất hiện trước LCP. Mở từng task để xác định script nguồn và thời gian thực thi.

Cách sửa

• Chỉ tải công cụ cần thiết ở lần hiển thị đầu.
• Trì hoãn widget tương tác chưa xuất hiện trong viewport.
• Rà soát tag trùng lặp trong GTM.
• Giảm số lượng công cụ cùng thực hiện một chức năng.
• Kiểm tra tracking sau khi thay đổi.

Mục tiêu không phải tắt toàn bộ công cụ marketing. Mục tiêu là giữ dữ liệu cần thiết mà không bắt người dùng chờ các tính năng chưa cần dùng.

Ví dụ dễ hiểu: Một em nhỏ đang làm bài toán nhưng cùng lúc có năm người đứng cạnh hỏi chuyện. Em vẫn có thể làm xong, nhưng chậm hơn nhiều. Main thread của trình duyệt cũng bị chậm khi quá nhiều script cùng yêu cầu xử lý.

12. Font, animation hoặc slider giữ LCP ở trạng thái ẩn

Dấu hiệu

• Hero đã tải nhưng chỉ hiện sau hiệu ứng fade-in.
• H1 không xuất hiện cho đến khi font tùy chỉnh tải xong.
• Slider cần JavaScript khởi tạo trước khi hiển thị slide đầu.
• Phần tử có opacity: 0, visibility: hidden hoặc transform ban đầu.

Cách sửa

• Cho nội dung quan trọng hiển thị ngay, sau đó mới thêm hiệu ứng nhẹ.
• Dùng font-display phù hợp.
• Chỉ preload font thật sự xuất hiện trong vùng đầu trang.
• Cắt bớt bộ ký tự hoặc số lượng font weight không cần thiết.
• Dùng fallback font có kích thước gần với font chính.
• Tránh carousel nếu một ảnh tĩnh đã truyền tải đủ thông điệp.

Đối với Webflow, hãy kiểm tra Interaction được áp dụng cho hero, H1, wrapper và slider. Một hiệu ứng đẹp nhưng giữ toàn bộ nội dung đầu trang ở trạng thái ẩn trong một giây vẫn làm LCP tăng.

Ví dụ dễ hiểu: Diễn viên đã đứng đúng vị trí nhưng tấm rèm vẫn đóng để chờ hiệu ứng ánh sáng. Khán giả chưa nhìn thấy diễn viên nên đồng hồ LCP vẫn tiếp tục chạy.

‍

Cách giảm Largest Contentful Paint cho hình ảnh mà không preload quá mức

Ảnh thường là LCP element, nhưng không phải mọi ảnh đều cần preload. Trước khi thêm preload, hãy trả lời ba câu hỏi:

1. Ảnh có chắc chắn xuất hiện trong màn hình đầu tiên không?
2. Trình duyệt có thể phát hiện ảnh ngay từ HTML ban đầu không?
3. Ảnh có bị phát hiện muộn vì nằm trong CSS hoặc JavaScript không?

Nếu ảnh đã nằm trong thẻ <img> ở đầu HTML và có fetchpriority="high", preload có thể không tạo thêm lợi ích rõ ràng. Nó còn có thể chiếm băng thông của CSS, font hoặc tài nguyên quan trọng khác.

Khi nên cân nhắc preload

• Ảnh LCP nằm trong CSS background và chưa thể chuyển sang <img>.
• Ảnh chỉ được phát hiện sau khi một stylesheet được tải.
• Cần khai báo chính xác ảnh responsive mà trình duyệt phải ưu tiên.

Khi không nên preload

• Ảnh nằm dưới màn hình đầu tiên.
• Ảnh chỉ xuất hiện sau tương tác.
• Có nhiều phiên bản nhưng chưa thiết lập media query phù hợp.
• Đang preload hàng loạt ảnh, font và script chỉ để tăng điểm Lighthouse.

Khi LCP là H1 hoặc khối văn bản

Nếu DevTools xác định H1 là LCP, hãy kiểm tra đường đi từ HTML đến lần hiển thị đầu tiên của văn bản.

Font có đang chặn chữ không?

Kiểm tra thời điểm font bắt đầu tải, số file font và số lượng weight. Một thiết kế chỉ dùng Regular và Bold không cần tải thêm Light, Medium, SemiBold và ExtraBold ở màn hình đầu tiên.

H1 có bị JavaScript hoặc animation giữ lại không?

H1 nên xuất hiện trong HTML ban đầu. Nếu script chèn nội dung hoặc Interaction đặt H1 ở trạng thái ẩn, thời gian chờ đó sẽ cộng vào LCP.

‍

CSS đầu trang có quá nặng không?

Xác định stylesheet nào bắt buộc để hiển thị H1. Trì hoãn hoặc loại bỏ CSS của component không xuất hiện trong viewport đầu.

Những cách tối ưu LCP dễ làm sai

Chỉ nhìn điểm PageSpeed

Điểm tổng hợp giúp sàng lọc vấn đề, nhưng mục tiêu cuối là trải nghiệm người dùng và dữ liệu Core Web Vitals thực tế. Một lần chạy đạt 100 điểm không đại diện cho mọi thiết bị, mạng và người dùng.

Lazy-load tất cả hình ảnh

Lazy loading giúp giảm tải ảnh bên dưới màn hình đầu tiên. Áp dụng cho ảnh LCP sẽ làm request bắt đầu muộn hơn.

Preload mọi tài nguyên quan trọng theo cảm tính

Preload là một yêu cầu tải sớm. Nếu dùng quá nhiều, trình duyệt phải chia băng thông cho các tài nguyên đang cạnh tranh.

Đặt mọi ảnh thành ưu tiên cao

Priority hint chỉ có giá trị khi nó giúp trình duyệt phân biệt tài nguyên nào thật sự cần trước.

Chỉ nén ảnh mà không xem waterfall

Dung lượng ảnh chỉ ảnh hưởng resource load duration. Nó không giải quyết TTFB, thời gian chờ phát hiện tài nguyên hoặc thời gian chờ render.

Tuyên bố thành công ngay sau khi deploy

Kiểm tra trong phòng thử nghiệm giúp xác nhận thay đổi. Dữ liệu người dùng thật mới cho biết kết quả có bền vững trên nhiều thiết bị và điều kiện mạng hay không.

‍

Case thực tế: bài học từ Nuvemshop

Trong case study được web.dev công bố, đội ngũ Nuvemshop ban đầu nghi ngờ dung lượng hình ảnh và thời gian phản hồi máy chủ. Phân tích sâu hơn cho thấy nhiều vấn đề nằm ở bố cục động, hiệu ứng chuyển cảnh, mức độ ưu tiên và lazy loading.

Sau quá trình tối ưu, tỷ lệ phiên có LCP tốt được báo cáo tăng từ 57% lên 96%. Tỷ lệ URL vượt qua Core Web Vitals tăng từ 48% lên 72%. Chuyển đổi organic từ Google trên mobile tăng 8,9% và mức độ tương tác với giỏ hàng tăng 8,4%.

Đây là kết quả riêng của Nuvemshop, không phải mức tăng mặc định cho mọi website. Bài học có thể áp dụng là: giả định ban đầu thường tập trung vào dung lượng ảnh, trong khi dữ liệu có thể chỉ ra một nguyên nhân khác lớn hơn.

Xem case study Nuvemshop trên web.dev

Mẫu ghi nhận kết quả trước và sau

Mỗi thay đổi cần đi kèm bằng chứng. Markdao có thể dùng bảng sau trong quá trình kiểm tra:

Chỉ số · Trước khi sửa · Sau khi sửa · Điều kiện đo

LCP tổng ·  ·  · Thiết bị, mạng, vị trí

TTFB ·  ·  · Cùng URL

Resource load delay ·  ·  · Cùng viewport

Resource load duration ·  ·  · Cold cache hoặc warm cache

Element render delay ·  ·  · Ngày và công cụ

Field LCP p75 ·  ·  · Khoảng thời gian dữ liệu

Kèm theo bảng là hai ảnh chụp waterfall trước và sau. Trên ảnh cần ghi rõ thiết bị, ngày đo và thay đổi đã triển khai. Nếu không giữ điều kiện tương đương, hai con số rất khó so sánh.

Checklist bàn giao giữa SEO và Webflow Developer

SEO Lead cần chuẩn bị

• Danh sách URL và template bị ảnh hưởng.
• Dữ liệu field trên mobile và desktop.
• Ảnh chụp LCP element.
• Bảng phân rã bốn giai đoạn.
• Giả thuyết nguyên nhân dựa trên bằng chứng.
• Tiêu chí nghiệm thu và lịch theo dõi D7, D28.

Webflow Developer cần thực hiện

• Kiểm tra cấu trúc HTML của hero và H1.
• Rà soát responsive image, background image và slider.
• Loại bỏ lazy loading khỏi ảnh LCP.
• Dùng priority hint hoặc preload có chọn lọc.
• Kiểm tra font, Interaction và script toàn cục.
• Chụp lại waterfall sau khi sửa.
• Kiểm tra giao diện, tracking và form trên mobile.

Điều kiện để xem một lỗi đã được xử lý

• Có bằng chứng xác định nguyên nhân trước khi sửa.
• Có thay đổi cụ thể gắn với nguyên nhân đó.
• Kết quả lab tốt hơn qua nhiều lần chạy.
• Không làm hỏng giao diện hoặc tracking.
• Dữ liệu field được tiếp tục theo dõi.
• Ngày đo và điều kiện đo được ghi lại.

Đăng ký kiểm tra tốc độ website

Tải danh sách kiểm tra LCP của Markdao

Một checklist tốt không chỉ hỏi “ảnh đã nén chưa?” hoặc “website đã bật cache chưa?”. Nó phải dẫn người kiểm tra đi qua toàn bộ hành trình tải trang, từ lúc người dùng nhập URL đến khi phần tử lớn nhất thật sự xuất hiện.

Checklist LCP của Markdao được xây dựng theo bốn giai đoạn và 12 nguyên nhân trong bài này. Mỗi mục có chỗ ghi bằng chứng, người phụ trách, thay đổi đã thực hiện và kết quả trước, sau. Nhờ đó, SEO Lead và Webflow Developer có thể cùng nhìn vào một vấn đề thay vì trao đổi bằng các nhận định chung như “website hơi chậm” hoặc “ảnh có vẻ nặng”.

Tải danh sách kiểm tra LCP để:

• Xác định đúng LCP element.
• Khoanh vùng giai đoạn đang chậm.
• Chọn lỗi cần xử lý trước.
• Lưu ảnh waterfall trước và sau.
• Bàn giao rõ ràng giữa SEO, developer và marketing.
• Theo dõi kết quả D7 và D28.

CTA chính: Tải danh sách kiểm tra LCP

CTA phụ: Đăng ký kiểm tra tốc độ website

Nếu website cần xử lý đồng thời cấu trúc, giao diện và hiệu suất, xem thêm dịch vụ thiết kế và tối ưu website của Markdao.

Kết luận: tối ưu LCP bắt đầu từ chẩn đoán, không bắt đầu từ plugin

LCP cao không phải một lỗi đơn lẻ. Nó là kết quả của toàn bộ quá trình từ lúc người dùng mở trang đến khi nội dung lớn nhất xuất hiện.

Muốn giảm Largest Contentful Paint, hãy đi theo đúng thứ tự:

1. Xác nhận vấn đề bằng dữ liệu thực tế.
2. Tìm đúng LCP element.
3. Chia thời gian thành bốn giai đoạn.
4. Sửa nguyên nhân chiếm nhiều thời gian nhất.
5. Đo lại trong cùng điều kiện.
6. Theo dõi dữ liệu field sau triển khai.

Khi có waterfall, ảnh chụp trước, sau và tiêu chí nghiệm thu rõ ràng, SEO Lead không còn phải yêu cầu chung chung rằng “hãy làm website nhanh hơn”. Developer cũng biết chính xác tài nguyên, đoạn mã hoặc hiệu ứng nào cần xử lý.

Tải danh sách kiểm tra LCP để kiểm tra lần lượt 12 nguyên nhân và chuyển kết quả thành đầu việc cụ thể cho đội ngũ.