Tối ưu hóa hình ảnh cho Core Web Vitals: LCP, CLS và INP

Cập nhật lần cuối: June 28, 2026

Images là nguyên nhân lớn nhất gây ra điểm Core Web Vitals kém. Trên các trang web tôi kiểm tra năm nay, phần tử LCP là một hình ảnh trong 8/10 trường hợp, và hero trung bình nặng 1.6 MB trước khi tôi tối ưu hóa nó. Tôi đã tối ưu hóa những hình ảnh đó và thấy LCP giảm từ 3.9s xuống còn 1.7s trên dữ liệu thực tế, đồng thời CLS về bằng không.

Bài viết chuyên sâu này chỉ tập trung vào các cách khắc phục liên quan đến hình ảnh giúp cải thiện ba chỉ số Core Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) và INP (Interaction to Next Paint). Nếu bạn muốn quy trình tối ưu hóa, CDN hoặc thay đổi kích thước toàn diện hơn, hãy kết hợp bài viết này với bảng kiểm tối ưu hóa hình ảnh hoàn chỉnh.

Trả lời nhanh: những cách khắc phục hình ảnh nào giúp cải thiện Core Web Vitals?

Năm cách khắc phục thực sự đã giúp tôi tăng điểm số:

1. Nén và thay đổi kích thước hero image về kích thước hiển thị, sau đó xuất nó dưới dạng WebP hoặc AVIF.
2. Preload hình ảnh LCP bằng fetchpriority="high".
3. Không bao giờ lazy-load hero nằm trên phần tử cuộn (above-the-fold).
4. Đặt chiều rộng và chiều cao rõ ràng (hoặc CSS aspect-ratio) cho mọi hình ảnh để loại bỏ CLS.
5. Thêm decoding="async" và thay đổi kích thước bằng srcset để bảo vệ INP.

Hãy đo trước và sau bằng dữ liệu thực tế của PageSpeed Insights, chứ không chỉ là các lần chạy thử nghiệm Lighthouse lab. Dữ liệu lab nói dối về CWV vì nó sử dụng một thiết bị mô phỏng duy nhất; dữ liệu thực tế mới là thứ Google dùng để xếp hạng.

Hình ảnh ảnh hưởng đến từng Core Web Vital như thế nào?

Mỗi chỉ số đều liên quan đến một chế độ lỗi hình ảnh khác nhau. Biết bạn đang chống lại vấn đề gì sẽ giúp bạn không sửa nhầm thứ gì.

Vấn đề là: việc khắc phục LCP bằng một hero lớn hơn, sắc nét hơn có thể làm trầm trọng thêm INP, và lazy-loading quá mức có thể làm tệ cả LCP và INP. Hãy tối ưu hóa từng chỉ số, sau đó đo lại toàn bộ bộ dữ liệu.

Làm thế nào để giảm kích thước file ảnh LCP?

Đây là đòn bẩy trực tiếp nhất. Tôi đã chuyển một hero của khách hàng từ 2.1 MB PNG xuống còn 148 KB WebP bằng ba bước này, và LCP lập tức giảm khoảng 1.1s:

• Thay đổi kích thước về gấp 2 lần chiều rộng hiển thị lớn nhất (một màn hình 1200px cần nguồn khoảng 2400px, chứ không phải 6000px).
• Nén về chất lượng 75 đến 80; mức tiết kiệm là 60 đến 70 phần trăm mà không mất nét đáng kể nào.
• Xuất WebP hoặc AVIF; AVIF nhỏ hơn WebP thêm 25 đến 35 phần trăm nữa.

Để biết quy trình thay đổi kích thước đầy đủ, hãy xem hướng dẫn thay đổi kích thước ảnh cho web. Một nguồn 4000px được phục vụ cho một hộp 400px là những byte lãng phí trên mọi thiết bị.

Làm thế nào để preload hero bằng fetchpriority?

Trình duyệt phát hiện hình ảnh muộn. Chúng phân tích HTML, tải CSS, sau đó mới tìm thấy thẻ <img>. Preloading báo cho trình duyệt biết bắt đầu yêu cầu ngay lập tức, song song với CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

Tôi đã đo được mức tăng LCP từ 200 đến 500ms chỉ nhờ cách này. fetchpriority="high" nâng cao độ ưu tiên yêu cầu để hero vượt qua lưu lượng mạng khác. Google tài liệu hóa mẫu này trong hướng dẫn Largest Contentful Paint.

