Trích xuất ảnh quan trọng cho LCP và tối ưu hóa SEO

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

Trích xuất hình ảnh quan trọng (critical image extraction) nghĩa là tìm ra bức ảnh kiểm soát ấn tượng thị giác đầu tiên của một trang. Trên nhiều trang sản phẩm, landing page và bài đăng blog, bức ảnh đó là hero image, ảnh sản phẩm chính, hoặc minh họa lớn phía trên phần gấp (above-the-fold). Nếu bạn xác định nó sớm, bạn có thể tải trước (preload) hoặc ưu tiên tệp tin đúng thay vì tăng tốc độ tất cả các hình ảnh một cách đồng đều.

Câu trả lời nhanh: làm thế nào để trích xuất hình ảnh quan trọng?

Sử dụng critical image extraction để đặt tên cho hình ảnh có khả năng trở thành phần tử Largest Contentful Paint nhất, sau đó áp dụng phương thức tải đặc biệt cho tệp tin đó. Thông thường điều này có nghĩa là hình ảnh lớn nhất hiển thị trong viewport ban đầu sẽ được gán fetchpriority="high", không sử dụng lazy loading, kích thước ổn định, và đôi khi là một <link rel="preload">.

Không nên preload mọi tệp lớn. Chỉ nên preload ảnh hero hoặc ảnh sản phẩm khi trình duyệt nếu không có can thiệp nào khác thì sẽ phát hiện nó muộn, chẳng hạn như bên trong CSS, carousel, component được render bởi client, hoặc một stack <picture> responsive với việc lựa chọn nguồn phức tạp.

Sau khi thay đổi, hãy xác minh kết quả. Tài liệu Largest Contentful Paint của Google định nghĩa LCP xung quanh phần tử nội dung lớn nhất hiển thị, và PageSpeed Insights sẽ cho biết phần tử nào đã được đo. Chrome DevTools cũng nên hiển thị yêu cầu hình ảnh quan trọng sớm trong waterfall.

Sử dụng thứ tự này:

1. Tải trang ở viewport di động thực tế.
2. Tìm hình ảnh hoặc poster lớn nhất phía trên phần gấp.
3. Kiểm tra xem PageSpeed hay Lighthouse có báo cáo nó là LCP không.
4. Xóa loading="lazy" khỏi hình ảnh đó.
5. Thêm kích thước (dimensions) hoặc tỷ lệ khung hình (aspect ratio).
6. Thêm fetchpriority="high" khi đó là thẻ <img>.
7. Chỉ preload khi việc phát hiện diễn ra muộn.
8. Giữ các hình ảnh dưới phần gấp ở chế độ lazy.
9. Kiểm tra lại sau khi thay đổi layout, CMS, hoặc nội dung hero.

Hình ảnh nào được coi là hình ảnh quan trọng?

Hình ảnh quan trọng là bức ảnh mà người truy cập chờ đợi trước khi trang cảm thấy hữu ích. Nó thường, nhưng không phải lúc nào cũng là phần tử LCP. Một logo nhỏ ở đầu trang có thể tải trước, nhưng hiếm khi nó kiểm soát mức độ sẵn sàng nhận thức. Một hình ảnh hero chiếm một nửa màn hình điện thoại thì thường làm được điều đó.

Hãy kết hợp kích thước hiển thị (rendered size), vị trí viewport, và mục đích sử dụng. Một thumbnail trong menu điều hướng là có thể thấy được, nhưng nó không phải nội dung chính. Hình nền phía sau tiêu đề có thể quan trọng nếu nó là phần tử lớn nhất hiển thị. Ảnh thẻ mạng xã hội trong metadata quan trọng cho việc chia sẻ, nhưng nó sẽ không được tải về trang đã render trừ khi template cũng hiển thị nó.

Hướng dẫn LCP của Google liệt kê các thẻ <img>, các phần tử hình ảnh bên trong SVG, ảnh poster video, và hình nền CSS là những ứng cử viên có thể. Điều đó có nghĩa là việc trích xuất không thể dừng lại ở việc tìm kiếm thẻ <img> đầu tiên. Bạn cần kiểm tra trang đã render.

