On-Page SEO

Largest Contentful Paint (LCP)

Chỉ số đo thời gian tải phần nội dung lớn nhất trong khung nhìn ban đầu, mục tiêu ≤2.5s.

3 lượt xem Cập nhật: 29/05/2026

Largest Contentful Paint (LCP) là gì?

Largest Contentful Paint (LCP) là chỉ số đo thời gian từ lúc người dùng bắt đầu tải trang cho đến khi phần nội dung lớn nhất trong khung nhìn ban đầu (above-the-fold) được hiển thị đầy đủ. Đây là một trong ba chỉ số Core Web Vitals do Google xác định, phản ánh trải nghiệm tải trang thực tế của người dùng.

Phần nội dung lớn nhất thường là: ảnh (<img>), video (<video>), nền có background-image (nếu được khai báo qua CSS và chiếm diện tích lớn), hoặc khối văn bản (<h1>, <p>, <div>) có kích thước hiển thị lớn nhất — miễn là nó không bị che khuất hoặc chưa render xong.

Mục tiêu đề xuất của Google là LCP ≤ 2.5 giây. Trang đạt dưới 2.5s được đánh giá là tốt, từ 2.5–4.0s là cần cải thiện, và trên 4.0s là kém.

Tại sao quan trọng trong SEO?

LCP là yếu tố xếp hạng trực tiếp trong thuật toán Google từ tháng 6/2021. Trang có LCP chậm hơn 2.5s có thể bị giảm vị trí trên kết quả tìm kiếm — đặc biệt với các truy vấn mang tính cạnh tranh cao và trên thiết bị di động.

Ngoài ra, LCP ảnh hưởng mạnh đến hành vi người dùng: trang tải chậm làm tăng tỷ lệ thoát (bounce rate), giảm thời gian ở lại và giảm khả năng chuyển đổi. Google coi đây là tín hiệu gián tiếp về chất lượng trang — vì vậy dù không phải yếu tố xếp hạng duy nhất, nhưng LCP kém sẽ kéo toàn bộ hiệu suất SEO xuống.

Đáng chú ý: LCP chỉ được tính trên phiên bản đã render của trang — nghĩa là nếu nội dung lớn nhất bị chặn bởi JavaScript hoặc CSS chưa tải xong, trình duyệt sẽ hoãn ghi nhận LCP cho đến khi phần đó sẵn sàng hiển thị.

Cách hoạt động

LCP được tính tự động bởi trình duyệt thông qua API PerformanceObserver. Trình duyệt theo dõi tất cả các phần tử ứng cử viên (candidate elements) xuất hiện trong khung nhìn ban đầu, bao gồm:

  • <img><image> trong <svg>
  • <video> (dùng poster hoặc frame đầu tiên)
  • <div>, <p>, <h1>… có nền hình ảnh qua CSS (background-image) và chiếm ít nhất 25% diện tích viewport
  • Không tính: phần tử ẩn (display: none), phần tử nằm ngoài viewport, phần tử chưa render (chưa có layout), hoặc phần tử bị che bởi lớp overlay

Trình duyệt chọn phần tử có diện tích hiển thị lớn nhất trong suốt quá trình tải — và ghi lại thời điểm nó hoàn tất render (khi pixel cuối cùng được vẽ lên màn hình). Thời điểm này chính là giá trị LCP.

Hướng dẫn thực hiện