Tại sao không bao giờ được lazy-load ảnh LCP?

loading="lazy" trì hoãn yêu cầu cho đến khi hình ảnh gần khu vực hiển thị (viewport). Đối với hình ảnh dưới phần tử cuộn thì hoàn toàn chính xác; nhưng đối với hero thì lại tai hại. Tôi từng xuất bản một hero với lazy-loading và LCP nhảy vọt 800ms vì yêu cầu bắt đầu muộn hơn một giây.

Quy tắc tôi tuân theo: hình ảnh hiển thị đầu tiên nhận loading="eager" (hoặc không có thuộc tính nào). Mọi thứ bên dưới phần tử cuộn đều nhận loading="lazy". Nếu bạn muốn chiến lược lazy-loading đầy đủ, hãy đọc bài lazy load images này.

Làm thế nào để dành chỗ trống nhằm loại bỏ CLS?

CLS đo lường sự dịch chuyển bố cục bất ngờ. Nguyên nhân hình ảnh kinh điển: một thẻ <img> không có dimensions sẽ hiển thị với chiều cao bằng 0, sau đó bật lên kích thước đầy đủ khi byte đến, đẩy mọi đoạn văn bản bên dưới nó xuống.

Khi trình duyệt biết kích thước từ trước, nó sẽ dành chỗ cho hộp và không có gì di chuyển khi hình ảnh được vẽ.

<!-- Xấu: gây dịch chuyển bố cục -->
<img src="photo.webp" alt="Storefront">

<!-- Tốt: trình duyệt dành chỗ cho hộp -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Tôi đã kiểm tra một trang danh mục với 40 hình ảnh sản phẩm và không có dimensions; CLS là 0.34. Việc thêm width/height cho mọi hình ảnh đã đưa CLS về 0.02 trong chu kỳ dữ liệu thực tế tiếp theo. Google giải thích cơ chế này trong hướng dẫn Cumulative Layout Shift.

Đối với hình ảnh responsive, khi CSS ghi đè thuộc tính width, chỉ riêng thuộc tính height là không đủ. aspect-ratio sẽ dành chỗ dọc chính xác ở bất kỳ chiều rộng viewport nào:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Làm thế nào để giữ việc decode hình ảnh không chạy trên main thread (INP)?

INP thay thế FID làm chỉ số phản hồi. Việc decode một hình ảnh lớn có thể chặn main thread trong 50 đến 100ms, khiến thao tác chạm của người dùng vào menu hoặc nút "Thêm vào giỏ hàng" cảm thấy bị đơ.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" gợi ý cho trình duyệt decode ngoài main thread. Đây là một chiến thắng chỉ với một thuộc tính mà không có nhược điểm nào; áp dụng nó cho mọi hình ảnh, chứ không chỉ hero.

Cũng cần thay đổi kích thước bằng srcset: một hình ảnh 4000x3000 hiển thị ở 400x300 buộc thiết bị phải decode khoảng 100 lần pixel hơn mức nó hiển thị. Hãy phục vụ đúng kích thước theo viewport với srcset và sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

Trên điện thoại, điều này hiện tải xuống và decode file 400w, chỉ là một phần nhỏ công việc. Kết hợp với CDN tái mã hóa và lưu cache từng derivative, đây là cách khắc phục INP có đòn bẩy cao nhất. Xem hướng dẫn image CDN để thiết lập thay đổi kích thước tức thời (on-the-fly resizing).

Nên xuất định dạng nào?

Việc lựa chọn định dạng khuếch đại với mọi cách khắc phục ở trên, bởi vì file nhỏ hơn có nghĩa là LCP nhanh hơn, decode ít hơn và INP tốt hơn.

Tôi xuất AVIF với WebP fallback thông qua phần tử <picture>. Đối với hầu hết các trang web, WebP là đủ và tránh được sự phức tạp khi mã hóa của AVIF.

Đo lường trước và sau của tôi

Để chứng minh đây không phải lý thuyết, đây là một trang thực tế tôi đã tối ưu hóa tháng trước (dữ liệu di động, cửa sổ 28 ngày):

