LCP: Cách Tìm Đúng Phần Tử Và Giảm Thời Gian Thật

LCP không chỉ là con số nằm trong báo cáo Core Web Vitals. Muốn giảm LCP thật, cần tìm đúng phần tử được trình duyệt chọn làm nội dung lớn nhất trong vùng nhìn thấy, sau đó xác định thời gian bị mất ở giai đoạn nào.

Quy trình hiệu quả gồm bốn phần: TTFB, delay tải tài nguyên, thời gian tải tài nguyên và delay render. Mốc cần hướng tới là LCP không quá 2,5 giây ở phân vị thứ 75; nếu chỉ tối ưu điểm Lighthouse mà bỏ qua dữ liệu người dùng thật, bạn có thể đang sửa sai vấn đề.

LCP là gì và vì sao phải phân rã thành bốn giai đoạn?

LCP, viết tắt của Largest Contentful Paint, đo thời điểm phần tử nội dung lớn nhất trong vùng nhìn thấy được trình duyệt hiển thị hoàn tất. Phần tử này thường là ảnh hero, ảnh sản phẩm, tiêu đề lớn, khối văn bản chính hoặc poster của video.

Theo ngưỡng của Google dành cho Core Web Vitals, LCP được xem là tốt khi không quá 2,5 giây, cần cải thiện khi lớn hơn 2,5 giây đến 4 giây, và kém khi vượt quá 4 giây. Các ngưỡng này nên được đọc ở phân vị thứ 75, tức ít nhất 75% lượt truy cập đạt mốc tương ứng; không nên lấy điểm trung bình để kết luận toàn bộ người dùng có trải nghiệm giống nhau.

Từ thời điểm người dùng điều hướng đến khi LCP xuất hiện, thời gian có thể được tách như sau:

Thời gian LCP = TTFB + delay tải + thời gian tải + delay render

• TTFB: thời gian chờ phản hồi đầu tiên từ máy chủ.
• Delay tải: thời gian trình duyệt chưa bắt đầu tải tài nguyên LCP, thường do phát hiện muộn hoặc bị chặn bởi tài nguyên khác.
• Thời gian tải: thời gian tải dữ liệu của chính tài nguyên LCP, chẳng hạn file ảnh.
• Delay render: thời gian từ khi tài nguyên đã sẵn sàng đến khi phần tử thực sự được vẽ lên màn hình.

Điểm quan trọng là cùng một LCP 4 giây có thể cần cách sửa hoàn toàn khác. Nếu TTFB chiếm 2,5 giây, nén ảnh sẽ gần như không giải quyết được vấn đề. Nếu TTFB chỉ 400 mili giây nhưng delay render kéo dài, tăng máy chủ cũng không tạo ra thay đổi đáng kể.

Bước 1: Xác định đúng phần tử LCP

Trước khi tối ưu, hãy ghi lại URL, loại thiết bị, mẫu trang và phần tử LCP cụ thể. LCP ở trang danh mục có thể là ảnh sản phẩm đầu tiên; ở trang bài viết có thể là tiêu đề hoặc ảnh đại diện; ở trang landing page có thể là một khối tiêu đề nằm trong CSS background.

Trong Chrome DevTools, mở tab Performance, bật ghi nhận tải trang rồi tìm marker LCP trên timeline. Khi chọn marker này, trình duyệt thường hiển thị node tương ứng. Bạn cần kiểm tra cả selector, kích thước hiển thị và URL tài nguyên nếu đó là ảnh.

Trong PageSpeed Insights, phần chẩn đoán LCP thường cho biết phần tử lớn nhất. Với dữ liệu người dùng thật, báo cáo CrUX hoặc công cụ RUM có thể cho thấy LCP khác nhau theo thiết bị, quốc gia, loại kết nối và mẫu trang. Một bài kiểm tra trên máy tính dùng mạng nhanh không đại diện cho người dùng di động dùng 4G yếu.