Để tối ưu LCP, cần tập trung vào ba nhóm nguyên nhân chính: tốc độ server, truyền tải tài nguyên và render trang. Dưới đây là các bước cụ thể, ưu tiên theo mức độ tác động:

  1. Tối ưu máy chủ và CDN: Dùng hosting có thời gian phản hồi (TTFB) dưới 200ms; bật HTTP/2 hoặc HTTP/3; cấu hình CDN để cache HTML tĩnh và tài nguyên tĩnh.
  2. Tối ưu ảnh: Chuyển sang định dạng hiện đại (WebP/AVIF); nén không mất dữ liệu (công cụ như Squoosh, ShortPixel); áp dụng lazy loading có điều kiện (không lazy cho ảnh LCP); đặt thuộc tính widthheight để tránh layout shift.
  3. Giảm chặn render: Loại bỏ hoặc trì hoãn JavaScript/CSS không cần thiết cho nội dung đầu trang; inline CSS quan trọng (critical CSS); loại bỏ render-blocking scripts bằng defer hoặc async.
  4. Sử dụng preconnect và preload: Thêm <link rel="preconnect" href="https://cdn.example.com"> cho CDN; dùng <link rel="preload" as="image" href="hero.jpg"> cho ảnh LCP.
  5. Kiểm tra và xác minh: Đo LCP bằng Chrome DevTools (tab Performance/Lighthouse), PageSpeed Insights, hoặc Web Vitals Extension. Kiểm tra trên thiết bị di động thật — vì LCP trên mobile thường chậm hơn 2–3 lần so với desktop.

Lỗi thường gặp

Dưới đây là những sai lầm phổ biến khiến LCP bị chậm — kèm cách khắc phục cụ thể:

Lỗi Dấu hiệu Cách khắc phục
Ảnh LCP tải sau khi render LCP > 3s, ảnh xuất hiện muộn dù đã có thẻ <img> Dùng loading="eager", thêm fetchpriority="high", preload ảnh, kiểm tra đường dẫn và kích thước file
TTFB quá cao (>600ms) LCP bắt đầu muộn ngay từ giây đầu tiên Tối ưu database, bật OPcache, dùng object caching (Redis/Memcached), kiểm tra plugin nặng trên CMS
CSS chặn render cho phần hero Text hoặc ảnh LCP bị delay dù file nhỏ Trích xuất critical CSS, inline phần CSS cần thiết cho vùng trên cùng, loại bỏ import CSS không cần thiết
Ảnh nền CSS không được nhận diện Trình duyệt không chọn background làm LCP dù chiếm 50% viewport Chuyển sang dùng thẻ <img> thay vì background-image; hoặc đảm bảo CSS được load sớm và không bị chặn

Ví dụ thực tế

Một trang bán hàng điện máy tại Việt Nam có LCP ban đầu là 5.8s — do ảnh hero (1920x800px, JPG 1.2MB) tải chậm và không có preload. Sau khi áp dụng các bước sau:

  • Chuyển ảnh sang WebP (giảm còn 320KB),
  • Thêm <link rel="preload" as="image" href="/images/hero.webp"> trong <head>,
  • Inline critical CSS cho phần header,
  • Bật Brotli compression và preconnect tới CDN,

→ LCP giảm còn 1.9s trên mạng 4G. Tỷ lệ thoát giảm 22%, thời gian ở lại tăng 37%, và vị trí từ khóa “máy lạnh inverter” cải thiện từ trang 3 lên trang 1 trong 6 tuần.

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

LCP có giống với thời gian tải trang (page load time) không?

Không. Thời gian tải trang (onload) đo đến khi mọi tài nguyên (kể cả script, iframe, analytics) hoàn tất. Còn LCP chỉ đo đến khi phần nội dung lớn nhất trong khung nhìn đầu tiên được render — thường xảy ra sớm hơn nhiều.

Có thể đo LCP trên thiết bị thật không?

Có. Dùng Chrome trên Android với chế độ Developer Tools → Remote Debugging, hoặc công cụ như WebPageTest (chọn device thật như Moto G Power). Lưu ý: LCP trên thiết bị thật có thể khác với lab test do mạng, CPU và cache — nên luôn kiểm tra cả hai môi trường.

Trang tĩnh (HTML thuần) có cần tối ưu LCP không?

Có. Ngay cả trang HTML thuần cũng phụ thuộc vào TTFB, tốc độ mạng, kích thước ảnh và cách trình duyệt xử lý CSS/JS. Nếu ảnh LCP lớn hoặc server chậm, LCP vẫn có thể vượt 4s — đặc biệt trên mạng di động.