Fri Mar 27 2026 20:00:00 GMT-0400 (北美东部夏令时间)

Lazy Load Images năm 2026: Tăng tốc trang web mà không làm hỏng LCP

Hướng dẫn thực tế về cách lazy load images chính xác: những gì nên trì hoãn, những gì cần ưu tiên, và cách bảo vệ các chỉ số quan trọng như LCP, CLS, SEO, cùng việc tối ưu hóa CDN.

Lazy Load Images năm 2026: Tăng tốc trang web mà không làm hỏng LCP

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

Lazy loading giúp các trang nặng về hình ảnh có cảm giác nhanh hơn vì trình duyệt có thể bỏ qua các yêu cầu hình ảnh nằm dưới phần hiển thị ban đầu. Tuy nhiên, nếu sử dụng không cẩn thận, nó cũng có thể làm chậm một hình ảnh mà người dùng cần ngay lập tức: bức ảnh chủ đạo (hero), ảnh sản phẩm chính, hoặc ảnh bìa bài viết – những yếu tố tạo nên Largest Contentful Paint element.

Hướng dẫn này sẽ chỉ ra nơi nào nên sử dụng loading="lazy" gốc, nơi nào nên giữ các hình ảnh ở chế độ eager, và cách xuất bản các hình ảnh lazy-loaded mà không làm hỏng Core Web Vitals, SEO, hoặc việc phân phối CDN.

Trả lời nhanh: bạn nên lazy load hình ảnh như thế nào?

Chỉ sử dụng lazy loading cho các hình ảnh bắt đầu nằm ngoài khung nhìn (viewport) ban đầu. Giữ hình ảnh LCP có khả năng xảy ra ở chế độ eager, dành riêng chiều rộng và chiều cao cho mọi hình ảnh, và phục vụ các tệp WebP hoặc AVIF đáp ứng từ URL CDN có thể cache.

Đối với HTML thuần túy, cách triển khai đơn giản nhất là thêm loading="lazy" vào các phần tử <img> nằm dưới khung nhìn. Không nên thêm thuộc tính này vào ảnh hero, ảnh sản phẩm chính, hình ảnh bài viết đầu tiên hiển thị, hoặc bất kỳ hình ảnh nào phải xuất hiện trước khi người dùng cuộn chuột.

Khi nghi ngờ, hãy kiểm tra trang bằng Lighthouse hoặc Chrome DevTools. Nếu một hình ảnh lazy được báo cáo là LCP element, hãy loại bỏ lazy loading khỏi hình ảnh đó và cân nhắc sử dụng fetchpriority="high".

Lazy loading thực sự thay đổi điều gì?

Lazy loading thay đổi thời điểm yêu cầu (request timing). Trình duyệt có thể chờ tải xuống một hình ảnh cho đến khi người dùng đủ gần để nhìn thấy nó. Điều này giúp tiết kiệm băng thông trên các trang dài, giảm áp lực yêu cầu ban đầu, và cho phép CSS, font chữ, script, và hình ảnh hiển thị có cơ hội hoàn thành trước tốt hơn.

Nó không làm cho những hình ảnh quá khổ trở nên nhỏ gọn. Một JPEG 2400 px vẫn lãng phí sau khi nó cuối cùng được tải. Hãy kết hợp lazy loading với việc thay đổi kích thước (resizing), nén, và markup đáp ứng ngay từ đầu. Bài viết Image Compression Deep Dive đề cập đến giảm byte, trong khi Mobile Image Optimization Guide đề cập đến srcset và kích thước hiển thị trên thiết bị di động.

Vị trí hình ảnh Lựa chọn tải Lý do
Ảnh hero, bìa hoặc ảnh sản phẩm chính Eager Nó có thể là LCP element và nên bắt đầu sớm
Hình ảnh đầu tiên trong khung nhìn bài viết hiển thị Thường là eager hoặc normal Nó có thể xuất hiện trước ngưỡng lazy trên thiết bị di động
Ảnh chụp màn hình giữa bài viết Lazy Người dùng có thể không bao giờ cuộn đến chúng
Thumbnail gallery dài Lazy Trì hoãn hàng chục yêu cầu sẽ bảo vệ lần render ban đầu
Slide carousel ẩn Thường là lazy, nhưng cần kiểm tra Một số slider giấu các hình ảnh nhanh chóng trở nên hiển thị

