Cùng một tấm ảnh, AVIF thường nhẹ hơn WebP đáng kể — và ảnh nhẹ là một trong những đòn bẩy mạnh nhất để kéo LCP (Largest Contentful Paint — thời điểm phần tử lớn nhất hiện ra) về ngưỡng tốt. Nhưng “nhẹ hơn” không phải là toàn bộ câu chuyện: encode chậm, hỗ trợ trình duyệt, và cách fallback mới quyết định bạn nên chọn gì. Bài này mổ xẻ từng tiêu chí để bạn ra quyết định đúng cho dự án của mình.
Hai định dạng này khác nhau ở đâu
WebP do Google phát triển, ra mắt từ 2010, dựa trên kỹ thuật nén của video VP8/VP9. AVIF (AV1 Image File Format) mới hơn, lấy lõi nén từ codec video AV1 — vốn được thiết kế để vượt qua các định dạng cũ. Cả hai đều hỗ trợ ảnh có kênh trong suốt (alpha) và ảnh động, nên về mặt tính năng chúng đủ thay thế cả PNG lẫn GIF cho hầu hết trường hợp.
Điểm mấu chốt: AVIF dùng thuật toán nén thế hệ mới hơn, nên ở cùng mức chất lượng cảm nhận, file thường nhỏ hơn. Đổi lại, bộ mã hoá (encoder) phải làm việc nặng hơn nhiều, dẫn tới thời gian encode dài hơn hẳn.
Bảng so sánh WebP vs AVIF (2026)
| Tiêu chí | WebP | AVIF |
|---|---|---|
| Mức nén (so JPEG) | Nhỏ hơn ~25–30% | Nhỏ hơn ~50–60% |
| Nén so với nhau | Cơ sở | Nhỏ hơn WebP ~20–35% ở cùng chất lượng |
| Thời gian encode | Nhanh | Chậm hơn ~5–10 lần (tuỳ effort) |
| Hỗ trợ trình duyệt (toàn cầu) | ~96–97% | ~93–95% |
| Kênh trong suốt (alpha) | Có | Có |
| HDR / dải màu rộng (10-bit, wide gamut) | Hạn chế | Có |
| Ảnh động | Có | Có (ít công cụ hỗ trợ hơn) |
| Hợp nhất cho | Ảnh nội dung số lượng lớn, build nhanh | Ảnh hero, ảnh nặng cần kéo LCP |
Các con số trên là khoảng tham chiếu tổng hợp từ tài liệu Google và đo đạc cộng đồng năm 2026; kết quả thực tế dao động theo nội dung ảnh (ảnh nhiều chi tiết phẳng AVIF thắng đậm; ảnh nhiễu hạt thì khoảng cách hẹp lại). Theo web.dev, AVIF tiết kiệm khoảng 60% so với JPEG và 35% so với WebP — nhưng hãy đo trên chính bộ ảnh của bạn thay vì tin một con số duy nhất.
Mức nén và chất lượng — nhìn kỹ hơn
Ở vùng chất lượng trung bình tới cao (quality 50–80), AVIF gần như luôn ra file nhỏ hơn WebP mà mắt thường khó phân biệt. AVIF cũng xử lý vùng chuyển màu mượt (gradient bầu trời, đổ bóng) tốt hơn — WebP đôi khi để lại dải màu (banding) ở những vùng này. Ngược lại, ở ảnh rất nhỏ (icon, thumbnail vài KB), phần “chi phí cố định” của container AVIF có thể khiến nó không còn lợi thế, thậm chí nặng hơn WebP. Với ảnh tí hon, WebP hoặc thậm chí PNG tối ưu vẫn hợp lý hơn.
Encode chậm — cái giá thật của AVIF
Đây là điểm dev hay bỏ qua. AVIF encode ở mức nỗ lực cao có thể chậm gấp 5–10 lần WebP. Hệ quả thực tế:
- Build tĩnh / CMS sinh ảnh hàng loạt: nếu bạn convert hàng nghìn ảnh trong CI, AVIF có thể đội thời gian build lên đáng kể. Cân nhắc giảm tham số effort, hoặc chỉ tạo AVIF cho ảnh quan trọng (hero, ảnh đầu trang).
- Ảnh upload động (người dùng đăng ảnh): encode AVIF đồng bộ ngay lúc upload dễ làm nghẽn request. Nên encode nền (background job) hoặc đẩy việc này cho một dịch vụ ảnh tự lo.
WebP gần như miễn phí về chi phí encode trong đa số quy trình, nên nếu hạ tầng của bạn nhạy cảm với thời gian build, đó là lý do chính đáng để chọn WebP làm mặc định.
Hỗ trợ trình duyệt 2026
Tin tốt: cả hai đều đã phổ cập rộng. Tính tới đầu 2026, WebP đạt khoảng 96–97% và AVIF khoảng 93–95% độ phủ toàn cầu. Chrome, Edge, Firefox và Safari (macOS lẫn iOS) đều đọc được AVIF. Khoảng trống còn lại chủ yếu là thiết bị cũ — vài bản Android đời trước và iOS 15 còn sót. Vì vẫn còn vài phần trăm không đọc được AVIF, bạn không nên phục vụ AVIF “trần” mà phải có fallback.
Cách fallback đúng với thẻ <picture>
Trình duyệt sẽ lấy <source> đầu tiên mà nó hiểu được, nên thứ tự phải là AVIF trước, rồi WebP, cuối cùng là <img> JPEG/PNG làm lưới an toàn:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Mô tả ảnh thật"
width="1200" height="630"
loading="eager" fetchpriority="high">
</picture>
Vài lưu ý dễ sai:
- Luôn có
widthvàheighttrên thẻ<img>để trình duyệt giữ chỗ, tránh nhảy layout — đây là cách phòng CLS (Cumulative Layout Shift — điểm xê dịch bố cục tích luỹ). - Ảnh hero (phần tử LCP) nên để
fetchpriority="high"và không lazy-load; ngược lại ảnh nằm dưới màn hình đầu thì đểloading="lazy". - Muốn phục vụ nhiều độ phân giải, kết hợp
srcset+sizestrong từng<source>thay vì chỉ một file.
Phần lớn plugin CMS và dịch vụ ảnh hiện đại tự sinh khối <picture> này, bạn không phải viết tay mỗi ảnh. Nếu dùng một tối ưu hiệu năng web bài bản, việc dò định dạng theo header Accept của trình duyệt (content negotiation) còn gọn hơn nữa — server tự trả AVIF cho trình duyệt đọc được mà không cần đổi HTML.
Vậy nên chọn cái nào
- Chọn AVIF cho ảnh nặng, ảnh hero, ảnh nhiều gradient — nơi mỗi KB tiết kiệm được kéo thẳng LCP xuống. Nhớ có fallback WebP/JPEG.
- Chọn WebP làm mặc định nếu bạn cần build nhanh, xử lý ảnh upload động, hoặc chỉ muốn chuẩn hoá một định dạng duy nhất với độ phủ trình duyệt nhỉnh hơn.
- Lý tưởng là cả hai: AVIF first, WebP fallback, JPEG cuối — đúng cách web22.dev đang vận hành. Trình duyệt mới nhận file nhỏ nhất, trình duyệt cũ vẫn xem được ảnh.
Sau khi đổi định dạng, đừng quên hai khâu liền kề: lazy-load ảnh dưới màn hình đầu để không tải sớm thứ chưa cần, và cân nhắc đẩy ảnh qua image CDN tối ưu ảnh tự động để khỏi tự gánh khâu encode AVIF chậm.
Câu hỏi thường gặp
AVIF có thay hẳn WebP được chưa?
Chưa nên thay hẳn. AVIF nén tốt hơn nhưng vẫn còn vài phần trăm trình duyệt cũ không đọc được, nên giữ WebP/JPEG làm fallback là an toàn nhất.
Đổi sang AVIF có giúp tăng điểm PageSpeed không?
Có thể, nếu ảnh là phần tử LCP và đang nặng. Ảnh nhẹ hơn giúp LCP nhanh hơn. Nhưng hãy đo bằng Lighthouse hoặc PageSpeed Insights trước và sau, vì kết quả tuỳ ảnh.
Ảnh icon nhỏ có nên dùng AVIF không?
Thường không đáng. Với ảnh vài KB, AVIF có thể không nhỏ hơn WebP do chi phí cố định của container; WebP hoặc PNG tối ưu là đủ.