Hướng dẫn tối ưu hóa hình ảnh di động cho các trang web nhanh hơn

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

Tối ưu hóa hình ảnh trên thiết bị di động bắt đầu bằng một ràng buộc: điện thoại không nên tải xuống các pixel mà nó không thể hiển thị. Hãy thay đổi kích thước nguồn, phục vụ các biến thể đáp ứng (responsive variants), giữ cho hình ảnh lớn nhất ở khu vực above-the-fold tránh lazy loading, và xuất bản các file WebP hoặc AVIF có thể thu thập dữ liệu qua CDN.

Trả lời nhanh: nên tối ưu hóa hình ảnh cho thiết bị di động như thế nào?

Hãy sử dụng thứ tự này: thay đổi kích thước trước, mã hóa sau, phân phối thứ ba, đo lường cuối cùng. Một bức ảnh sản phẩm 4000 px hiển thị ở độ rộng 390 px là lãng phí ngay cả khi nó đã được nén. Trình duyệt vẫn phải tải xuống, giải mã và điều chỉnh tỷ lệ của nó trước khi trang cảm thấy sẵn sàng.

Đối với hầu hết các trang di động, hãy gửi một bộ nguồn WebP hoặc AVIF với độ rộng khoảng 400, 800 và 1200 px. Hãy giữ lại fallback JPEG nếu đối tượng của bạn bao gồm các trình duyệt cũ, client email hoặc feed đối tác. Để đưa ra quyết định sâu hơn về format, hãy sử dụng so sánh AVIF vs WebP.

Hướng dẫn LCP của Google nói rằng các trang nên nhắm mục tiêu Largest Contentful Paint ở mức 2.5 giây trở xuống tại phân vị thứ 75, được tách biệt theo thiết bị di động và máy tính để bàn. Hình ảnh thường là phần tử LCP, vì vậy hình ảnh hero xứng đáng được xử lý đặc biệt: preload hoặc ưu tiên nó, đặt kích thước thực tế, và không lazy-load nó.

Điều gì thực sự thay đổi trên điện thoại?

Điện thoại thay đổi ba thứ cùng một lúc: độ rộng viewport, chất lượng mạng và mật độ bố cục (layout density). Hình ảnh máy tính để bàn thường thất bại trên thiết bị di động vì trang giữ nguyên tài sản 1600 px, cắt xén chủ thể kém, hoặc trì hoãn hình ảnh hero phía sau JavaScript.

Tôi đã tạo một đồ họa nguồn 1600 x 1000 và mã hóa nó dưới dạng WebP q82 ở ba độ rộng khác nhau. Kết quả cho thấy tại sao thay đổi kích thước lại tốt hơn tinh chỉnh chất lượng:

Những con số này mang tính minh họa, không phải phổ quát. Một bức ảnh chi tiết sẽ lớn hơn đồ họa sạch này, và một logo phẳng sẽ nhỏ hơn. Quy tắc hữu ích là ổn định: yêu cầu trình duyệt chọn từ các ứng viên độ rộng thực tế thay vì một file quá khổ duy nhất.

Bạn nên tạo những kích thước hình ảnh di động nào?

Bắt đầu từ slot hiển thị (rendered slot), chứ không phải từ file camera gốc. Kiểm tra mẫu của bạn tại các điểm ngắt (breakpoints) phổ biến và ghi lại độ rộng CSS tối đa cho từng loại hình ảnh.

Sử dụng các mô tả độ rộng khi độ rộng bố cục thay đổi:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Reusable water bottle on a kitchen counter"
>

Hướng dẫn hình ảnh đáp ứng của MDN giải thích mô hình lựa chọn srcset và sizes. Phiên bản ngắn gọn: srcset liệt kê các ứng viên, và sizes cho trình duyệt biết slot hiển thị sẽ rộng bao nhiêu trước khi bố cục hoàn thành.

Đối với quy trình làm việc hàng loạt (batch workflow), hãy tạo độ rộng từ cùng một file gốc. Hướng dẫn thay đổi kích thước hàng loạt đề cập đến mẫu dòng lệnh, và phân tích chuyên sâu nén hình ảnh giải thích tại sao việc thay đổi kích thước nên xảy ra trước khi nén cuối cùng.

