Tối ưu LCP cho website (tìm phần tử, đo và sửa từng giai đoạn)

Trong ba chỉ số tối ưu Core Web Vitals mà Google dùng để chấm trải nghiệm tải trang, chỉ số đo “phần tử lớn nhất hiện ra” thường là khó qua nhất nhưng cũng dễ sửa nhất. Lý do là nó phụ thuộc vào một chuỗi sự kiện rõ ràng: máy chủ trả byte đầu, trình duyệt phát hiện tài nguyên, tải về, rồi vẽ ra màn hình. Hiểu đúng chuỗi này thì việc tối ưu trở nên có địa chỉ, không còn mò mẫm.

Ngưỡng “tốt” và cách Google chấm

Google đặt ba mốc cho chỉ số này, đo ở phân vị 75 (p75 — tức 75% lượt tải phải đạt, tách riêng máy tính và điện thoại):

Theo dữ liệu công khai của web.dev, chỉ số này là Core Web Vital khó đạt nhất: chỉ khoảng 59% trang trên di động đạt mức tốt, so với hơn 70% ở hai chỉ số còn lại là INP (đo độ phản hồi tương tác) và CLS (đo độ ổn định bố cục).

Tìm phần tử LCP trên trang của bạn

Trước khi tối ưu, bạn phải biết phần tử nào đang bị tính là “lớn nhất”. Thường là ảnh hero (ảnh banner đầu trang), một khối chữ tiêu đề lớn, hoặc ảnh nền. Cách xem nhanh trong Chrome DevTools:

1. Mở DevTools (F12) → tab Performance.
2. Bấm tải lại trang để ghi lại quá trình tải.
3. Tìm dấu mốc LCP trên dòng thời gian (Timings), rê chuột vào sẽ thấy “node” (phần tử) tương ứng được tô sáng trên trang.

Trong tab Lighthouse hoặc trên PageSpeed Insights, mục “Largest Contentful Paint element” cũng chỉ thẳng phần tử đó. Khi đã biết nó là gì, mọi cải thiện sau này đều nhắm vào đúng tài nguyên ấy, không tốn công tối ưu thứ không liên quan.

Đo bằng lab và field — đừng nhầm hai loại

Có hai nguồn số liệu, đừng lẫn:

• Field (dữ liệu thực): lấy từ CrUX (dữ liệu trải nghiệm người dùng thật của Chrome) — chính là điểm Google dùng để xếp hạng. Xem ở phần “Discover what your real users are experiencing” trên PageSpeed Insights hoặc trong Google Search Console.
• Lab (mô phỏng): Lighthouse chạy thử trong môi trường giả lập. Tiện để gỡ lỗi nhưng số có thể lệch khá nhiều so với người dùng thật, vì cách mô phỏng băng thông khác thực tế. Để đo gần thực hơn, dùng thêm WebPageTest với cấu hình mạng cụ thể.

Nguyên tắc: ưu tiên field để biết mình đang ở đâu so với ngưỡng Google, dùng lab để truy nguyên nguyên nhân.

Bốc tách LCP thành 4 giai đoạn

Đây là phần đắt giá nhất. Theo web.dev, tổng thời gian LCP bằng tổng của bốn giai đoạn nối tiếp, mỗi giai đoạn cần một cách sửa hoàn toàn khác:

Một phát hiện đáng chú ý từ web.dev: ở các trang LCP kém, phần lớn thời gian không nằm ở khâu tải ảnh, mà ở khâu chờ trước khi bắt đầu tải ảnh đó. Tức là trình duyệt phát hiện ảnh hero quá muộn. Đây là chỗ sửa rẻ tiền mà hiệu quả cao.

Bốn đòn tối ưu theo từng giai đoạn

1. Giảm TTFB