Tính năng gốc của trình duyệt được tài liệu hóa bởi MDN là thuộc tính loading trên các thẻ images và iframes trong HTMLImageElement.loading. Đối với các trang web hiện đại, hãy ưu tiên sử dụng tính năng trình duyệt này trước khi thêm thư viện lazy-loading bằng JavaScript.

Những hình ảnh nào không nên lazy load?

Không được lazy load những hình ảnh xác định ấn tượng đầu tiên của trang. Lỗi phổ biến là áp dụng loading="lazy" cho mọi hình ảnh trong template CMS vì nó trông giống như một giải pháp hiệu suất toàn diện.

Hãy giữ các hình ảnh sau ở chế độ eager:

  1. Ảnh hero chính.
  2. Ảnh sản phẩm phía trên nút mua hàng.
  3. Hình ảnh đầu tiên trong bài viết khi nó xuất hiện gần phía trên trên thiết bị di động.
  4. Logo hoặc ảnh chụp màn hình giao diện phải hiển thị trước khi tương tác.
  5. Bất kỳ hình ảnh nào Chrome báo cáo là LCP element.

Timeline showing eager hero image loading first, near-fold assets next, and below-fold gallery images after scroll

Hướng dẫn Core Web Vitals của Google coi LCP là thời gian render của phần tử nội dung lớn nhất hiển thị trong khung nhìn; xem Largest Contentful Paint. Khi phần tử đó là một hình ảnh, việc trì hoãn yêu cầu tải nó là một trong những cách nhanh nhất làm cho chỉ số này tệ đi.

Hãy áp dụng quy tắc này cho các template: khe chứa hình ảnh đầu tiên nên mặc định là eager, và các khối hình ảnh lặp lại sau đó nên mặc định là lazy. Sau đó ghi đè theo loại trang khi ảnh chụp màn hình di động hiển thị một khung nhìn đầu tiên khác.

Làm thế nào để triển khai lazy loading trong HTML?

Hãy sử dụng markup gốc trước:

<img
  src="/images/gallery-chair.webp"
  alt="Ghế gỗ óc chó được chụp từ phía trước cho gallery sản phẩm"
  width="1200"
  height="800"
  loading="lazy"
  decoding="async"
>

Các thuộc tính widthheight quan trọng cũng như loading. Chúng cho phép trình duyệt dành không gian bố cục trước khi tệp đến. Nếu không có không gian dự trữ, một hình ảnh bị trì hoãn có thể đẩy văn bản xuống trang và tạo ra Cumulative Layout Shift.

Đối với các hình ảnh đáp ứng (responsive images), hãy giữ lazy loading trên thẻ <img> fallback:

<picture>
  <source type="image/avif" srcset="/images/gallery-chair-800.avif 800w, /images/gallery-chair-1200.avif 1200w">
  <source type="image/webp" srcset="/images/gallery-chair-800.webp 800w, /images/gallery-chair-1200.webp 1200w">
  <img
    src="/images/gallery-chair-1200.webp"
    alt="Ghế thư giãn gỗ óc chó với đệm xanh trên nền studio trắng"
    width="1200"
    height="800"
    sizes="(max-width: 700px) 92vw, 680px"
    loading="lazy"
  >
</picture>

Đối với hình ảnh có khả năng là LCP, hãy sử dụng mẫu ngược lại:

<img
  src="/images/product-hero.webp"
  alt="Ghế thư giãn gỗ óc chó với đệm xanh trên nền studio trắng"
  width="1600"
  height="1000"
  fetchpriority="high"
>

Bài viết của Google về browser-level image lazy loading khuyến nghị sử dụng lazy loading gốc và cảnh báo rằng các hình ảnh trong khung nhìn hiển thị đầu tiên nên tải bình thường. Lời khuyên đó vẫn là cơ sở sạch nhất cho việc xuất bản năm 2026.