• LCP: Từ 3.9s xuống 1.7s (hero thay đổi kích thước từ 2.1MB sang 148KB WebP, được preload).
• CLS: Từ 0.34 xuống 0.02 (thêm width/height cho tất cả hình ảnh).
• INP: Từ 230ms xuống 140ms (decoding="async" cộng với srcset right-sizing).

Mô hình này lặp lại trên các trang khác: kích thước file ảnh tác động nhiều nhất đến LCP, dimensions tác động nhiều nhất đến CLS, và chiến lược decode tác động nhiều nhất đến INP. Tối ưu hóa từng chỉ số, sau đó chạy lại toàn bộ bộ dữ liệu.

Bảng kiểm Core Web Vitals cho hình ảnh

Hãy chạy bảng kiểm này trước khi bạn xuất bản bất kỳ trang nào mà hình ảnh quan trọng:

1. Hero được nén xuống dưới 200 KB.
2. Hero được preload với fetchpriority="high".
3. Hero không lazy-load (loading="eager").
4. Mọi hình ảnh đều có thuộc tính width và height.
5. Hình ảnh linh hoạt sử dụng CSS aspect-ratio.
6. Tất cả hình ảnh sử dụng decoding="async".
7. Hình ảnh dưới phần tử cuộn sử dụng loading="lazy".
8. Phục vụ AVIF hoặc WebP, JPEG chỉ là fallback.
9. srcset và sizes cung cấp các file phù hợp với hiển thị.
10. Hình ảnh được phục vụ từ CDN có edge caching.

Một lưu ý thực tế

Các con số lab không phải là con số field. Các lần dọn dẹp của tôi trông hoàn hảo trong Lighthouse nhưng vẫn dao động trên thực địa, bởi vì người dùng thực tế đang sử dụng 4G bị giới hạn tốc độ, Android tầm trung và Wi-Fi tắc nghẽn. Sau khi áp dụng mọi cách khắc phục ở đây, hãy theo dõi dữ liệu field PageSpeed Insights của bạn trong suốt cửa sổ 28 ngày trước khi tuyên bố chiến thắng. CWV được tính dựa trên trải nghiệm thực tế của người dùng, chứ không phải những gì trình mô phỏng dự đoán.

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

Hình ảnh tác động nhiều nhất đến chỉ số Core Web Vitals nào?

LCP. Phần tử Largest Contentful Paint thường là một hero image, vì vậy kích thước file và thứ tự tải của nó chi phối chỉ số này. CLS đứng thứ hai — do hình ảnh không có dimensions dành chỗ — và INP đứng thứ ba, thông qua việc decode hình ảnh chậm chặn main thread. Thu nhỏ và preload hero tác động đến LCP nhiều hơn bất kỳ cách khắc phục đơn lẻ nào khác.

Tôi có cần cả lazy loading và preload không?

Chỉ một hình ảnh được preload — đó là hero LCP, vốn phải tải ngay lập tức (eagerly). Mọi thứ bên dưới phần tử cuộn đều nhận loading="lazy" để nó không cạnh tranh băng thông với hero. Preloading một hình ảnh đang lazy-loaded là mâu thuẫn và lãng phí byte; preload hero, lazy-load phần còn lại.

Bao lâu thì Core Web Vitals phản ánh các thay đổi về hình ảnh của tôi?

Lên đến 28 ngày. CWV được tính trên cửa sổ dữ liệu field thực tế liên tục được thu thập bởi Chrome User Experience Report, chứ không phải một lần chạy lab duy nhất. Bạn sẽ thấy sự thay đổi trong các công cụ lab (Lighthouse) ngay lập tức, nhưng điểm số mà Google sử dụng cần một cửa sổ đầy đủ người dùng thực để cập nhật.

Credit hình ảnh

• Máy tính xách tay hiển thị trang web đang tải trong khi nhà phát triển xem xét hiệu suất — photo by Christina Morillo trên Pexels
• Màn hình máy tính hiển thị bảng điều khiển kiểm tra hiệu suất — photo by Tima Miroshnichenko trên Pexels
• Máy tính xách tay hiển thị biểu đồ phân tích web thời gian thực — photo by weCare Media trên Pexels
• Máy tính xách tay hiển thị mã nguồn bên cạnh đồ thị chỉ số hiệu suất — photo by Daniil Komov trên Pexels