TTFB là nền móng — mọi giai đoạn sau đều bắt đầu sau nó. Cache trang ở tầng máy chủ là đòn bẩy mạnh nhất, kế đến là dùng CDN để rút ngắn quãng đường mạng. Web22 vận hành web22.dev trên LiteSpeed kèm LiteSpeed Cache và Cloudflare, nên trang đã được phục vụ dạng tĩnh từ cache thay vì dựng lại mỗi lượt truy cập. Chi tiết kỹ thuật giảm TTFB xem bài đào sâu giảm TTFB; nếu cần định nghĩa cơ bản thì đọc TTFB là gì.

2. Cho trình duyệt phát hiện ảnh LCP sớm (preload)

Nếu ảnh hero được nạp qua CSS hay JavaScript, trình duyệt sẽ phát hiện nó muộn. Khai báo preload kèm fetchpriority="high" để báo trước, đẩy ảnh lên hàng ưu tiên:

<link rel="preload"
      as="image"
      href="/uploads/hero.avif"
      fetchpriority="high">

Hoặc gắn thẳng thuộc tính ưu tiên lên thẻ ảnh trong HTML:

<img src="/uploads/hero.avif"
     fetchpriority="high"
     width="1200" height="630"
     alt="Mô tả ảnh hero">

Việc khai width và height còn giúp tránh layout shift — xem thêm cách dùng aspect-ratio chống dịch chuyển bố cục.

3. KHÔNG bao giờ lazyload ảnh LCP

Đây là lỗi phổ biến nhất. Nhiều plugin tự gắn loading="lazy" cho mọi ảnh, kể cả ảnh hero. Hậu quả: trình duyệt cố tình hoãn tải đúng cái ảnh quan trọng nhất, đẩy LCP lên cao. Quy tắc của web.dev rất dứt khoát — ảnh nằm trong khung nhìn đầu (above the fold) phải tải ngay:

<!-- SAI cho ảnh hero -->
<img src="hero.avif" loading="lazy">

<!-- ĐÚNG -->
<img src="hero.avif" loading="eager" fetchpriority="high">

Chỉ áp lazyload cho ảnh nằm dưới màn hình đầu. Hãy dùng định dạng nhẹ — xem so sánh WebP và AVIF để chọn đúng.

4. Dọn CSS/JS chặn render

Dù ảnh đã tải xong, phần tử vẫn chưa vẽ được nếu trình duyệt còn kẹt xử lý CSS hoặc JavaScript chặn render (render-blocking). Các việc nên làm: tách critical CSS (CSS tối thiểu để vẽ màn hình đầu) và nội tuyến nó, hoãn phần CSS còn lại; gắn defer hoặc async cho script không cần chạy ngay; tự host Google Font kèm font-display: swap để chữ không bị “ẩn chờ font”.

Thứ tự nên làm

1. Tìm phần tử LCP (DevTools / PageSpeed).
2. Bốc tách 4 giai đoạn, xem giai đoạn nào chiếm nhiều thời gian nhất.
3. Bật cache trang + CDN để hạ TTFB.
4. Preload ảnh LCP, bỏ lazyload cho ảnh hero, nén ảnh sang AVIF/WebP.
5. Dọn render-blocking, đo lại bằng field sau vài tuần.

Câu hỏi thường gặp

LCP bao nhiêu là tốt?

Dưới 2,5 giây ở phân vị 75 (p75). Trên 4 giây bị xếp loại kém.

Phần tử LCP luôn là ảnh phải không?

Không. Có thể là khối chữ tiêu đề lớn, ảnh nền, hoặc video poster. Khi không có ảnh đủ lớn, một khối văn bản sẽ được tính là phần tử LCP.

Tối ưu LCP rồi bao lâu mới thấy thay đổi trên Search Console?

Dữ liệu field trong CrUX là trung bình trượt 28 ngày, nên thường cần vài tuần để phản ánh đầy đủ cải thiện.

Nếu trang chủ đang qua ngưỡng 2,5 giây và bạn muốn người khác soi giúp đúng giai đoạn nào nghẽn, Web22 nhận audit hiệu năng website để chỉ ra việc cần sửa theo thứ tự ưu tiên.