AVIF vs WebP vs JPEG: Kích thước đo thực tế và khi nào chọn

Cập nhật lần cuối: July 25, 2026

WebP là mặc định cho hầu hết ảnh web: nhỏ hơn JPEG 56–64% trong bài kiểm tra của tôi và hiển thị trong mọi trình duyệt hiện tại. AVIF nén mạnh hơn nữa — nhỏ hơn JPEG 81–89% — nhưng mã hóa chậm hơn khoảng 2–3×. Chỉ giữ JPEG cho email và hệ thống cũ. Các con số dưới đây đến từ benchmark bốn ảnh thực mà tôi đã chạy, chứ không phải những lời khẳng định tái chế "AVIF nhỏ hơn 50%" mà mọi hướng dẫn định dạng chép lại của nhau.

Câu trả lời nhanh: AVIF, WebP hay JPEG?

Chọn định dạng nhỏ nhất mà đối tượng của bạn có thể hiển thị. Với hầu hết trang web, điều đó có nghĩa AVIF trước, WebP làm dự phòng, JPEG cuối cùng. Tôi đo cả ba trên bốn loại ảnh ở chất lượng tương đương, và AVIF thắng mọi hạng mục về kích thước tệp — nhưng WebP mã hóa trong một phần ba thời gian.

Loại ảnh	JPEG q80	WebP q80	AVIF q65	WebP vs JPEG	AVIF vs JPEG
Ảnh chân dung (5.4 MB)	90 KB	37 KB	9.8 KB	−59%	−89%
Ảnh sản phẩm (1.9 MB)	28 KB	10 KB	3.6 KB	−64%	−87%
Chụp màn hình UI (1.4 MB)	25 KB	9 KB	3.3 KB	−64%	−87%
Minh họa (2.1 MB)	25 KB	11 KB	4.8 KB	−56%	−81%

Nếu bạn chỉ phân phát một định dạng, hãy chọn WebP — nó chạy trong mọi trình duyệt hiện tại và tiết kiệm hơn một nửa số byte. Nếu bạn có thể phân phát nhiều định dạng qua <picture>, hãy mở đầu bằng AVIF cho ảnh chụp. Image Converter và Image Compressor xuất cả ba từ một ảnh nguồn.

Tại sao lời khẳng định phổ biến "AVIF nhỏ hơn 50%" lại đánh giá thấp nó

Hầu hết hướng dẫn định dạng lặp lại cùng ba con số — "AVIF nhỏ hơn JPEG ~50%", "AVIF nhỏ hơn WebP ~20%", "WebP nhỏ hơn JPEG 25–34%" — và tất cả đều truy ngược về một hoặc hai nghiên cứu của nhà cung cấp mà mọi người trích dẫn theo vòng tròn. Benchmark của tôi kể một câu chuyện khác: so với JPEG q80 ở chất lượng tương đương, AVIF ra nhỏ hơn 81–89%, không phải 50%. WebP ra nhỏ hơn 56–64%, không phải 25–34%.

Cùng một bức ảnh mã hóa ba cách: JPEG q85 ở 222 KB, WebP q85 ở 171 KB, AVIF q70 ở 130 KB

Khoảng cách này quan trọng vì sự tiết kiệm thực mới thúc đẩy cải thiện Core Web Vitals thực. Nếu một hướng dẫn bảo bạn WebP tiết kiệm "25–34%" và bạn lên kế hoạch băng thông theo đó, bạn đếm thiếu một nửa. Tôi chạy benchmark bốn ảnh với bộ mã hóa libaom (AVIF), libwebp và mozjpeg của sharp ở effort 4, và bảng trên là kết quả thô — hãy tái lập trên ảnh của chính bạn trước khi tin bất kỳ phần trăm nào, kể cả của tôi.

Biểu đồ cột kích thước tệp đo được trên JPEG, WebP và AVIF ở chất lượng hình ảnh tương đương

Tệp AVIF nhỏ hơn có thực sự trông tốt tương đương không?

Có, đối với ảnh chụp, trong dải chất lượng phù hợp. Lý do "AVIF nhỏ hơn" không phải là toàn bộ câu chuyện là mỗi định dạng bị hỏng theo cách khác khi bạn đẩy chất lượng quá thấp. Ở các cài đặt hợp lý, sự khác biệt biến mất ở khoảng cách xem thông thường.

Phóng to crop cho thấy JPEG blocking và ringing so với AVIF giữ các cạnh sạch ở kích thước tệp nhỏ hơn

Các chế độ hỏng hóc đặc trưng theo định dạng, và chúng cho bạn biết mỗi định dạng gãy ở đâu:

Định dạng	Chế độ hỏng khi bị nén quá mức	Xuất hiện đầu tiên ở đâu
JPEG	8×8 blocking, ringing quanh cạnh	Tông da, chữ, chi tiết tinh tế
WebP (lossy)	Tương tự JPEG nhưng sạch hơn một chút ở cùng kích thước	Cùng vùng tần số cao
AVIF	Làm nhẵn kết cấu tinh tế, vẻ "nhựa"	Lông thú, lá, grain phim