Hãy kiểm tra ít nhất ba trạng thái:

• Trang mới mở trong cửa sổ ẩn danh, chưa có cache.
• Thiết bị di động mô phỏng với CPU và mạng bị giới hạn.
• Trang đã có cache để phân biệt vấn đề tải lần đầu với vấn đề render.

Không nên mặc định phần tử LCP luôn là ảnh. Một tiêu đề có font lớn, một khối văn bản dài hoặc một phần tử nền CSS cũng có thể được chọn. Cũng không nên đổi kích thước hoặc ẩn phần tử chỉ để trình duyệt chọn một phần tử nhỏ hơn. Cách đó có thể làm chỉ số đẹp hơn nhưng làm trải nghiệm nội dung kém đi, thậm chí tạo ra layout không tự nhiên.

Phân tích bốn giai đoạn của LCP

Giai đoạn 1: Giảm TTFB trước khi đụng vào ảnh

TTFB không phải một mốc cố định riêng cho LCP, nhưng đây là phần đầu tiên cần xem. Nếu máy chủ mất 1.800 mili giây mới trả byte đầu tiên, tổng LCP khó xuống dưới 2,5 giây dù ảnh chỉ mất 200 mili giây để tải và render.

Hãy tách thời gian phản hồi thành các phần: DNS, kết nối, TLS, chờ máy chủ và nhận dữ liệu. Nếu phần chờ máy chủ cao, kiểm tra cache HTML, truy vấn cơ sở dữ liệu, gọi API bên thứ ba và logic tạo nội dung động. Với các trang không cần cá nhân hóa, cache HTML ở biên hoặc tại máy chủ thường có tác động trực tiếp hơn việc tăng số lượng plugin tối ưu giao diện.

Có thể đặt các mốc kiểm tra nội bộ như TTFB dưới 800 mili giây cho trang nội dung phổ biến và dưới 1 giây cho trường hợp có xử lý động phức tạp. Đây là mục tiêu vận hành, không phải ngưỡng chính thức thay thế ngưỡng LCP. Cần đo theo khu vực người dùng thật vì máy chủ phản hồi 300 mili giây ở một quốc gia có thể phản hồi hơn 1 giây ở khu vực khác.

Không nên bật cache toàn trang cho trang tài khoản, giỏ hàng hoặc nội dung phụ thuộc phiên đăng nhập nếu chưa kiểm tra dữ liệu cá nhân. Cũng không nên dùng CDN như giải pháp duy nhất cho TTFB khi nguyên nhân nằm ở truy vấn chậm tại máy chủ gốc.

Giai đoạn 2: Rút ngắn delay tải của phần tử LCP

Delay tải xuất hiện khi trình duyệt biết về phần tử LCP quá muộn. Ví dụ phổ biến là ảnh hero được chèn bằng JavaScript, ảnh nằm trong background-image của CSS, hoặc HTML ban đầu chỉ có khung rỗng rồi mới gọi API để lấy nội dung.

Nếu LCP là ảnh nội dung chính, ưu tiên khai báo trực tiếp trong HTML:

<img
  src="/images/hero-1280.webp"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="Mô tả nội dung ảnh">

fetchpriority="high" có thể giúp trình duyệt ưu tiên tài nguyên quan trọng, nhưng không nên gắn cho mọi ảnh. Chỉ nên dùng cho một tài nguyên LCP được xác định rõ. Nếu trang có năm ảnh đều đặt mức ưu tiên cao, bạn đã làm loãng ưu tiên và có thể khiến các tài nguyên cạnh tranh với nhau.

Preload cũng cần dùng có điều kiện:

<link rel="preload"
  as="image"
  href="/images/hero-1280.webp"
  type="image/webp">