Khi nào bạn nên sử dụng picture cho các crop di động?

Sử dụng <picture> khi hình ảnh trên thiết bị di động cần một kiểu cắt (crop) khác, chứ không chỉ là một file nhỏ hơn. Một hero desktop rộng có thể trở nên vô dụng trên điện thoại nếu chủ thể nằm ở phía xa bên trái hoặc khu vực văn bản che mất sản phẩm.

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Trail running shoe with the sole tread visible"
  >
</picture>

Sử dụng art direction cho:

1. Hình ảnh hero sản phẩm nơi sản phẩm trở nên nhỏ trên thiết bị di động.
2. Banner biên tập (editorial banners) nơi khuôn mặt hoặc vật thể phải giữ ở vị trí trung tâm.
3. Danh sách thị trường cần ảnh thu nhỏ hình vuông và hình ảnh chi tiết rộng.
4. Ảnh trước/sau nơi cả hai bên phải vẫn dễ đọc.
5. Ảnh chụp màn hình với văn bản nhỏ cần cắt chặt hơn.

Không sử dụng <picture> thay thế cho các độ rộng đáp ứng thông thường. Nếu bố cục giống nhau, srcset cộng với sizes sẽ đơn giản hơn.

WebP, AVIF và JPEG phù hợp với hiệu suất di động như thế nào?

Sử dụng WebP làm định dạng di động cơ bản khi bạn cần một file hiện đại hoạt động rộng rãi. Sử dụng AVIF khi quy trình của bạn có thể tạo ra nó và bạn có thể giữ lại fallback WebP hoặc JPEG. Giữ JPEG cho email, hệ thống đối tác cũ và kho lưu trữ nguồn mà các công cụ khác cần mở.

Danh sách kiểm tra tối ưu hóa hình ảnh hoàn chỉnh bao gồm trình tự xuất bản rộng hơn. Nếu bạn cần so sánh các công cụ xuất WebP và AVIF, hãy xem các giải pháp thay thế TinyPNG.

Sử dụng ngăn xếp <picture> khi bạn có thể:

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Blue ceramic mug beside a notebook">
</picture>

Lazy loading nên hoạt động như thế nào trên thiết bị di động?

Lazy-load các hình ảnh bắt đầu bên dưới viewport đầu tiên. Không lazy-load hình ảnh LCP. Lazy loading cấp trình duyệt rất hữu ích, nhưng bản thân nó không phải là một kế hoạch hiệu suất.

Hướng dẫn lazy loading cấp trình duyệt của Google khuyến nghị sử dụng loading="lazy" gốc cho các hình ảnh ngoài màn hình. Hướng dẫn tương tự cảnh báo chống lại việc lazy-load các hình ảnh hiển thị ngay lập tức vì nó có thể làm chậm nội dung người dùng đang chờ đợi.

Sử dụng danh sách kiểm tra này:

1. Gán loading="eager" hoặc bỏ qua thuộc tính loading cho hình ảnh hero.
2. Thêm fetchpriority="high" vào hình ảnh LCP có khả năng nhất.
3. Thêm loading="lazy" vào các hình ảnh sau màn hình đầu tiên.
4. Đặt width và height trên mọi hình ảnh.
5. Sử dụng CSS aspect-ratio khi tỷ lệ hiển thị thay đổi theo breakpoint.
6. Tránh chèn hình ảnh chỉ bằng JavaScript cho hero.
7. Kiểm tra rằng URL hình ảnh CDN bao gồm các header cache dài.
8. Thử nghiệm trên hồ sơ di động bị giới hạn băng thông (throttled mobile profile), không chỉ Wi-Fi desktop.
9. Theo dõi phần tử LCP trong PageSpeed Insights.
10. Chạy lại sau khi thay đổi thiết kế, vì phần tử LCP có thể thay đổi.

Tài liệu LCP của Google liệt kê các yếu tố hình ảnh, poster video và hình nền là các ứng viên LCP khả thi. Đó là lý do tại sao một hero nền vẫn có thể làm giảm LCP ngay cả khi nó không phải là thẻ <img>.