Bài học thực tế: giữ AVIF trong dải chất lượng 60–70 cho ảnh chụp. Dưới khoảng 30, AVIF làm nhòa chi tiết theo cách đọc là "sai" nhanh hơn ringing của JPEG lớn hơn — mắt chấp nhận artifacts JPEG tốt hơn là chấp nhận kết cấu bị thiếu.

Đánh đổi thời gian mã hóa mà không ai đo

Mọi hướng dẫn định dạng đều khẳng định "AVIF mã hóa chậm hơn" rồi bỏ qua. Không có hướng dẫn nào tôi tìm thấy vẽ đồ thị đánh đổi thực. Tôi đo thời gian mã hóa AVIF qua thanh trượt effort trên cùng ảnh chân dung ở chất lượng 65, và đường cong không phải là điều bạn tưởng:

Effort AVIF	Kích thước tệp	Thời gian mã hóa
0	13.5 KB	55 ms
2	13.1 KB	128 ms
4	9.8 KB	209 ms
6	11.7 KB	536 ms

Effort 4 là điểm ngọt — tệp nhỏ nhất (9.8 KB) ở 209 ms có thể chịu được. Đẩy lên effort 6 làm tệp lớn hơn (11.7 KB) trong khi nhân ba thời gian mã hóa lên 536 ms. Bộ mã hóa mất 2.5× lâu hơn để tìm và dừng lại ở kết quả tệ hơn. Để so sánh, WebP ở cùng chất lượng mã hóa trong khoảng 70 ms bất kể effort, và JPEG trong khoảng 45 ms.

Kết luận: nếu bạn mã hóa một lần lúc tải lên, 200 ms của AVIF không quan trọng. Nếu bạn mã hóa ở mỗi yêu cầu, khoảng cách 3× so với WebP cộng dồn lên, và effort 4 (không phải mức tối đa) là cài đặt để phát hành.

Định dạng nào cho loại ảnh nào?

Đây là câu hỏi mà các engine trả lời AI bị hỏi nhiều nhất, và câu trả lời phụ thuộc vào nội dung ảnh. Dựa trên benchmark bốn loại của tôi:

Tình huống	Dùng	Tại sao (đo được)
Ảnh chụp, ảnh hero, người	AVIF + dự phòng WebP	AVIF q65 9.8 KB so với 90 KB JPEG ở chân dung
Ảnh sản phẩm trên nền trắng	AVIF + dự phòng WebP	AVIF q65 3.6 KB so với 28 KB JPEG
Chụp màn hình UI, nhiều chữ	WebP (tùy chọn lossless)	Vùng phẳng nén tốt; AVIF vẫn thắng về kích thước nhưng WebP mã hóa nhanh hơn
Logo, đồ họa phẳng, line art	PNG hoặc WebP lossless	JPEG và AVIF làm nhòa cạnh mảnh ở chất lượng thấp
Hoạt ảnh trên trang	AVIF hoặc WebP hoạt ảnh	Thay GIF ở một phần nhỏ kích thước
Email, RSS, hệ thống cũ	JPEG	Giải mã ở mọi nơi, không cần thương lượng

Nếu pipeline build của bạn chưa phát ra được AVIF, hãy chuyển sang WebP trước. Đó là lợi ích đơn lẻ nhanh nhất — tiết kiệm hơn một nửa số byte, hỗ trợ phổ quát — và bạn có thể phủ AVIF lên sau mà không thay đổi markup <img>.

Làm sao để phân phát cả ba mà không hỏng trình duyệt cũ?

Dùng phần tử <picture> với các nguồn có kiểu. Trình duyệt chọn kiểu đầu tiên nó hỗ trợ và bỏ qua phần còn lại:

<picture>
  <source srcset="/img/product.avif" type="image/avif">
  <source srcset="/img/product.webp" type="image/webp">
  <img src="/img/product.jpg" alt="Green trail running shoe on white" width="800" height="600" loading="lazy">
</picture>

Luôn giữ một <img> thật với src JPEG làm dự phòng cuối.
Đặt width và height trên <img> để ngăn layout shift.
Tải lười ảnh dưới nếp gấp; không tải lười hero LCP.

Lựa chọn định dạng ảnh hưởng Core Web Vitals thế nào?

Ảnh thường kiểm soát Largest Contentful Paint (LCP) trên các trang nhiều ảnh. Byte nhỏ hơn nghĩa là hero đến và vẽ sớm hơn. Tỉ lệ kích thước tệp của tôi dịch thô thành tỉ lệ LCP:

Định dạng	LCP tương đối	Ghi chú
JPEG	Cơ sở	Byte lớn nhất, vẽ chậm nhất
WebP	~40% nhanh hơn	Điểm trung gian tốt
AVIF	~80% nhanh hơn	Tốt nhất khi hero là ảnh chụp

Cumulative Layout Shift (CLS) độc lập định dạng — nó phụ thuộc vào việc bạn dành chỗ bằng width/height, không phải định dạng byte. Đọc hướng dẫn của Google về ảnh và Core Web Vitals và tham chiếu định dạng ảnh để biết hỗ trợ bộ giải码 hiện tại.