Lazy loading ảnh hưởng đến SEO như thế nào?

Lazy loading an toàn với SEO khi nội dung quan trọng vẫn có thể được khám phá trong trang đã render. Google có thể xử lý JavaScript hiện đại, nhưng SEO hình ảnh sẽ yếu đi khi URL hình ảnh cuối cùng bị ẩn sau tương tác, script chỉ cuộn (scroll-only), cookies, hoặc một placeholder bị lỗi.

Sử dụng markup <img> hoặc <picture> bình thường cho các hình ảnh nội dung. Giữ văn bản alt mô tả, các URL CDN có thể crawl được, và đoạn văn bao quanh giải thích về hình ảnh. Image SEO Guide 2026 có quy trình làm việc rộng hơn về crawl và alt-text.

Kiểm tra SEO Thiết lập lazy-loading tốt Thiết lập rủi ro
URL hình ảnh WebP CDN cuối cùng xuất hiện trong HTML hoặc DOM đã render Script hoán đổi một URL theo dõi mờ sau khi cuộn
Alt text Mô tả hình ảnh hiển thị trong ngữ cảnh Alt text trống hoặc nhồi từ khóa
Ngữ cảnh Đoạn văn gần hình ảnh giải thích ý chính Hình ảnh độc lập không có lời giải thích xung quanh
Mã trạng thái CDN image trả về HTTP 200 mà không cần cookie Hình ảnh chặn bot, kiểm tra hotlink, hoặc trả về 403
Metadata Ảnh bìa trong frontmatter hoặc Open Graph là eager và ổn định Ảnh mạng xã hội trỏ đến tệp cục bộ cũ

Hướng dẫn JavaScript SEO của Google Search Central về lazy loading nói rằng nội dung nên tải khi hiển thị trong khung nhìn và không được phụ thuộc vào hành động người dùng như nhấp chuột hoặc gõ phím; xem Fix lazy-loaded content. Đó là một rào cản hữu ích cho các gallery hình ảnh, tab, và trang cuộn vô hạn.

Lazy loading có thể tiết kiệm bao nhiêu hiệu suất?

Mức tiết kiệm phụ thuộc vào số lượng hình ảnh nằm dưới khung nhìn đầu tiên và kích thước của các tệp đó. Trên một bài viết dài, trình duyệt có thể tránh tải hầu hết các hình ảnh nội dung trong quá trình tải ban đầu. Trên một trang sản phẩm ngắn với một bức ảnh hiển thị, lazy loading có thể tiết kiệm gần như không gì.

Tôi đã mã hóa bốn đồ họa trong bài viết này thành các tệp WebP cục bộ ở kích thước xuất bản. Các tài sản cuối cùng mỗi cái từ 25 KB đến 36 KB, vì vậy lazy loading không che giấu một vấn đề byte lớn nào ở đây. Lợi ích lớn hơn đến từ thời điểm yêu cầu: ảnh bìa có sẵn ngay lập tức, và các sơ đồ sau đó có thể chờ cho đến khi người đọc cuộn chuột.

Bar chart comparing unoptimized image bytes, CDN WebP bytes, and initial bytes after lazy loading

Hãy sử dụng thứ tự này trước khi đổ lỗi cho lazy loading:

  1. Thay đổi kích thước hình ảnh nguồn thành khe hiển thị thực lớn nhất.
  2. Chuyển đổi ảnh và đồ họa hỗn hợp sang WebP hoặc AVIF.
  3. Thêm srcsetsizes cho bố cục di động.
  4. Dự trữ kích thước hoặc tỷ lệ khung hình của hình ảnh.
  5. Giữ hình ảnh LCP ở chế độ eager.
  6. Chỉ lazy load các hình ảnh dưới khung nhìn (below-fold).
  7. Xuất bản qua CDN với bộ nhớ cache có tuổi thọ dài.
  8. Kiểm tra trang trên một viewport di động hẹp.

