Báo cáo Core Web Vitals trong Search Console ghi LCP “Cần cải thiện” hoặc “Kém” nghĩa là khách phải chờ quá lâu mới thấy nội dung chính của trang, thường là ảnh đầu trang hoặc tiêu đề lớn. Bài này chỉ cách tìm đúng phần tử đang bị tính là LCP, xác định thời gian mất ở giai đoạn nào và sửa đúng chỗ trên WordPress, thay vì nén ảnh hàng loạt rồi hy vọng.
LCP (Largest Contentful Paint) là thời gian từ lúc khách mở trang đến lúc phần tử nội dung lớn nhất trong màn hình đầu tiên hiện ra; tốt là từ 2,5 giây trở xuống, kém là trên 4 giây. Thời gian này gồm bốn giai đoạn: máy chủ phản hồi, trình duyệt phát hiện tài nguyên, tải tài nguyên, và vẽ ra màn hình. Trên WordPress, nguyên nhân hay gặp là ảnh đầu trang bị tải lười, ảnh quá nặng, máy chủ chậm không có cache trang, và CSS/JS chặn hiển thị. Cách sửa: xác định phần tử LCP, xem giai đoạn nào dài nhất, rồi xử lý đúng giai đoạn đó.
LCP đo gì và ngưỡng bao nhiêu là đạt?
LCP đo thời điểm phần tử lớn nhất nhìn thấy được trong khung nhìn đầu tiên hoàn tất hiển thị. Phần tử đó thường là ảnh banner, ảnh nền đầu trang, khối video hoặc một đoạn chữ lớn như tiêu đề H1. Theo tài liệu LCP trên web.dev, ngưỡng được tính ở phân vị 75 lượt tải trang, tách riêng điện thoại và máy tính:
| Mức | LCP | Nhãn trong Search Console |
|---|---|---|
| Tốt | ≤ 2,5 giây | Tốt |
| Cần cải thiện | > 2,5 giây đến 4 giây | Cần cải thiện |
| Kém | > 4 giây | Kém |
“Phân vị 75” nghĩa là ít nhất 3 trong 4 lượt truy cập thật phải đạt ngưỡng thì trang mới được tính là tốt. Vì vậy một trang tải nhanh trên máy bàn của bạn vẫn có thể bị ghi “Kém” nếu phần lớn khách dùng điện thoại với mạng chậm. Phần lý thuyết chung về ba chỉ số LCP, INP, CLS có ở bài Core Web Vitals là gì; nếu báo cáo của bạn kêu về phản hồi khi bấm thay vì tốc độ hiện nội dung, hãy xem bài INP cao trên WordPress.
Làm sao biết phần tử nào đang là LCP của trang?
Đừng đoán. Cùng một trang, phần tử LCP trên điện thoại có thể khác trên máy tính (ví dụ ảnh lớn ở máy tính nhưng tiêu đề lớn ở điện thoại), nên cần kiểm tra cả hai.
- Mở Báo cáo Core Web Vitals trong Search Console, chọn Điện thoại, xem các nhóm URL bị LCP kém. URL cùng nhóm có cấu trúc giống nhau nên thường cùng nguyên nhân, ví dụ toàn bộ trang bài viết hoặc toàn bộ trang sản phẩm.
- Chạy PageSpeed Insights cho một URL đại diện. Cuộn đến mục chẩn đoán “Phần tử Largest Contentful Paint” để thấy chính xác ảnh hay khối chữ nào đang được tính.
- Mở Chrome DevTools, bảng Performance, tải lại trang và xem dấu mốc LCP. Bảng này chia thời gian thành các giai đoạn, giúp bạn thấy phần nào dài nhất (xem phần dưới).
- Ghi lại kết quả cho từng nhóm trang: tên phần tử, kích thước ảnh, thời gian từng giai đoạn. Có số trước thì mới biết sửa xong có hiệu quả hay không.
Quy trình đo chi tiết và cách đọc báo cáo có ở bài cách kiểm tra tốc độ website.
Bốn giai đoạn của LCP: thời gian đang mất ở đâu?
Theo hướng dẫn tối ưu LCP của web.dev, thời gian LCP gồm bốn phần nối tiếp nhau. Biết phần nào dài nhất giúp bạn khỏi sửa nhầm chỗ:
| Giai đoạn | Ý nghĩa | Dấu hiệu dài bất thường |
|---|---|---|
| 1. Thời gian máy chủ phản hồi (TTFB) | Từ lúc khách mở trang đến lúc nhận byte HTML đầu tiên | Trang chưa có cache, hosting yếu, nhiều plugin truy vấn nặng |
| 2. Độ trễ tải tài nguyên | Từ khi có HTML đến khi trình duyệt bắt đầu tải ảnh LCP | Ảnh nằm trong CSS nền, nạp bằng JavaScript, hoặc bị gắn tải lười |
| 3. Thời gian tải tài nguyên | Thời gian tải xong tệp ảnh hoặc font | Ảnh dung lượng lớn, sai định dạng, sai kích thước |
| 4. Độ trễ hiển thị phần tử | Từ khi tải xong đến khi vẽ ra màn hình | CSS hoặc JavaScript chặn hiển thị, font chữ chặn vẽ chữ |
Một cách nhớ đơn giản: giai đoạn 1 là lỗi của máy chủ, giai đoạn 2 là lỗi của cách dựng trang, giai đoạn 3 là lỗi của tệp ảnh, giai đoạn 4 là lỗi của mã chặn hiển thị.
Bảng tra: nguyên nhân LCP cao trên WordPress và cách sửa
Sau khi biết giai đoạn nào dài, đối chiếu với bảng dưới. Các dòng được sắp theo mức hay gặp trên website doanh nghiệp làm bằng WordPress:
| Dấu hiệu | Nguyên nhân hay gặp | Cách sửa |
|---|---|---|
| Ảnh đầu trang hiện chậm dù tệp không nặng | Ảnh LCP bị gắn loading="lazy" (tải lười) do plugin tối ưu ảnh hoặc cache |
Loại ảnh đầu trang khỏi tải lười; chỉ tải lười ảnh bên dưới màn hình đầu tiên |
| Ảnh banner dung lượng lớn, vài MB | Tải ảnh gốc từ máy ảnh hoặc ảnh thiết kế chưa nén | Đổi sang WebP hoặc AVIF; đặt kích thước đúng với khung hiển thị; nén vừa đủ |
| Điện thoại tải ảnh to như máy tính | Thiếu thuộc tính srcset/sizes, hoặc ảnh chèn bằng CSS nền |
Dùng ảnh chèn thẻ img có kích thước nhiều bản; tránh đặt ảnh LCP làm nền CSS |
| Trình duyệt chỉ biết đến ảnh LCP rất muộn | Ảnh do slider, JavaScript hoặc page builder nạp sau khi trang dựng xong | Đưa ảnh vào HTML gốc; ưu tiên tải bằng fetchpriority="high" hoặc preload; bỏ slider đầu trang nếu không cần |
| Chờ lâu mới nhận được HTML | Không có cache trang, hosting chậm, plugin truy vấn database nặng | Bật cache trang ở máy chủ hoặc plugin cache; kiểm tra cấu hình hosting và phiên bản PHP |
| Chữ tiêu đề lớn hiện chậm | Font tùy chỉnh tải chậm, chặn vẽ chữ | Dùng font-display: swap; giảm số kiểu chữ; tự lưu font trên máy chủ thay vì tải từ bên ngoài |
| Màn hình trắng vài giây trước khi hiện nội dung | CSS và JavaScript chặn hiển thị: nhiều tệp CSS của plugin, theme nặng | Gộp, rút gọn CSS; hoãn JavaScript không thiết yếu; chỉ nạp CSS của plugin ở trang cần |
| Quá nhiều thứ cạnh tranh băng thông lúc đầu | Pixel quảng cáo, Tag Manager, widget chat, bản đồ nhúng tải cùng lúc với ảnh | Hoãn các script bên thứ ba; thay widget bằng liên kết đơn giản |
Lỗi tải lười ảnh đầu trang: nguyên nhân hay bị bỏ sót
Tải lười (lazy loading) là kỹ thuật chỉ tải ảnh khi khách cuộn gần tới, rất tốt cho ảnh nằm sâu trong bài. Nhưng nếu áp dụng cho chính ảnh LCP ở đầu trang, trình duyệt sẽ chờ thêm rồi mới tải, khiến LCP chậm đi. WordPress có cơ chế tự bỏ tải lười cho ảnh đầu tiên từ phiên bản 6.3, và cũng tự thêm fetchpriority="high" cho ảnh được nhận diện là LCP. Tuy nhiên plugin tối ưu ảnh, plugin cache hoặc page builder có thể ghi đè và gắn lại tải lười cho mọi ảnh.
- Mở mã nguồn trang (Ctrl+U), tìm thẻ
imgcủa ảnh đầu trang và kiểm tra cóloading="lazy"hay không. - Trong cài đặt plugin cache hoặc tối ưu ảnh, tìm tùy chọn tải lười và loại trừ ảnh đầu trang hoặc số ảnh đầu tiên.
- Với ảnh hero do page builder dựng, kiểm tra lại sau khi lưu vì nhiều builder tự thêm tải lười.
Thứ tự xử lý LCP trên website WordPress
Làm từ việc ít rủi ro, tác động rộng tới việc tốn công hơn. Sao lưu và ghi lại số đo trước mỗi bước (cách sao lưu có ở bài backup website định kỳ):
- Xác định phần tử LCP cho từng nhóm trang trên cả điện thoại và máy tính.
- Bỏ tải lười khỏi ảnh LCP và thêm ưu tiên tải. Việc này nhanh và thường có tác động rõ nhất.
- Nén và đổi định dạng ảnh LCP, đặt đúng kích thước khung hiển thị.
- Bật cache trang và kiểm tra thời gian phản hồi máy chủ. Nếu vẫn chậm ngay cả khi có cache, vấn đề nằm ở hosting; xem thêm hosting ảnh hưởng SEO thế nào.
- Giảm CSS, JavaScript chặn hiển thị: gỡ plugin không dùng, chỉ nạp script ở trang cần.
- Xử lý font chữ nếu LCP là khối chữ.
- Cuối cùng mới xét đổi theme hoặc builder nếu các bước trên không đủ; đây là việc lớn, nên làm khi có kế hoạch làm lại giao diện.
Thứ tự rà plugin và cấu hình cache đầy đủ có trong bài cách tăng tốc website WordPress, còn phần máy chủ có ở bài tối ưu hosting. Sau khi sửa, đo lại bằng PageSpeed Insights ngay để thấy thay đổi; dữ liệu thực tế trong Search Console là số cộng dồn 28 ngày nên cần khoảng bốn tuần mới phản ánh đủ. Bạn có thể bấm “Bắt đầu theo dõi” trong báo cáo để Google theo dõi lại nhóm URL đã sửa.
Khi nào LCP kém chưa phải việc cần làm trước?
Google nói rõ đạt Core Web Vitals không bảo đảm xếp hạng cao; nội dung liên quan và hữu ích vẫn quan trọng hơn. Vì vậy có vài trường hợp nên ưu tiên việc khác:
- Website ít truy cập, báo cáo ghi không đủ dữ liệu: con số trong công cụ là ước lượng, đừng đập đi làm lại vì nó.
- Chỉ đuổi điểm 100 trên PageSpeed: điểm mô phỏng khác với trải nghiệm của khách thật; ưu tiên LCP thật trong Search Console.
- Trang chưa có khách tìm đến: nếu bài chưa được Google lập chỉ mục thì tốc độ chưa phải nút thắt. Hãy kiểm tra lập chỉ mục trước.
- Có lượt truy cập nhưng không ai liên hệ: lỗi có thể nằm ở nội dung và nút gọi hơn là tốc độ; xem bài website có lượt truy cập nhưng không ai gọi.
Nếu bạn không có người kỹ thuật để đo từng nhóm trang và thử từng thay đổi, dịch vụ tối ưu website xử lý tốc độ tải trang (hai mức 3 triệu và 7 triệu tùy quy mô website). Với website cần người theo dõi plugin, cache và kiểm tra lại sau mỗi lần thêm tính năng, xem gói bảo trì website WordPress. Bạn có thể gửi link website qua Zalo 0332 942 567 để được xem nhanh phần tử LCP và giai đoạn nào đang chậm.
Câu hỏi thường gặp
LCP bao nhiêu giây là tốt?
Theo Google, LCP từ 2,5 giây trở xuống là tốt, từ trên 2,5 đến 4 giây là cần cải thiện, trên 4 giây là kém. Mức này được tính ở phân vị 75 lượt tải trang thật, tách riêng điện thoại và máy tính.
Vì sao điểm PageSpeed cao mà Search Console vẫn báo LCP kém?
Điểm PageSpeed Insights đến từ bài kiểm tra mô phỏng một lần tải trong điều kiện cố định, còn Search Console dùng dữ liệu người dùng Chrome thật trong 28 ngày, với thiết bị và mạng đa dạng hơn. Khách dùng điện thoại yếu hoặc mạng chậm có thể kéo LCP thật cao hơn kết quả mô phỏng.
Phần tử LCP thường là gì trên website WordPress?
Thường là ảnh banner đầu trang, ảnh bìa bài viết hoặc tiêu đề H1 cỡ lớn. Phần tử này có thể khác nhau giữa điện thoại và máy tính, nên cần kiểm tra cả hai bằng PageSpeed Insights hoặc bảng Performance trong Chrome DevTools.
Có nên tải lười (lazy load) ảnh đầu trang không?
Không. Tải lười phù hợp với ảnh nằm bên dưới màn hình đầu tiên. Nếu áp dụng cho ảnh LCP, trình duyệt sẽ tải ảnh đó muộn hơn và làm LCP chậm đi. Hãy loại ảnh đầu trang khỏi tải lười trong plugin cache hoặc tối ưu ảnh.
Sửa LCP xong bao lâu Search Console cập nhật?
Khoảng bốn tuần. Báo cáo dùng dữ liệu người dùng thật cộng dồn 28 ngày nên số liệu cải thiện dần. Có thể đo ngay bằng PageSpeed Insights để kiểm tra thay đổi, rồi bấm Bắt đầu theo dõi trong báo cáo Core Web Vitals.
Cần người làm giúp phần này?
Mô tả ngắn nhu cầu hoặc gửi link website. Chúng tôi phản hồi bằng đánh giá cụ thể trước khi báo giá.