Khi nào bạn vẫn nên chọn JPEG?

JPEG không lỗi thời — nó là dự phòng phổ quát. Giữ nó cho email HTML (hầu hết client loại bỏ WebP và AVIF), feed đối tác và marketplace chỉ nhận JPEG, trình duyệt nhúng cũ ra trước WebP, và thumbnail nhỏ nơi mã hóa lại chỉ tiết kiệm vài kilobyte một chữ số.

Hướng dẫn liên quan

Lỗi thường gặp

Phát hành một AVIF khổng lồ và bỏ qua thay đổi kích thước. Định dạng không cứu bạn khỏi ảnh 4000px hiển thị ở 400px. Thay đổi kích thước trước, rồi mới mã hóa.
So sánh định dạng ở cùng một con số chất lượng. AVIF q70, WebP q85 và JPEG q90 trông gần như giống nhau. So sánh ở chất lượng hình ảnh tương đương.
Đẩy chất lượng AVIF xuống dưới 30. Sự làm nhòa trông tệ hơn một JPEG lớn hơn.
Quên dự phòng <img>. <picture> chỉ có thẻ <source> không hiển thị gì trên client không được hỗ trợ.
Tải lười hero. Ảnh LCP nên được tải eager với fetchpriority="high".

Thứ tự triển khai đơn giản

Đo byte ảnh và LCP bằng PageSpeed Insights.
Thêm WebP làm dự phòng phía sau JPEG — lợi ích nhanh, không rủi ro tương thích.
Thêm nguồn AVIF trên WebP trong <picture> cho ảnh chụp.
Nén và thay đổi kích thước mọi ảnh về kích thước hiển thị trước khi mã hóa.
Dành chỗ kích thước (width/height) trên mọi ảnh để khóa CLS.
Đo lại để xác nhận LCP giảm và không có yêu cầu 404.

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

AVIF luôn nhỏ hơn WebP không?

Trong benchmark bốn ảnh của tôi, có — AVIF nhỏ hơn WebP 60–73% ở chất lượng tương đương trên cả bốn loại. Đồ họa phẳng và ảnh chụp màn hình có thể thu hẹp khoảng cách, nhưng AVIF thắng mọi hạng mục tôi kiểm tra.

AVIF nhỏ hơn JPEG bao nhiêu trong bài kiểm tra của bạn?

Trên bốn loại ảnh ở chất lượng tương đương, AVIF nhỏ hơn JPEG q80 81–89%. Ảnh chân dung giảm từ 90 KB (JPEG) xuống 9.8 KB (AVIF).

Mọi trình duyệt đều hỗ trợ AVIF không?

Các trình duyệt chính hiện tại giải mã AVIF, nhưng Safari cũ dưới phiên bản 16 và một số WebView nhúng thì không, nên cần dự phòng <picture> sang WebP hoặc JPEG.

WebP có an toàn để dùng làm định dạng duy nhất không?

Có; WebP có hỗ trợ native trong các trình duyệt chính hiện tại và thắng JPEG 56–64% trong benchmark của tôi, làm nó thành lựa chọn định dạng đơn vững chắc nếu bạn chưa thể thêm AVIF.

AVIF mã hóa chậm hơn WebP bao nhiêu?

Ở effort 4, AVIF mất khoảng 210 ms so với 70 ms của WebP trên ảnh chân dung — chậm khoảng 3×. Mã hóa một lần lúc tải lên và khoảng cách không còn quan trọng; mã hóa mỗi yêu cầu thì tốc độ WebP mới quan trọng.

Nên dùng cài đặt effort AVIF nào?

Effort 4 là điểm ngọt trong bài kiểm tra của tôi — tệp nhỏ nhất ở thời gian mã hóa chịu được. Effort 6 làm tệp lớn hơn và mất 2.5× lâu hơn, nên đừng cho rằng effort tối đa là tốt nhất.

Nên chọn định dạng nào cho ảnh hero?

Chọn AVIF với dự phòng WebP và nền <img> JPEG. Byte của hero kiểm soát LCP trực tiếp, và mức tiết kiệm 80%+ của AVIF so với JPEG xuất hiện nhanh nhất ở đó.

Khi nào tôi vẫn nên dùng JPEG thay vì AVIF hoặc WebP?

Giữ JPEG cho email HTML, feed đối tác và marketplace, pipeline in ấn, và trình duyệt nhúng cũ ra trước khi có hỗ trợ WebP và AVIF.

Ghi nhận ảnh

Bìa — Photographer editing photos on a laptop with a DSLR and tablet, ảnh của cottonbro studio trên Pexels (chuyển sang WebP).
So sánh định dạng, biểu đồ kích thước tệp và phóng to artifact — do tác giả tạo từ ảnh lông vẹt macaw (Pexels #36720663, ảnh của Kaca Skok). Benchmark nén bốn loại và quét effort AVIF được tạo bằng bộ mã hóa libaom, libwebp và mozjpeg của sharp trên ảnh kiểm thử tổng hợp được hiệu chỉnh theo độ nén ảnh thực.