AVIF vs WebP vs JPG: Màn so găng các định dạng ảnh hiện đại
Vì sao cuộc so găng này thực sự đáng quan tâm
Đừng nhầm lẫn định dạng ảnh chỉ là lựa chọn về mặt thẩm mỹ. Không phải vậy đâu. Chỉ một định dạng được chọn sai trên trang sản phẩm có lưu lượng truy cập cao có thể cộng thêm 200–400 KB cho mỗi ảnh. Điều này cộng dồn thành vài giây tải trang lâu hơn và làm sụt giảm tỷ lệ chuyển đổi một cách rõ rệt. Core Web Vitals của Google phạt thẳng tay các điểm số Largest Contentful Paint (LCP) chậm, và hình ảnh thường là thủ phạm chính. Việc lựa chọn giữa AVIF, WebP, và JPG có hậu quả thực sự đối với SEO, hóa đơn băng thông, và việc người dùng có ở lại trang hay không. JPG đã thống trị nhiếp ảnh từ giữa những năm 90. Nó hoạt động ở mọi nơi, mã hóa nhanh, và mọi lập trình viên đều biết cách xử lý nó. WebP của Google ra mắt năm 2010 như một sự thay thế, hứa hẹn khả năng nén tốt hơn với cùng chất lượng. Tân binh là AVIF, được chuẩn hóa vào năm 2019 bởi Alliance for Open Media. Nó đẩy khả năng nén đi xa hơn nữa bằng cách mượn công nghệ từ codec video AV1. Mục tiêu ở đây không phải là tuyên bố một định dạng nào là kẻ chiến thắng. Điều đó thật vô nghĩa. Mục tiêu là để hiểu rõ những đánh đổi cụ thể để bạn có thể đưa ra quyết định đúng đắn cho dự án *của bạn*, chứ không chỉ làm theo một vài lời khuyên lỗi thời từ năm 2021. Chúng ta sẽ phân tích khả năng nén trong thực tế, hỗ trợ trình duyệt, và các chi phí ẩn như tốc độ mã hóa, giúp bạn có đủ bối cảnh để sử dụng mỗi định dạng một cách hiệu quả—và biết khi nào cần phải chuyển đổi định dạng.
Hiệu suất nén: Những con số đằng sau lời đồn
Đúng vậy, các định dạng hiện đại nhỏ hơn đáng kể so với JPG. Phần này của lời đồn là sự thật. Nhưng nhỏ hơn bao nhiêu còn phụ thuộc vào hình ảnh, bộ mã hóa, và chất lượng bạn đang hướng tới. Đối với một bức ảnh thông thường, WebP thường nhỏ hơn 25–35% so với file JPG có chất lượng hình ảnh tương đương. AVIF còn đi xa hơn nữa, thường đạt mức nhỏ hơn 40–55% so với JPG, tức là nhỏ hơn khoảng 15–25% so với WebP. Điều đó có nghĩa là một bức ảnh sản phẩm 180 KB (JPG, chất lượng 85) có thể trở thành file WebP 120 KB hoặc file AVIF 90 KB. Việc tiết kiệm là có thật. Nhưng bạn không thể chỉ so sánh các con số chất lượng giữa các định dạng. Chúng không tương đương nhau. Một file JPG "chất lượng 85" không giống với một file WebP "chất lượng 85". Giảm chất lượng file JPG từ 85 xuống 75 trong ImageMagick có thể cắt giảm đáng kể kích thước file, nhưng nó cũng sẽ tạo ra các khối vỡ (artifact) dạng ô vuông ở những vùng chuyển màu và bầu trời. WebP sử dụng thang điểm 0–100, trong đó 80 là một điểm khởi đầu tốt, gần tương đương với JPG 85. AVIF sử dụng thang điểm Constant Rate Factor (CRF), thường từ 0–63, trong đó số càng thấp càng tốt. Đối với ảnh web, CRF từ 30–40 thường là mức tối ưu. Câu chuyện lại khác đối với các loại đồ họa như ảnh chụp màn hình UI, logo, hay infographic. PNG vốn là lựa chọn hàng đầu nhờ chất lượng không mất dữ liệu (lossless), nhưng chế độ lossless của WebP luôn tạo ra các file nhỏ hơn 20–30%. Chế độ lossless của AVIF chưa hoàn thiện bằng và đôi khi có thể tạo ra các file *lớn hơn* so với WebP lossless cho loại nội dung này. Đừng cho rằng AVIF luôn chiến thắng ở mọi mặt. Nhóm Squoosh tại Google đã thực hiện các bài kiểm tra và xác nhận ưu thế chung của AVIF về khả năng nén, nhưng họ cũng phát hiện ra rằng lợi thế này bị thu hẹp khi bạn làm việc với các ảnh nguồn đã được nén rất nhiều. Nếu bạn đang chuyển đổi lại một đống file JPG cũ thay vì làm việc từ các file gốc chất lượng cao, bạn sẽ thấy hiệu quả giảm dần. Đầu vào là rác thì đầu ra cũng chỉ là rác nhỏ hơn một chút.
Hỗ trợ trình duyệt và nền tảng: Mọi thứ trở nên phức tạp
Nói thẳng luôn: JPG được hỗ trợ khắp mọi nơi. Mọi trình duyệt, hệ điều hành, trình xem ảnh, CMS, CDN, và trình duyệt email đều xử lý được nó. Đừng đánh giá thấp lợi thế đó; đó là một mức độ phổ biến mà các định dạng mới hơn đơn giản là chưa thể sánh kịp. Đối với việc sử dụng trên web, hỗ trợ WebP giờ đã rất tuyệt vời. Tính đến năm 2024, mọi trình duyệt lớn—Chrome, Firefox, Safari (từ phiên bản 14), Edge, Opera—đều đã hỗ trợ. Tỷ lệ hỗ trợ toàn cầu là hơn 97% trên caniuse.com. Những trường hợp duy nhất còn sót lại là các phiên bản Safari cổ trên iOS 13 trở xuống, điều này có thể không phải là vấn đề với đối tượng người dùng của bạn. Hỗ trợ AVIF cũng tốt, nhưng bạn cần phải cẩn thận hơn. Chrome đã hỗ trợ từ phiên bản 85 (2020), Firefox từ 93 (2021), và Safari cuối cùng cũng tham gia với phiên bản 16 (2022). Điều này bao phủ hầu hết người dùng, nhưng bạn vẫn có thể gặp trục trặc với Edge trên các bản build Windows 10 cũ hoặc một số Android WebView nhất định. Tỷ lệ hỗ trợ toàn cầu dao động quanh mức 93-95%. Nghe có vẻ tuyệt vời, nhưng đối với một trang web có lưu lượng truy cập cao, 5-7% người dùng nhận được ảnh lỗi là một vấn đề rất thực tế. Ngoài trình duyệt, mọi thứ trở nên phức tạp. Đối với các ứng dụng desktop, ứng dụng di động, hoặc email, hỗ trợ rất chắp vá. macOS đã hỗ trợ AVIF từ Ventura (13.0). Windows 11 hỗ trợ nó, nhưng Windows 10 cần một codec từ Microsoft Store. Android đã hỗ trợ từ phiên bản 12, và iOS từ phiên bản 16. Tất cả điều này không thành vấn đề nếu bạn đang sử dụng thẻ HTML `<picture>` với các phương án dự phòng (fallback) phù hợp, nhưng nó là một cơn đau đầu thực sự nếu bạn muốn người dùng tự download và mở các file này. Chiến lược hợp lý duy nhất cho một trang web sản phẩm là phân phát ảnh theo tầng: AVIF trước tiên, sau đó là WebP làm dự phòng, và cuối cùng là JPG cho tất cả các trường hợp còn lại. Bạn có thể triển khai điều này bằng cách sử dụng các thẻ `source` với thuộc tính `type` của thẻ `<picture>`, hoặc bằng cách kiểm tra header `Accept` trên máy chủ của bạn. Đừng chỉ phân phát AVIF rồi cầu mong mọi chuyện tốt đẹp.
Tốc độ mã hóa và công cụ: Chi phí ẩn
Có một chi phí ẩn đằng sau khả năng nén đáng kinh ngạc của AVIF: thời gian. Mã hóa AVIF chậm một cách tàn bạo so với JPG hoặc WebP, và điều đó có những hậu quả thực tế đối với quy trình làm việc của bạn. Hãy xem các con số. Mã hóa một bức ảnh 2000×1500 sang JPG (chất lượng 85, libjpeg-turbo) có thể mất 50-80 mili giây trên một máy tính hiện đại. Cùng một ảnh đó sang WebP (chất lượng 80, libwebp) mất 200-400 mili giây. Nhưng mã hóa sang AVIF (CRF 32, tốc độ 6) có thể mất từ 2 đến 8 *giây*. Và nếu bạn đẩy bộ mã hóa lên cài đặt chậm nhất, chất lượng cao nhất, bạn có thể phải đợi 30 giây hoặc hơn cho một tấm ảnh duy nhất. Đối với một lô 500 ảnh sản phẩm, đó là sự khác biệt giữa một giờ giải lao uống cà phê 5 phút và một cuộc chờ đợi 4 tiếng đồng hồ. Nếu bạn đang tạo ảnh một cách nhanh chóng (on-the-fly), như một số CDN vẫn làm, chi phí mã hóa như vậy có thể gây ra độ trễ không thể chấp nhận được trừ khi hệ thống cache của bạn hoàn hảo. Bộ mã hóa libavif có một thiết lập tốc độ từ 0 (chậm nhất, nén tốt nhất) đến 10 (nhanh nhất, kém nhất). Tốc độ 6 là khuyến nghị tiêu chuẩn, một sự thỏa hiệp hợp lý giữa kích thước file và sự tỉnh táo của chính bạn. Tốc độ 10 gần như nhanh bằng WebP, nhưng bạn sẽ hy sinh rất nhiều lợi thế nén của AVIF. CocoConvert xử lý sự phức tạp này cho bạn trên máy chủ, nhưng các quy luật vật lý vẫn được áp dụng: các lô chuyển đổi AVIF lớn sẽ mất nhiều thời gian hơn đáng kể so với các tác vụ WebP hoặc JPG. Nếu bạn đang vội, WebP thường là lựa chọn thực tế hơn, ngay cả khi AVIF có thể tiết kiệm thêm vài kilobyte. Hệ sinh thái công cụ cho WebP đã trưởng thành và ổn định; cwebp, Squoosh, ImageMagick, và thư viện Sharp của Node.js đều có hỗ trợ mạnh mẽ. Công cụ cho AVIF đang dần bắt kịp—Sharp đã thêm hỗ trợ trong v0.27.0 và ImageMagick sử dụng libheif—nhưng bất kỳ ai đã từng phải vật lộn với các vấn đề phụ thuộc thư viện đều biết rằng "bắt kịp" có thể đồng nghĩa với việc gặp phải các lỗi lạ và xung đột phiên bản mà đơn giản là không tồn tại trong thế giới của JPG và WebP.
Chất lượng ảnh ở bitrate thấp: Nơi các định dạng khác biệt nhất
Ở cài đặt chất lượng cao, hầu hết các ảnh nén đều trông đẹp mắt. Bài kiểm tra thực sự đến ở bitrate thấp, khi bạn đang cố gắng vắt kiệt từng byte cuối cùng ra khỏi một file. Đây là lúc các định dạng thực sự thể hiện bản chất của mình, và sự khác biệt là rất rõ ràng. Nén JPG nặng nổi tiếng với các khối vỡ dạng ô vuông. Ở chất lượng 40-50, các vùng chuyển màu mượt mà trên bầu trời xanh bị vỡ thành một mảng chắp vá các ô vuông. Văn bản có một quầng mờ, nhiễu xung quanh. Tất cả chúng ta đều đã thấy chúng, và chúng rất xấu. WebP, ở cùng kích thước file thấp, có xu hướng làm mờ thay vì tạo khối. Nó làm mịn các chi tiết nhỏ. Đây có thể là một hiệu ứng dễ chịu hơn đối với ảnh chân dung, nơi sự mờ ảo trông tự nhiên hơn các khối vuông thô kệch của JPG. Tuy nhiên, đối với các hình ảnh có đường nét sắc sảo hoặc văn bản, chính sự mờ ảo đó lại có thể là một nhược điểm lớn. Đây là lúc AVIF thực sự tỏa sáng. Ở bitrate thấp, nó đè bẹp hai định dạng còn lại. Bộ mã hóa dựa trên AV1 của nó đơn giản là tốt hơn trong việc bảo toàn chi tiết và xử lý các vùng chuyển màu một cách mượt mà. Một ảnh AVIF 50 KB trông sạch sẽ hơn hẳn so với một ảnh WebP hoặc JPG cùng kích thước. Lợi thế thực sự của AVIF không nằm ở chất lượng 90, nơi mọi thứ đều ổn; nó nằm ở chất lượng 50-60, nơi bạn đang đẩy đến giới hạn. Các chỉ số đo lường cảm nhận (perceptual metrics) cũng chứng minh điều này. Một bức ảnh phong cảnh 1200×800 được nén xuống 50 KB có thể đạt điểm DSSIM là 0.008 cho JPG, 0.005 cho WebP, và 0.003 cho AVIF (càng thấp càng tốt). Đó không chỉ là những con số; chúng đại diện cho những cải tiến có thể nhìn thấy được. Nếu bạn có ngân sách kích thước file eo hẹp, AVIF sẽ luôn cho bạn hình ảnh trông đẹp nhất. Có một ngoại lệ: các hạt nhiễu phim (film grain) mịn hoặc các vân tự nhiên. Bộ mã hóa của AVIF có thể quá tích cực trong việc làm mịn các chi tiết này, dẫn đến một vẻ ngoài hơi nhân tạo, như nhựa trong một số ảnh chụp ISO cao. Luôn kiểm tra trên ảnh của chính bạn; đừng cho rằng AVIF là viên đạn bạc cho mọi loại nội dung.
Các trường hợp sử dụng thực tế: Chọn định dạng phù hợp với mục đích
Lý thuyết thì hay đấy, nhưng bạn nên thực sự sử dụng mỗi định dạng ở đâu? Đây là hướng dẫn thực tế cho các tình huống phổ biến. **Ảnh Hero & Ảnh sản phẩm trên website:** Hãy chọn AVIF, dự phòng bằng WebP, rồi đến JPG. Bạn kiểm soát môi trường, vì vậy bạn có thể sử dụng thẻ `<picture>` để phân phát định dạng tốt nhất. Việc tiết kiệm băng thông là rất lớn. Một công cụ như CocoConvert có thể chuyển đổi hàng loạt các file gốc JPG của bạn sang cả AVIF và WebP để làm việc này trở nên dễ dàng. **Ảnh trong Email:** JPG. Chấm hết. Các trình duyệt email là một vùng đất hoang của việc hiển thị không nhất quán. Cả AVIF và WebP đều không có hỗ trợ đáng tin cậy trong Outlook, Apple Mail, hay Gmail. Gửi một file WebP sẽ chỉ hiển thị một ảnh lỗi cho một phần lớn khán giả của bạn. **Tải ảnh lên mạng xã hội:** Hãy dùng JPG chất lượng cao. Mọi nền tảng (Instagram, Twitter/X, Facebook) sẽ mã hóa lại ảnh của bạn bất kể bạn tải lên cái gì. Hãy cung cấp cho bộ mã hóa của họ nguồn tài liệu tốt nhất có thể; việc tải lên một file AVIF đã được nén sẵn không mang lại lợi ích gì cho bạn. **In ấn hoặc lưu trữ:** Không dùng cái nào cả. Hãy sử dụng định dạng không mất dữ liệu như TIFF hoặc PNG cho các file gốc của bạn. Nếu bạn phải gửi một bản xem trước đã nén, một file JPG chất lượng cao (90-95) là tiêu chuẩn phổ quát mà bất kỳ cửa hàng in ấn hay biên tập viên nào cũng có thể mở được. **Tài nguyên trong ứng dụng di động:** Tùy thuộc vào phiên bản hệ điều hành tối thiểu bạn nhắm đến. Nếu bạn đang xây dựng cho Android 12+ và iOS 16+, AVIF là một lựa chọn tuyệt vời. Để hỗ trợ rộng hơn, WebP là lựa chọn an toàn hơn, hoạt động từ Android 4.0 và iOS 14. **Nội dung trên CMS:** Hãy thận trọng với AVIF. Khi những người dùng không chuyên về kỹ thuật đang tải ảnh lên, bạn muốn có một quy trình làm việc đáng tin cậy nhất. Nhiều thư viện media và trình tạo thumbnail của CMS vẫn chưa xử lý AVIF đúng cách. JPG và WebP thực tế hơn nhiều và ít có khả năng gây ra các ticket hỗ trợ về việc xem trước ảnh bị lỗi.
Cách chuyển đổi giữa các định dạng này (và những điều cần lưu ý)
Chuyển đổi giữa các định dạng này rất dễ dàng với các công cụ phù hợp, nhưng một vài cái bẫy có thể phá hỏng các tác vụ hàng loạt của bạn nếu bạn không cẩn thận. Quy tắc vàng khi chuyển đổi: luôn bắt đầu từ nguồn có chất lượng cao nhất. Chuyển đổi một file JPG sang AVIF không thần kỳ khôi phục lại chi tiết mà việc nén JPG đã phá hủy. Nó chỉ gói dữ liệu đã suy giảm chất lượng đó trong một định dạng mới. Nếu bạn có file gốc RAW hoặc TIFF, hãy sử dụng chúng. Nếu tất cả những gì bạn có là một file JPG, việc chuyển nó sang AVIF sẽ làm cho file nhỏ hơn, nhưng nó sẽ không làm cho hình ảnh trông đẹp hơn. Sử dụng một công cụ như CocoConvert giúp đơn giản hóa quy trình: tải lên, chọn định dạng, và tải xuống. Các cài đặt chất lượng mặc định cho việc chuyển từ JPG sang WebP được tinh chỉnh để duy trì chất lượng hình ảnh. Đối với việc chuyển từ JPG sang AVIF, các cài đặt mặc định tạo ra sự cân bằng giữa kích thước file và chất lượng, nhưng bạn nên cân nhắc yêu cầu chất lượng cao hơn cho những hình ảnh sẽ được hiển thị lớn và bị người dùng soi kỹ. Hãy nói thẳng về một hạn chế: CocoConvert không xử lý các định dạng ảnh động. Chuyển đổi WebP động sang AVIF động là một câu chuyện hoàn toàn khác, liên quan đến thời gian khung hình và bảng màu. Đối với việc đó, bạn sẽ cần phải dùng đến một công cụ dòng lệnh như FFmpeg. Hãy cẩn thận với độ trong suốt (transparency). JPG không hỗ trợ nó, chấm hết. Nếu bạn chuyển đổi một file PNG hoặc WebP trong suốt sang JPG, nền sẽ được lấp đầy bằng một màu đặc, thường là trắng hoặc đen. Cả AVIF và WebP đều xử lý tốt độ trong suốt (kênh alpha), vì vậy việc chuyển đổi giữa chúng sẽ bảo toàn được nó. Chỉ cần chắc chắn rằng bạn không vô tình đưa một ảnh trong suốt qua bước chuyển đổi sang JPG trong quy trình của mình. Cuối cùng, một chút thực tế. Trước khi bạn tạo phiên bản AVIF và WebP cho mọi hình ảnh, hãy tự hỏi liệu bạn có thực sự cần cả hai không. Tạo ra hai định dạng sẽ làm tăng gấp đôi thời gian xử lý và dung lượng lưu trữ của bạn. Đối với nhiều trang web, việc chỉ cần chuẩn hóa sang WebP đã là một cải tiến lớn so với JPG và bao phủ hơn 97% người dùng với độ phức tạp thấp hơn nhiều. AVIF rất mạnh mẽ, nhưng chỉ thêm nó vào nếu hóa đơn băng thông của bạn thực sự xứng đáng với công sức bỏ ra.