Ảnh chỉ làm LCP chậm khi phần tử LCP của trang là ảnh. Hãy kiểm bằng PageSpeed Insights trước, rồi mới nén. Nếu đúng là ảnh, làm bốn việc theo thứ tự: đúng kích thước hiển thị, nén hoặc đổi WebP, không lazy-load ảnh LCP, đặt fetchpriority="high". Trang chủ netsolutions.vn là ví dụ ngược: PSI báo bớt được 167 KiB ảnh, nhưng phần tử LCP là một đoạn chữ.
Ảnh chỉ là thủ phạm khi phần tử LCP là ảnh
LCP là thời điểm phần tử lớn nhất trong khung nhìn đầu tiên hiện ra. Phần tử đó có thể là ảnh, khối chữ hoặc ảnh nền. Google coi LCP tốt khi không quá 2,5 giây ở phân vị 75 của lượt tải trang.
Cách kiểm nhanh nhất: mở PageSpeed Insights, nhập URL, chọn tab Mobile, rồi mở mục LCP breakdown. Báo cáo ghi rõ phần tử LCP là thẻ nào. Theo web.dev, LCP chia thành bốn phần: thời gian tới byte đầu tiên, độ trễ bắt đầu tải tài nguyên, thời gian tải tài nguyên và độ trễ hiển thị. Chỉ hai phần giữa phụ thuộc vào dung lượng ảnh. Cách đọc từng phần có ở bài cải thiện Core Web Vitals.
Muốn thấy phần tử LCP ngay trên trình duyệt, mở tab Console của DevTools, dán đoạn dưới rồi tải lại trang. Chúng tôi đã chạy thử đoạn này trên trang landing của mình.
new PerformanceObserver((list) => {
const e = list.getEntries().pop();
console.log(Math.round(e.startTime) + ' ms', e.element, e.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });
Trang chủ của chúng tôi cho thấy vì sao phải kiểm trước. PSI chạy ngày 16/10/2026 (Lighthouse 13.5.0, giả lập điện thoại Moto G Power, mạng Slow 4G) cho điểm Performance 26 và LCP 10,2 giây. Mục Improve image delivery báo ước tính bớt được 167 KiB ảnh. Nhưng phần tử LCP lại là thẻ <p>, một đoạn chữ, không phải ảnh. Lần đo ngày 10/10/2026 cũng ra khối chữ, với LCP 6,6 giây trên điện thoại. Hai lần đo cách nhau sáu ngày ra hai số khác nhau, nên chúng tôi chỉ dùng chúng để xác định phần tử, không để so sánh.
Nếu bạn muốn có người đọc báo cáo giúp và chỉ ra phần tử nào kéo LCP, đó là một phần của dịch vụ audit SEO chuyên sâu.
Khi LCP là ảnh, sửa theo bốn bước này
Thứ tự quan trọng, vì bước đầu thường cho kết quả lớn nhất mà không làm ảnh xấu đi. Nhiều người nhảy thẳng sang bước nén hoặc đổi WebP và bỏ qua kích thước.
| Bước | Việc cần làm | Làm ở đâu, bao nhiêu lần | Rủi ro |
|---|---|---|---|
| 1. Đúng kích thước hiển thị | Dùng ảnh có chiều rộng gần với chiều rộng hiển thị, hoặc khai báo srcset | Từng ảnh LCP; WordPress tự tạo nhiều cỡ khi tải lên | Cắt quá tay thì ảnh mờ trên màn hình có mật độ điểm ảnh cao |
| 2. Nén | Giảm chất lượng một chút, bỏ siêu dữ liệu thừa | Một lần cho cả thư viện, rồi tự động cho ảnh mới | Nén quá tay làm vỡ khối ở vùng chuyển màu |
| 3. Đổi WebP | Chuyển JPEG/PNG sang WebP, giữ bản gốc | Một lần cho thư viện cũ, tự động cho ảnh mới | Máy chủ không hỗ trợ WebP thì lỗi khi tải lên |
| 4. Tải ưu tiên | Bỏ lazy-load ở ảnh LCP, đặt fetchpriority=”high” | Một lần ở theme hoặc block | Đặt cho nhiều ảnh thì ưu tiên mất tác dụng |
Thứ tự do Net Solutions đề xuất, dựa trên tài liệu web.dev và make.wordpress.org đã dẫn trong bài.
Ví dụ có thật ngay trong số đo của chúng tôi. Ảnh ai-agent-luong-hero-v2.webp trên trang chủ nặng 119,0 KiB và có kích thước 900×1200. Trên điện thoại, trang chỉ hiển thị nó ở 340×453. PSI ước tính bớt được 102,0 KiB, tức 85,7% dung lượng ảnh. Ảnh này đã là WebP. Cái thừa là kích thước, không phải định dạng.
Vì vậy, đổi sang WebP mà không đổi kích thước chỉ giải quyết một nửa vấn đề. Tuy nhiên, ảnh này nằm dưới khung nhìn đầu và đang lazy-load, nên nó là bài toán dung lượng tải trang, chưa phải bài toán LCP.
Nén và đổi WebP: WordPress từ 5.8 đã tải được WebP
Từ bản 5.8, WordPress cho phép tải ảnh WebP lên thư viện. Điều kiện nằm ở máy chủ: cần Imagick hoặc GD có hỗ trợ WebP. Nếu máy chủ không hỗ trợ, WordPress báo lỗi khi bạn tải ảnh lên.
WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.
— Google for Developers, WebP, 16/10/2026
Con số của Google là mức trung bình, không phải lời hứa cho từng ảnh. Có ba cách đưa ảnh sang WebP, từ ít việc nhất đến nhiều việc nhất:
- Plugin tự đổi khi tải lên. Chức năng cần có: chuyển ảnh mới sang WebP lúc tải lên và giữ lại bản gốc.
- Đổi cả thư viện cũ theo lô. Cùng loại plugin, chạy một lần trên ảnh đã có.
- Đổi tay trước khi tải lên. Hợp với vài ảnh LCP quan trọng, nơi bạn muốn tự soi chất lượng.
wp-content/uploads và cơ sở dữ liệu trước khi đổi theo lô. Đổi hàng loạt khó quay lại nếu bản gốc bị xoá.Về chất lượng, hãy xuất vài mức nén của cùng một ảnh, mở ở 100% và chọn mức thấp nhất mà mắt bạn không thấy khác. Logo và ảnh PNG nền trong suốt dùng WebP lossless; Google ghi lossless nhỏ hơn PNG 26%. Về trình duyệt, caniuse ghi nhận khoảng 97% người dùng toàn cầu mở được WebP (kiểm ngày 16/10/2026), và Safari hỗ trợ đầy đủ từ bản 16.0. Nếu cần phục vụ cả trình duyệt cũ, dùng thẻ <picture> với bản JPEG dự phòng:
<picture>
<source srcset="hero-900.webp" type="image/webp">
<img src="hero-900.jpg" width="900" height="600" alt="Mô tả cảnh trong ảnh" fetchpriority="high">
</picture>
Để thấy mức tiết kiệm, lấy một ví dụ giả định: ảnh hero JPEG nặng 500 KB. Với mức giảm 25–34% của Google, bản WebP nặng khoảng 330–375 KB. Lighthouse mô phỏng điện thoại với băng thông 1,6 Mbps và độ trễ 150 ms. Chỉ tính thời gian truyền, ảnh 500 KB mất 2,50 giây, còn 1,65–1,88 giây ở dạng WebP. Mức bớt là 0,62 đến 0,85 giây.
| Ảnh hero giả định | Dung lượng | Thời gian truyền ở 1,6 Mbps |
|---|---|---|
| JPEG gốc | 500 KB | 2,50 giây |
| WebP lossy, giảm 25% | 375 KB | 1,875 giây |
| WebP lossy, giảm 34% | 330 KB | 1,65 giây |
Tính theo công thức KB × 8 ÷ 1.600 (1 KB = 1.000 byte). Nguồn: mức giảm của Google for Developers và thông số mạng của tài liệu Lighthouse, kiểm ngày 16/10/2026. Ví dụ giả định, chưa phải số đo của một trang thật.
Đây chỉ là thời gian truyền. LCP còn gồm độ trễ máy chủ, độ trễ bắt đầu tải và độ trễ hiển thị, nên mức bớt thực tế trên LCP sẽ khác. Chúng tôi không có số đo riêng cho mức cải thiện LCP khi đổi WebP và không đưa ra con số đó.
Đừng lazy-load ảnh LCP
Lazy-load hoãn việc tải ảnh cho tới khi ảnh gần vào khung nhìn. Với ảnh nằm ngay đầu trang, việc hoãn đó làm LCP chậm đi. Tài liệu của Google nói thẳng điều này.

Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.
— web.dev, Browser-level image lazy-loading, 16/10/2026
WordPress đã tự xử lý một phần. Bản 5.9 bỏ lazy-load cho ảnh nội dung đầu tiên trên trang. Bản 6.3 tự thêm fetchpriority="high" cho một ảnh đủ điều kiện, với ngưỡng mặc định 50.000 điểm ảnh vuông. Nhưng ảnh trong page builder, slider hoặc ảnh nền của theme thường nằm ngoài cơ chế này. Với các ảnh đó, bạn phải tự kiểm HTML.
Chúng tôi làm thế này cho bài viết trên netsolutions.vn, đã kiểm trên HTML của hai bài ngày 16/10/2026. Ảnh đại diện có loading="eager", fetchpriority="high" và khai báo sẵn chiều rộng, chiều cao. Ảnh thân bài có loading="lazy" và cũng khai báo kích thước.
<!-- Ảnh LCP: không lazy, tải ưu tiên, có kích thước -->
<img src="anh-dai-dien.webp" width="800" height="667" alt="Mô tả" loading="eager" fetchpriority="high">
<!-- Ảnh dưới khung nhìn đầu: lazy -->
<img src="anh-than-bai.webp" width="800" height="525" alt="Mô tả" loading="lazy">
Số đo ảnh trên bốn trang netsolutions.vn
Chúng tôi viết mã đếm thẻ <img> trong HTML và gửi yêu cầu HEAD để lấy Content-Length của từng ảnh. Ngày 16/10/2026, kết quả như sau. Ảnh trùng URL chỉ tính một lần.
| Trang | Số ảnh | Tổng dung lượng | Ảnh WebP | Ảnh nặng nhất |
|---|---|---|---|---|
| Trang chủ | 53 | 1.592,3 KB | 48/53 | 119,0 KB · WEBP |
| Bài “Website chậm ảnh hưởng SEO” | 9 | 189,1 KB | 7/9 | 49,3 KB · PNG |
| Bài “Schema Markup trên WordPress” | 10 | 195,3 KB | 8/10 | 49,3 KB · PNG |
| Trang landing page chạy quảng cáo | 6 | 82,1 KB | 4/6 | 49,3 KB · PNG |
Nguồn: mã đo của Net Solutions, HEAD lấy Content-Length, 1 KB = 1.024 byte, đo ngày 16/10/2026.
Trang chủ nặng nhất vì có nhiều ảnh dịch vụ và ảnh minh hoạ, nhưng 48/53 ảnh đã là WebP. Phần chưa phải WebP gồm 3 ảnh JPEG (188,9 KB) và 2 ảnh PNG (52,7 KB). Nếu WebP giảm 25–34% so với JPEG, ba ảnh đó bớt được khoảng 47–64 KB trên tổng 1.592 KB.
Có một điều chúng tôi chưa sửa. Tệp logoSaleNoti-555x210.png nặng 49,3 KB, định dạng PNG, xuất hiện trên cả bốn trang. Nếu đổi sang WebP lossless và đạt mức giảm 26% của Google, nó bớt được khoảng 12,8 KB. Trên trang landing, tệp này còn mang loading="eager" và fetchpriority="high".
Liệu logo đó có phải phần tử LCP của trang landing? Chúng tôi kiểm thay vì đoán. Ngày 16/10/2026, mở trang trong Chrome giả lập điện thoại 412 px, CPU chậm 4 lần, mạng Slow 4G, và đọc LCP bằng PerformanceObserver. Kết quả là một đoạn chữ (thẻ <p>), không phải logo. Trên máy tính, phần tử LCP là tiêu đề H1. Vậy ưu tiên tải đang đặt nhầm cho một ảnh không quyết định LCP. Chúng tôi sẽ sửa và ghi lại ở bài này.
Khi nén ảnh không cứu được LCP
Nén ảnh không giúp gì khi phần tử LCP không phải ảnh, hoặc khi thời gian chết nằm ở chỗ khác. Ba dấu hiệu thường gặp:
- Phần tử LCP là khối chữ, như trang chủ của chúng tôi. Phần bị chậm thường là độ trễ hiển thị, không phải thời gian tải.
- Phần tử LCP là slider hoặc ảnh nền nạp bằng JavaScript, nên trình duyệt chỉ biết tới ảnh sau khi mã chạy xong.
- CSS hoặc JavaScript chặn hiển thị. PSI ngày 16/10/2026 ước tính mục Render-blocking requests trên trang chủ của chúng tôi có thể bớt 1.480 ms, còn mục ảnh là 167 KiB.
Hai con số trên không cùng đơn vị, nên không so trực tiếp được. Điều đáng ghi nhận là báo cáo gợi ý cả hai, nhưng chỉ phần tử LCP cho biết nên ưu tiên việc nào. Nguyên nhân chậm nằm ngoài ảnh được tách riêng ở bài tại sao website chậm.
Nén ảnh vẫn có ích cho băng thông và cho các trang mà LCP đúng là ảnh. Mối liên hệ giữa tốc độ và thứ hạng có ở bài website chậm ảnh hưởng SEO thế nào. Chỉ là bạn không nên hứa trước mức cải thiện LCP khi chưa kiểm phần tử.
Net Solutions làm gì với ảnh và LCP
Chúng tôi làm theo ba bước: đo, sửa, đo lại. Bước đo xác định phần tử LCP của từng trang quan trọng, không đo chung cả site. Bước sửa chỉ động vào ảnh khi ảnh là phần tử LCP hoặc là ảnh nặng bất thường.
Sau khi sửa, chúng tôi đo lại sau 28 ngày. Dữ liệu người dùng thật của Chrome tính theo cửa sổ 28 ngày, nên đo sớm hơn chưa phản ánh thay đổi. Chúng tôi không hứa trước điểm số hay mức LCP.
Câu hỏi thường gặp
WebP có làm giảm chất lượng ảnh không? WebP có hai chế độ. Chế độ lossy bỏ bớt chi tiết khó thấy, còn lossless giữ nguyên điểm ảnh. Google ghi lossy nhỏ hơn JPEG 25–34% ở cùng chỉ số SSIM. Mức nén càng mạnh càng dễ thấy vỡ khối, nên hãy mở ảnh ở 100% và so với bản gốc trước khi đổi cả thư viện.
WordPress bản nào tải ảnh WebP lên được? Từ bản 5.8. Ngoài phiên bản WordPress, máy chủ phải có Imagick hoặc GD hỗ trợ WebP. Nếu thiếu, WordPress báo lỗi lúc tải ảnh lên. WebP lossless cần Imagick. Bạn có thể hỏi nhà cung cấp hosting nếu không chắc máy chủ đang dùng thư viện nào.
Có cần plugin để đổi WebP không? Không bắt buộc. Bạn có thể đổi tay từng ảnh bằng công cụ trên máy rồi tải lên. Plugin chỉ có lợi khi bạn có nhiều ảnh cũ hoặc đăng ảnh thường xuyên, vì nó tự đổi khi tải lên và chạy được theo lô. Dù chọn cách nào, hãy giữ bản gốc.
Có nên lazy-load ảnh đầu trang không? Không. Ảnh nằm trong khung nhìn đầu tiên cần tải ngay, và ảnh LCP là trường hợp rõ nhất. Hãy đặt loading=”eager” hoặc bỏ thuộc tính loading, rồi thêm fetchpriority=”high” cho đúng một ảnh LCP. Ảnh ở thân bài, dưới khung nhìn đầu, mới nên để lazy.
Ảnh đã nhẹ mà LCP vẫn chậm là do đâu? Thường là phần tử LCP không phải ảnh, hoặc thời gian chết nằm ở chỗ khác. Mở mục LCP breakdown trong PSI và xem phần nào dài nhất. Máy chủ trả byte đầu chậm, CSS chặn hiển thị hay JavaScript nạp muộn đều làm LCP chậm dù ảnh rất nhẹ.
Ảnh nên nặng tối đa bao nhiêu KB? Không có ngưỡng chính thức từ Google cho dung lượng ảnh, nên chúng tôi không đưa con số đó. Cách đáng tin hơn là nhìn kết quả: nếu ảnh là phần tử LCP, đo LCP và các phần của nó. Ảnh đủ nhẹ khi phần tải tài nguyên không còn là phần dài nhất.
Muốn biết ảnh có đang kéo LCP của bạn không?
Net Solutions đo phần tử LCP của từng trang quan trọng, chỉ ra phần nào cần sửa và đo lại sau khi sửa. Gọi hoặc nhắn Zalo 0906.207.001.
Xem dịch vụ audit SEONhắn ZaloHotline 0906.207.001
Cập nhật 19/10/2026 bởi Công ty TNHH Net Solutions.