Không preload ảnh chỉ xuất hiện sau khi người dùng cuộn, ảnh của các slide chưa hiển thị hoặc ảnh chỉ xuất hiện trên một breakpoint khác. Preload sai làm tăng cạnh tranh băng thông và có thể khiến CSS, font hoặc tài nguyên thực sự quan trọng bị tải muộn.

Với ảnh nền CSS bắt buộc phải giữ, hãy cân nhắc preload đúng URL hoặc chuyển phần tử chính sang <img> để trình duyệt phát hiện sớm hơn. Với nội dung LCP được tạo từ API, hãy kiểm tra có thể đưa dữ liệu thiết yếu vào HTML phía máy chủ hay không. Không phải mọi ứng dụng đều cần chuyển sang SSR, nhưng việc bắt trình duyệt chờ JavaScript cho tiêu đề và ảnh đầu tiên thường là một điểm nghẽn rõ ràng.

Giai đoạn 3: Giảm thời gian tải tài nguyên LCP

Khi phần tử đã được phát hiện sớm nhưng file ảnh mất quá lâu để tải, vấn đề nằm ở kích thước truyền tải, định dạng hoặc đường phân phối. Trước hết, so sánh kích thước ảnh hiển thị với kích thước file được tải. Ảnh hiển thị rộng 640 pixel nhưng tải bản 3.000 pixel là dấu hiệu cần sửa.

Dùng srcset và sizes để trình duyệt chọn biến thể phù hợp:

<img
  src="hero-1280.webp"
  srcset="hero-640.webp 640w, hero-1280.webp 1280w, hero-1920.webp 1920w"
  sizes="100vw"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="Ảnh minh họa">

Không có một kích thước file tối ưu cho mọi loại ảnh. Ảnh hero cần nhiều chi tiết có thể lớn hơn ảnh minh họa đơn giản, nhưng mục tiêu thực tế là giảm dữ liệu mà không làm ảnh vỡ hoặc mất thông tin quan trọng. Hãy kiểm tra bằng mạng bị giới hạn, không chỉ nhìn dung lượng trên máy tính văn phòng.

AVIF hoặc WebP có thể giảm dung lượng so với JPEG trong nhiều trường hợp, nhưng cần kiểm tra chất lượng, khả năng tương thích và thời gian mã hóa tại hệ thống phân phối. Đừng chuyển toàn bộ kho ảnh sang một định dạng mới chỉ vì phần mở rộng nhỏ hơn; hãy đo kích thước thực tế của nhóm ảnh LCP đại diện.

Ảnh LCP không nên đặt loading="lazy". Lazy loading phù hợp với ảnh nằm dưới vùng nhìn thấy, còn áp dụng cho ảnh đầu trang có thể trì hoãn chính tài nguyên cần xuất hiện sớm. Đây là một trong những lỗi cấu hình thường gặp khi dùng quy tắc tối ưu ảnh tự động.

Giai đoạn 4: Giảm delay render sau khi tài nguyên đã tải

Ở giai đoạn này, tài nguyên LCP có thể đã tải xong nhưng người dùng vẫn chưa thấy nội dung. Nguyên nhân thường là CSS chưa sẵn sàng, font đang chờ, JavaScript bận xử lý hoặc phần tử bị ẩn bằng opacity: 0, visibility: hidden hay logic hiệu ứng.

Kiểm tra waterfall và main thread trong DevTools. Nếu có tác vụ JavaScript kéo dài hơn 50 mili giây, nhiều tác vụ liên tiếp có thể chặn trình duyệt cập nhật giao diện. Hãy trì hoãn script phân tích, widget chat, quảng cáo và tính năng chỉ dùng sau tương tác. Mục tiêu không phải xóa toàn bộ JavaScript, mà là để nội dung đầu tiên không phải chờ những chức năng chưa cần thiết.