Đối với công việc liên quan, hãy giữ checklist tối ưu hóa hình ảnh cho SEO rộng hơn gần đó. Critical image extraction quyết định thứ tự ưu tiên; nén, tên tệp, alt text và nội dung có cấu trúc vẫn quyết định liệu hình ảnh có hữu ích sau khi nó tải hay không.

Hình ảnh nào nên được preload hoặc ưu tiên cao?

Hãy ưu tiên cao cho một hình ảnh: hình ảnh LCP có khả năng của trang hiện tại. Nếu hai ứng cử viên gần nhau, hãy chọn cái lớn nhất trên di động trước, bởi vì Core Web Vitals di động thường khó vượt qua hơn.

Sử dụng fetchpriority="high" khi hình ảnh quan trọng là thẻ <img> thông thường hoặc thẻ <img> fallback trong phần tử <picture>. Hướng dẫn fetch priority của Google giải thích rằng gợi ý này thay đổi thứ tự ưu tiên tài nguyên của trình duyệt mà không thay đổi đường dẫn phát hiện markup.

Sử dụng preload khi vấn đề là việc phát hiện (discovery). rel="preload" reference của MDN mô tả preload là một cách để yêu cầu tài nguyên sớm hơn trong quá trình tải trang. Điều này giúp ích khi URL hình ảnh xuất hiện trong CSS, đến sau hydration, hoặc nằm sau markup mà trình duyệt không thể phát hiện đủ nhanh.

Đối với một hình ảnh responsive thông thường, markup có thể trông như thế này:

<img
  src="/images/product-hero-960.webp"
  srcset="/images/product-hero-480.webp 480w, /images/product-hero-960.webp 960w, /images/product-hero-1440.webp 1440w"
  sizes="(max-width: 640px) 100vw, 960px"
  width="960"
  height="640"
  fetchpriority="high"
  alt="Black leather backpack shown open with laptop sleeve visible"
>

Nếu hình ảnh là background CSS và bạn chưa thể di chuyển nó lên HTML, hãy preload cùng một tài sản mà viewport ban đầu sẽ sử dụng:

<link
  rel="preload"
  as="image"
  href="/images/home-hero-960.webp"
  imagesrcset="/images/home-hero-480.webp 480w, /images/home-hero-960.webp 960w"
  imagesizes="100vw"
>

Hướng dẫn preloading hình ảnh bao gồm cú pháp chi tiết hơn. Quy tắc quan trọng ở đây hẹp hơn: preload sau khi trích xuất, chứ không phải trước đó.

Làm thế nào để tránh lazy-loading sai hình ảnh?

Lazy loading thuộc về khu vực dưới viewport đầu tiên. Việc áp dụng nó cho critical image là một sai lầm vì nó báo cho trình duyệt chờ đợi cho đến khi kiểm tra layout và khoảng cách hoàn tất. Hướng dẫn lazy loading cấp độ trình duyệt của Google cảnh báo chống lại việc lazy-loading các hình ảnh hiển thị ngay lập tức.

Hãy kiểm tra kỹ lưỡng các global image components. Nhiều framework mặc định đặt lazy loading vì hầu hết các hình ảnh đều nằm dưới phần gấp. Mặc định này làm hỏng các trang mà hình ảnh hero được bọc trong cùng một component với thumbnail gallery.

Kiểm tra những vị trí sau:

1. Các renderer hình ảnh rich-text của CMS.
2. Components gallery sản phẩm.
3. Components hình ảnh bìa blog.
4. Tiện ích nền hero trên trang chủ.
5. Sliders ẩn tất cả các slide cho đến khi JavaScript chạy.
6. Components placeholder thay thế data-src thành src.
7. Các khối cá nhân hóa của bên thứ ba (third-party personalization blocks).
8. Các wrapper A/B testing làm chậm markup hero.