Image CDN nên làm gì cho thiết bị di động?

Một image CDN nên loại bỏ công việc thủ công lặp đi lặp lại: thay đổi kích thước ở biên (edge), đàm phán format, lưu cache các biến thể và giữ URL công khai ổn định. CDN không thay thế vệ sinh nguồn gốc (source hygiene). Tải lên một bức ảnh sản phẩm 900 px bị mờ lên image CDN sẽ không tạo ra chi tiết 1600 px thực tế.

Tìm kiếm các điều khiển sau:

• Biến đổi độ rộng cho các slot di động và desktop phổ biến.
• Đầu ra WebP và AVIF với Content-Type chính xác.
• Các khóa cache bao gồm độ rộng, chất lượng và format.
• Một cách để bảo toàn các bản tải lên gốc riêng biệt với các phái sinh công khai.
• URL công khai ổn định mà Google Images có thể thu thập dữ liệu.
• Giám sát lỗi 404 sau khi triển khai và di chuyển.

Đối với SEO, thực tiễn tốt nhất về SEO hình ảnh của Google nhấn mạnh các hình ảnh hữu ích, hiển thị gần văn bản liên quan, tên file và alt text mô tả, và URL hình ảnh có thể thu thập dữ liệu. Một CDN URL ổn khi nó có thể lập chỉ mục (indexable), ổn định và được tham chiếu từ trang.

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

Kiểm tra trang theo cách mà người dùng di động nhận được nó. Một lần chạy Lighthouse sạch sẽ rất hữu ích, nhưng nó có thể che giấu các lỗi CDN, các ứng viên đáp ứng quá khổ, và các dịch chuyển bố cục (layout shifts) chỉ xuất hiện trong các mẫu thực tế.

Một lệnh thực tế cho kiểm toán cục bộ (local audit):

curl -I https://cdn.example.com/images/product-card-480.webp

Sau đó kiểm tra trang đã hiển thị ở viewport hẹp. Nếu một bảng hoặc hình ảnh tràn màn hình, hãy sửa bố cục trước khi ăn mừng việc tiết kiệm byte.

Danh sách kiểm tra SEO và GEO hình ảnh di động

Các công cụ tìm kiếm và công cụ trả lời cần thứ mà con người cần: ngữ cảnh trực tiếp. Đừng chôn vùi hình ảnh trong một carousel không có giải thích gần đó và mong đợi tài sản tự mang ý nghĩa.

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

1. Trang có một câu trả lời rõ ràng ở gần phía trên.
2. Mỗi hình ảnh quan trọng đều có alt text mô tả.
3. Tên file mô tả chủ thể hiển thị, chứ không phải IMG_9021.
4. URL hình ảnh có thể thu thập dữ liệu mà không cần cookie.
5. Đoạn văn xung quanh giải thích tại sao hình ảnh đó tồn tại.
6. Hero di động không lớn hơn slot hiển thị cần thiết.
7. Hình ảnh nội dung sử dụng loading="lazy" chỉ khi nằm dưới viewport đầu tiên.
8. Bảng tóm tắt các quyết định mà người đọc có thể tái sử dụng.
9. Các tuyên bố bên ngoài liên kết đến nguồn đáng tin cậy.
10. Liên kết nội bộ trỏ đến quy trình làm việc thực tế tiếp theo, chứ không phải một trang cụm ngẫu nhiên.

Đối với lần kiểm tra SEO sau khi nén, hãy sử dụng danh sách kiểm tra tối ưu hóa SEO hình ảnh. Đối với công việc file đơn lẻ, Image Compressor, Image Converter, và Image Resizer bao gồm các bước thủ công phổ biến.

Tín dụng hình ảnh

• Biểu đồ độ rộng đáp ứng, biểu đồ cắt art-direction và biểu đồ ưu tiên tải đã được tạo cho bài viết này bằng ImageMagick và xuất dưới dạng WebP. Biểu đồ độ rộng đáp ứng sử dụng đầu ra WebP q82 được đo từ cùng một đồ họa nguồn 1600 x 1000.