CSS dùng cho phần đầu trang nên được tải sớm, còn CSS của các phần dưới màn hình có thể tách hoặc trì hoãn nếu kiến trúc cho phép. Tuy nhiên, không nên inline toàn bộ CSS vào HTML. Một khối CSS lớn làm tăng HTML, giảm khả năng cache và có thể khiến TTFB hoặc thời gian truyền tải tăng lên.

Font cũng cần được kiểm tra. Nếu tiêu đề LCP dùng font web nhưng trình duyệt phải chờ font mới hiển thị, delay render sẽ tăng. Có thể dùng font-display: swap để cho phép hiển thị font thay thế trong lúc tải, nhưng phải kiểm tra nguy cơ thay đổi kích thước chữ và layout shift. Preload font chỉ khi font đó thực sự cần cho màn hình đầu; preload nhiều font là cách tiêu tốn băng thông nhanh chóng.

Cách đọc số liệu và ưu tiên việc cần sửa

Hãy lập bảng cho từng mẫu trang với các cột: URL, thiết bị, LCP element, TTFB, delay tải, thời gian tải, delay render và LCP tổng. Ví dụ, nếu một trang có TTFB 620 mili giây, delay tải 1.100 mili giây, thời gian tải 500 mili giây và delay render 280 mili giây, tổng LCP xấp xỉ 2.500 mili giây. Trường hợp này, sửa cách phát hiện ảnh có khả năng hiệu quả hơn tối ưu thêm 20 KB ảnh.

Nếu tổng LCP là 3.400 mili giây, nhưng TTFB 500 mili giây, delay tải 1.600 mili giây, thời gian tải 900 mili giây và delay render 400 mili giây, cần xử lý theo thứ tự delay tải rồi thời gian tải. Nếu chỉ giảm ảnh từ 900 xuống 700 mili giây, LCP vẫn còn khoảng 3.200 mili giây và chưa đạt mốc 2,5 giây.

Đo lại sau từng thay đổi, giữ nguyên thiết bị và điều kiện mạng khi kiểm thử lab. Với dữ liệu người dùng thật, nên chờ đủ mẫu và so sánh cùng mẫu trang, cùng loại thiết bị, cùng khu vực. Một lần chạy nhanh hơn 300 mili giây không chứng minh bản phát hành đã cải thiện phân vị thứ 75.

Những cách tối ưu LCP không nên làm

• Không ẩn phần tử LCP hoặc thay nội dung chính bằng một khối rỗng chỉ để báo cáo chọn phần tử nhỏ hơn.
• Không lazy-load ảnh hero, tiêu đề hoặc nội dung đầu tiên trong vùng nhìn thấy.
• Không preload hàng loạt ảnh, font và script với hy vọng trình duyệt sẽ tải tất cả nhanh hơn.
• Không chỉ tối ưu Lighthouse rồi kết luận website đã tốt khi dữ liệu người dùng thật vẫn vượt 2,5 giây.
• Không xóa alt, kích thước ảnh hoặc nội dung có ý nghĩa để giảm vài mili giây.
• Không quy mọi vấn đề LCP về máy chủ hoặc CDN khi waterfall cho thấy delay render do JavaScript.

Quy trình đúng là xác định phần tử LCP trước, chia tổng thời gian thành bốn giai đoạn, chọn giai đoạn chiếm nhiều thời gian nhất rồi sửa đúng nguyên nhân. Khi TTFB, delay tải, thời gian tải và delay render đều được đo riêng, việc tối ưu LCP trở thành một bài toán kỹ thuật có thể kiểm chứng, thay vì chuỗi thử nghiệm dựa trên điểm số đơn lẻ.

Đọc thêm

• Dịch vụ geo — triển khai trọn gói, có cam kết đo lường bằng số.
• Bảng báo giá seo — xem phạm vi công việc và mức đầu tư.
• Tuyển Dụng Nhân Sự SEO: Khung Đánh Giá Và Mức Lương Thị Trường
• VPS Cho Website: Khi Nào Cần Nâng Và Cấu Hình Tối Thiểu