Cách khắc phục thường nhỏ. Thêm một tùy chọn priority, aboveFold, hoặc isLcp vào component và yêu cầu chủ sở hữu template chọn nó một cách rõ ràng. Hình ảnh body dưới phần gấp vẫn nên sử dụng lazy loading gốc, đặc biệt là các hướng dẫn dài với ảnh chụp màn hình và sơ đồ.

Đối với các trang nặng về di động, hãy kết hợp điều này với hướng dẫn tối ưu hóa hình ảnh di động. Một hero được ưu tiên đúng cách vẫn hoạt động kém nếu điện thoại tải một crop desktop 2400 px cho vị trí 390 px.

Bạn nên trích xuất hình ảnh từ trang thực tế như thế nào?

Bắt đầu trong trình duyệt, không phải trong thư viện tài sản (asset library). Thư viện tài sản cho bạn biết cái gì tồn tại; trình duyệt cho bạn biết người dùng nhận được gì.

Sử dụng quy trình làm việc thủ công này:

1. Mở trang ở độ rộng 390 px và tải lại với cache bị vô hiệu hóa.
2. Ghi chú hình ảnh lớn nhất hiển thị trước khi cuộn.
3. Kiểm tra phần tử đó và ghi lại URL cuối cùng của nó.
4. Xác nhận xem nó là <img>, <picture>, video poster, hay CSS background.
5. Xác nhận chiều rộng và chiều cao đã render.
6. So sánh chiều rộng tệp tải xuống với vị trí hiển thị (rendered slot).
7. Tìm kiếm loading="lazy" hoặc gán src bị trì hoãn bởi JavaScript.
8. Kiểm tra DevTools Network để biết thời gian bắt đầu yêu cầu và độ ưu tiên.
9. Chạy PageSpeed Insights và ghi lại phần tử LCP.
10. Lặp lại trên desktop nếu hero thay đổi theo breakpoint.

Đối với việc kiểm toán template, hãy tạo một bảng trích xuất nhỏ trước khi chỉnh sửa code:

Tôi đã tạo các sơ đồ trong bài viết này dưới dạng tệp WebP và giữ mỗi tệp dưới 40 KB. Đó không phải là mục tiêu chung cho ảnh, nhưng đó là một lời nhắc nhở hữu ích: hình ảnh được trích xuất nên có kích thước phù hợp trước khi nó nhận ưu tiên. Nếu tệp vẫn còn quá lớn, hãy sử dụng deep dive nén hình ảnh và hướng dẫn thay đổi kích thước hàng loạt trước khi xuất bản.

Làm thế nào để xác minh hình ảnh quan trọng trong các công cụ?

Xác minh có hai nhiệm vụ. Thứ nhất, chứng minh rằng hình ảnh được chọn thực sự là phần tử LCP hoặc ứng cử viên LCP nghiêm túc. Thứ hai, chứng minh rằng trình duyệt phát hiện nó đủ sớm.

Sử dụng PageSpeed Insights cho bối cảnh field và lab. Bảng chẩn đoán thường đặt tên phần tử LCP, và ảnh chụp màn hình giúp xác nhận liệu phần tử được báo cáo có khớp với hero trực quan của trang hay không. Sử dụng Lighthouse hoặc DevTools Performance khi bạn cần một trace cục bộ.

Sử dụng DevTools Network cho hành vi yêu cầu:

1. Lọc theo các yêu cầu hình ảnh (image requests).
2. Tải lại với cache bị vô hiệu hóa.
3. Xác nhận rằng hình ảnh quan trọng bắt đầu gần phía trên của waterfall.
4. Kiểm tra xem độ ưu tiên có là High hoặc được nâng cấp sớm không.
5. Xác nhận rằng các hình ảnh dưới phần gấp không cùng cạnh tranh tại một thời điểm.
6. Kiểm tra mã trạng thái (status code), loại nội dung (content type), kích thước truyền tải (transfer size), và header cache.

Sử dụng kiểm tra HTML đã render cho các lỗi markup:

1. Hình ảnh quan trọng có src hoặc srcset có thể phát hiện được trong markup ban đầu.
2. Nó không có loading="lazy".
3. Nó có width và height, hoặc tỷ lệ khung hình CSS ổn định.
4. Alt text của nó mô tả chủ thể hiển thị khi hình ảnh là nội dung.
5. URL CDN trả về phản hồi 200 có thể crawl được.

Đối với tìm kiếm, thực tiễn tốt nhất SEO hình ảnh của Google cũng nhấn mạnh tên tệp mô tả, alt text và văn bản giải thích hữu ích xung quanh. Critical image extraction cải thiện thứ tự ưu tiên tải, nhưng cùng một hình ảnh vẫn cần ngữ cảnh tìm kiếm.

Điều gì làm hỏng việc trích xuất hình ảnh quan trọng?

Lỗi phổ biến nhất là coi mọi trang đều có hero giống nhau. Một index blog, trang sản phẩm và trang giá cả có thể có các ứng cử viên LCP khác nhau. Bước trích xuất phải xảy ra ở cấp độ template và ở cấp độ breakpoint.

Hãy chú ý đến những cạm bẫy này:

1. Preloading ảnh Open Graph. Ảnh thẻ xã hội có thể không bao giờ được render trên trang.
2. Lazy-loading ảnh sản phẩm đầu tiên. Các gallery sản phẩm thường kế thừa mặc định thumbnail.
3. Ưu tiên mọi slide carousel. Chỉ slide hiển thị đầu tiên mới có thể quan trọng khi tải.
4. Bỏ qua việc crop di động. Desktop và mobile có thể chọn các hình ảnh LCP khác nhau.
5. Sử dụng background CSS cho nội dung ý nghĩa. Chúng khó ưu tiên hơn và kém khả năng truy cập hơn.
6. Quên kích thước (dimensions). Ưu tiên không ngăn chặn việc dịch chuyển layout (layout shift).
7. Xuất bản một nguồn quá khổ. Một hình ảnh 3 MB có độ ưu tiên cao vẫn chậm.
8. Chỉ kiểm tra trên Wi-Fi cục bộ. Mạng 4G chậm phơi bày sự chậm trễ phát hiện.

Nếu vấn đề chủ yếu là trọng lượng tệp, hãy bắt đầu với checklist tối ưu hóa hình ảnh hoàn chỉnh. Nếu vấn đề là lựa chọn định dạng, hãy so sánh AVIF vs WebP trước khi thay đổi quy tắc phân phối.

Tóm tắt: checklist trích xuất hình ảnh quan trọng

Critical image extraction là một quyết định về tốc độ trang (page-speed), chứ không phải bài tập đặt tên tài sản. Hãy tìm ra hình ảnh kiểm soát viewport đầu tiên, chỉ áp dụng xử lý tải sớm cho hình ảnh đó, và ngăn phần còn lại của trang cạnh tranh với nó.

Trước khi xuất bản, xác nhận:

1. Hình ảnh LCP có khả năng được đặt tên trong template hoặc ghi chú kiểm toán.
2. Các ứng cử viên di động và desktop được kiểm tra riêng biệt.
3. Hình ảnh quan trọng không bị lazy-load.
4. fetchpriority="high" được sử dụng cho ứng cử viên <img> LCP hiển thị.
5. Preload chỉ được sử dụng khi việc phát hiện diễn ra muộn.
6. Tệp đã chọn được thay đổi kích thước và nén.
7. Chiều rộng và chiều cao, hoặc tỷ lệ khung hình, dành chỗ layout.
8. Hình ảnh dưới phần gấp vẫn ở chế độ lazy.
9. PageSpeed Insights báo cáo phần tử LCP mong đợi.
10. DevTools hiển thị yêu cầu hình ảnh quan trọng sớm trong waterfall.
11. URL CDN trả về 200 với loại hình ảnh dự kiến.
12. Hình ảnh có alt text hữu ích và nội dung giải thích gần đó.

Credit hình ảnh

• Sơ đồ ứng cử viên, diagram LCP, cây quyết định ưu tiên và dấu vết xác minh cho bài viết này được tạo bằng ImageMagick và xuất dưới dạng WebP.