Nếu bạn cần một chuỗi rộng hơn, Complete Image Optimization Checklist là bước kiểm tra cuối cùng tốt trước khi xuất bản. Đối với các quy tắc CDN và tiêu đề cache, hãy sử dụng Image CDN Guide.

Bạn nên kiểm tra gì trước khi xuất bản?

Kiểm tra trang đã render, chứ không chỉ mã code. Ngưỡng của trình duyệt cho lazy loading gốc là chi tiết triển khai, và một trang hoạt động trên desktop vẫn có thể làm chậm hình ảnh sai trên viewport di động 390 px.

Checklist for prioritizing, deferring, and verifying lazy loaded CDN WebP images before publishing

Chạy kiểm tra xuất bản này:

  • Ảnh bìa hoặc hero tải ở chế độ eager.
  • Hình ảnh LCP có khả năng không được đánh dấu loading="lazy".
  • Mọi hình ảnh đều có widthheight hoặc một container tỷ lệ khung hình ổn định.
  • Các hình ảnh dưới khung nhìn sử dụng loading="lazy".
  • Hình ảnh đáp ứng bao gồm các giá trị sizes thực tế.
  • URL hình ảnh CDN trả về HTTP 200.
  • Tên tệp mô tả hình ảnh hiển thị.
  • Alt text cụ thể và không bị nhồi từ khóa.
  • Lighthouse hoặc PageSpeed Insights không đánh dấu hình ảnh lazy là LCP.
  • Ảnh chụp màn hình di động không có khoảng trống lớn hoặc nhảy bố cục nào.

Đối với các nhóm phát triển, hãy thêm một quy tắc template: chỉ các thành phần hình ảnh nội dung lặp lại mới nên mặc định lazy load. Các thành phần hero, media sản phẩm chính và hình ảnh biên tập phía trên khung nhìn cần yêu cầu quyết định rõ ràng.

Danh sách kiểm tra lazy-loading cho năm 2026

Lazy loading hoạt động tốt nhất như một phần nhỏ của quy trình xử lý hình ảnh. Nó nên được thực hiện sau các bước kiểm tra về định dạng, kích thước, độ ưu tiên, khả năng truy cập và CDN.

Quyết định Mặc định sử dụng Thay đổi khi
Hình ảnh có ý nghĩa đầu tiên Eager, có thể là fetchpriority="high" Kiểm tra chứng minh một phần tử khác là LCP
Hình ảnh nội dung sau phần giới thiệu loading="lazy" Hình ảnh xuất hiện trong khung nhìn di động đầu tiên
Gallery dài Thumbnail lazy với kích thước dự trữ Gallery là trải nghiệm chính phía trên khung nhìn
Hình ảnh trang trí Tránh hoặc sử dụng alt text trống Hình ảnh truyền tải nội dung thực tế
Phân phối CDN URL WebP hoặc AVIF bất biến (immutable) CMS phải chuyển đổi từ một bản tải lên gốc

Trước khi xuất bản, hãy kiểm tra khung nhìn đầu tiên và tự hỏi một câu hỏi thiết thực: liệu trang có còn ý nghĩa nếu mọi hình ảnh dưới khung nhìn đều chờ cho đến khi cuộn? Nếu có, lazy loading có lẽ đang giúp ích. Nếu trang bắt đầu bằng một khe hero trống, hãy sửa độ ưu tiên trước khi chạm vào bất cứ thứ gì khác.

Sử dụng các công cụ miễn phí trong khi bạn theo dõi hướng dẫn.

Ảnh bìa cho PNG sang WebP: Hướng dẫn Chuyển đổi và Thu nhỏ Ảnh PNG

Tue Mar 17 2026 20:00:00 GMT-0400 (北美东部夏令时间)

PNG sang WebP: Hướng dẫn Chuyển đổi và Thu nhỏ Ảnh PNG

Chuyển đổi PNG sang WebP để tối ưu hóa kích thước tệp web. Tìm hiểu khi nào nên dùng WebP không mất dữ liệu (lossless), khi nào dùng kiểu nén có tổn thất (lossy), cùng các lệnh cwebp và Pillow với fallback PNG.