Hướng dẫn nén ảnh toàn diện: Chọn JPG, PNG hay WebP theo mục đích

Đăng 2026-04-13 8 phút đọc

Tóm tắt (TL;DR)

Cuối tuần trước tôi kéo một bức ảnh mèo JPG gốc 4,2 MB vào Squoosh, xuất sang WebP ở chất lượng 80 và kết quả là 380 KB — giảm tới 91%. Thành thật mà nói, trên màn hình điện thoại tôi không thể phân biệt được bản xuất ra và bản gốc. Đó chính là nén có tổn hao khi nó làm đúng việc của mình. Mỗi lần tôi quên điều này, lại mở một blog nào đó và đợi ba giây để ảnh hero 2 MB trôi xuống qua LTE, bài học đó tự nó lặp lại.

Chọn định dạng ảnh không phải câu hỏi “cái nào tốt nhất” mà là “dùng cho mục đích gì”. Ảnh chụp có tông liên tục phù hợp với các định dạng có tổn hao như JPEG, WebP (có tổn hao) và AVIF. Ở cùng mức chất lượng thị giác, WebP thường nhỏ hơn JPEG khoảng 25–35%, còn AVIF nhỏ hơn JPEG khoảng 40–50% tuỳ tham số encoder. Ngược lại, logo, biểu tượng, ảnh chụp màn hình và bất cứ thứ gì cần cạnh sắc nét hoặc chữ rõ ràng thì các định dạng không tổn hao như PNG, WebP không tổn hao và TIFF an toàn hơn. Nếu cần vừa có độ trong suốt vừa có hoạt ảnh, các lựa chọn chính là WebP, APNG và AVIF. Hỗ trợ trình duyệt tính đến đầu năm 2026 đã rộng: WebP có mặt từ Chrome 32 (2014), Firefox 65 và Safari 14 (cuối 2020), còn AVIF chạy từ Chrome 85 (tháng 8 năm 2020), Firefox 93 (tháng 10 năm 2021) và Safari 16 (tháng 9 năm 2022) trở đi. Đường cơ sở hợp lý là “SVG cho logo vector, WebP hoặc AVIF cho ảnh chụp, PNG cho ảnh chụp màn hình”, cộng với fallback <picture> sang JPEG khi cần hỗ trợ môi trường cũ.

Bối cảnh và khái niệm

Các định dạng có tổn hao như JPEG, WebP (có tổn hao) và AVIF giảm kích thước bằng cách loại bỏ thông tin mà hệ thống thị giác của con người ít nhạy với. Hai kỹ thuật cốt lõi đứng sau việc này. Thứ nhất là lượng tử hoá (quantization), làm tròn các hệ số trong miền tần số và cắt mạnh tay hơn với thành phần tần số cao. Với ảnh chụp có chuyển tông mượt, hiệu ứng này gần như vô hình, nhưng ở các cạnh sắc thì ranh giới khối có thể lộ ra. Thứ hai là chroma subsampling, lưu kênh màu ở độ phân giải thấp hơn kênh độ sáng. Cấu hình 4:4:4 giữ nguyên màu, còn 4:2:0 phổ biến hơn thì giảm một nửa theo cả hai chiều. Mặc định này ổn với ảnh chụp thông thường, nhưng nó có thể làm nhoè cạnh chữ màu — đặc biệt là chữ đỏ hoặc xanh trên nền tối.

JPEG được chuẩn hoá năm 1992, sử dụng biến đổi cosine rời rạc (DCT) dựa trên khối trên các khối pixel 8×8. WebP kế thừa các kỹ thuật khung nội (intra-frame) của codec video VP8, còn AVIF sử dụng bộ công cụ khung nội của AV1. Do đó cả hai hiện đại hơn JPEG đáng kể ở cách dự đoán, biến đổi và lượng tử hoá dữ liệu ảnh, với khối lớn hơn, dự đoán có hướng và mã hoá entropy tốt hơn. PNG thuộc dòng khác hẳn: đây là định dạng không tổn hao dùng họ nén deflate, có hỗ trợ kênh alpha và bảng màu chỉ mục. PNG không loại bỏ dữ liệu, nhưng với nội dung ảnh chụp thì sự “nguyên chất” đó phải trả giá bằng file to hơn nhiều lần.

Một khái niệm liên quan là giải mã lũy tiến (progressive decoding). Progressive JPEG và interlaced PNG cho phép người xem nhìn thấy phiên bản độ phân giải thấp ngay lập tức rồi tinh chỉnh dần khi dữ liệu tiếp tục về. WebP và AVIF thường giải mã một lần qua, nên sự khác biệt chỉ rõ ở ảnh rất lớn hoặc kết nối chậm. SVG, cuối cùng, không phải định dạng raster nén mà là mô tả vector; kích thước file phụ thuộc vào số hình và việc nén chính văn bản (gzip và brotli rất hiệu quả với nguồn SVG).

So sánh và dữ liệu

Định dạngCó tổn haoKhông tổn haoTrong suốtHoạt ảnhNén ảnh chụp điển hìnhHỗ trợ trình duyệt 2025
JPEGCóKhôngKhôngKhôngKhoảng 10:1Mọi trình duyệt
PNGKhôngCóCóMở rộng APNGKhoảng 2–3:1Mọi trình duyệt
WebPCóCóCóCóNhỏ hơn JPEG 25–35%Safari 14 (2020) trở lên, gần như toàn phổ
AVIFCóCóCóCóNhỏ hơn JPEG 40–50%Chrome 85+, Firefox 93+, Safari 16+
GIFCó (palette 256 màu)Không1 bitCóKém cho ảnh chụpMọi trình duyệt

Hãy xem các con số này như xu hướng chung. Kết quả nén thực tế phụ thuộc rất nhiều vào nội dung nguồn, encoder, preset và mức chất lượng mục tiêu. Cùng một bức JPEG ở chất lượng 85 và 60 có thể chênh nhau 3–4 lần kích thước, còn lợi thế của AVIF sẽ thu hẹp khi dùng preset nhanh. Các benchmark do Google và Mozilla công bố giai đoạn 2019–2023 báo cáo WebP tiết kiệm khoảng 26–34% so với JPEG ở cùng SSIM, còn AVIF tiết kiệm khoảng 40–50% so với JPEG — nhưng những khoảng đó giả định encoder preset chậm và chất lượng được tinh chỉnh, không phải cài đặt mặc định một nút bấm của hầu hết phần mềm chỉnh ảnh.

Một chiều khác là chi phí mã hoá và giải mã. JPEG giải mã trong một phần nghìn giây trên bất kỳ thiết bị nào. WebP xấp xỉ như vậy. Giải mã AVIF tốn CPU hơn, và mã hoá AVIF ở preset chất lượng cao có thể mất nhiều giây cho mỗi ảnh. Hồ sơ chi phí đó ổn cho pipeline asset lúc build, nhưng bất tiện với nội dung do người dùng tạo, nơi server phải mã hoá lại từng upload trên hot path.

Tình huống thực tế

Tình huống 1 — Ảnh thumbnail và hero cho blog. Tôi vừa rà lại site của mình và thấy hero image đang phát ở mức 1,8 MB. Xuất lại sang WebP chất lượng 82 đưa nó xuống 210 KB, và Largest Contentful Paint của trang đã giảm từ 2,4 giây xuống 1,1 giây trên hồ sơ 4G bị bóp băng thông trong Lighthouse. Mặc định WebP là định dạng chính, để <picture> phục vụ JPEG làm fallback cho môi trường rất cũ. Luôn resize ảnh xuất đúng chiều rộng CSS hiển thị; phục vụ ảnh rộng 3000 pixel vào container 600 pixel lãng phí băng thông bất kể định dạng nào.

Tình huống 2 — Logo và biểu tượng. Nếu bạn có nguồn vector, xuất SVG đầu tiên. Có lần tôi review một landing page mà logo thương hiệu đỏ được xuất thành JPEG chất lượng 75, và các cạnh đỏ chảy thành vầng hồng quanh mỗi chữ cái. Chroma subsampling 4:2:0 phá cạnh đỏ trên nền tối trước khi phá gần như bất cứ thứ gì khác. Nếu chỉ có nguồn raster, chọn PNG hoặc WebP không tổn hao. Coi nén có tổn hao trên logo là cờ đỏ chứ không phải tối ưu.

Tình huống 3 — Ảnh chụp màn hình và capture UI. Ảnh chụp màn hình nên mặc định là PNG. Chrome trình duyệt, snippet code và font CJK đều lộ artefact JPEG rất mạnh — tôi học được điều này sau khi một reviewer tài liệu gắn cờ “font monospace bị mờ” ở hai PR liên tiếp. Nếu buộc phải giảm dung lượng, hãy dùng pngquant (brew install pngquant trên macOS) để giảm palette xuống 256 màu; ảnh chụp UI hiếm khi thấy khác biệt, còn file thường nhỏ đi 4–6 lần. Với site docs, cân nhắc ghép PNG với markup ảnh responsive bằng CSS để màn hình retina nhận asset 2x còn màn hình cũ tải bản 1x — điều này thường tiết kiệm nhiều byte hơn là đổi định dạng.

Tình huống 4 — Lưu trữ nguồn gốc. Với nguồn có thể tái xử lý sau này (master ảnh chụp, bản scan thô, ảnh sản phẩm), hãy giữ một bản không tổn hao như TIFF hoặc WebP không tổn hao ở cold storage và phái sinh các biến thể có tổn hao khi cần. Nén lại JPEG có tổn hao nhiều lần sẽ xuống cấp ở mỗi chu kỳ (“generation loss”), nên bạn muốn có một nguồn sạch để quay lại.

Những hiểu lầm thường gặp

“PNG luôn có chất lượng cao nhất.” PNG là không tổn hao, nghĩa là tái tạo hoàn hảo, nhưng với ảnh chụp thì sự nguyên chất đó chuyển thành file lớn hơn vài lần mức cần thiết. Trên mobile, ảnh vài megabyte làm tổn hại thời gian tải cảm nhận và Core Web Vitals.

“WebP không chạy trên mọi trình duyệt.” Kể từ Safari 14 cuối năm 2020, WebP đã được hỗ trợ trong mọi trình duyệt chính. Nếu thực sự cần hỗ trợ di sản, phần tử <picture> với fallback JPEG là giải pháp gọn gàng.

“AVIF là phép thuật.” Hiệu suất nén xuất sắc, nhưng mã hoá chậm hơn JPEG hoặc WebP đáng kể. Trên M2 MacBook Air của tôi, avifenc --speed 4 mất 5–9 giây cho một ảnh 2400×1600; ở --speed 0, dự kiến hơn 30 giây. Giải mã trên thiết bị di động cũ cũng là mối lo. AVIF hợp với pipeline batch và tối ưu hoá lúc build hơn là mã hoá lại mọi upload của người dùng trên hot path.

“Cứ dùng JPEG thôi.” Điều này hợp lý cho đến khoảng năm 2015, nhưng WebP và AVIF hiện đại thường cho file nhỏ hơn ở chất lượng tương đương với hỗ trợ gần như toàn phổ. Pipeline mới nên coi WebP là cơ sở thay vì JPEG.

“Chất lượng cao luôn đáng giá.” Trên mức chất lượng 85 với JPEG hoặc WebP, kích thước file tăng nhanh hơn chất lượng cảm nhận. Người xem hiếm khi nhận ra khác biệt giữa chất lượng 85 và 95, nhưng file có thể gấp đôi. Đo bằng thang đo cảm nhận (SSIM, butteraugli) thay vì tin thanh chất lượng như thang tuyến tính.

“Resize không quan trọng nếu tôi nén tốt.” Chiến thắng lớn nhất trong phân phối ảnh thường đến từ gửi ảnh đúng kích thước chứ không phải từ tinh chỉnh nén. WebP rộng 800 pixel gần như luôn nhẹ hơn WebP rộng 3000 pixel, bất kể tham số chất lượng, vì bạn đang loại bỏ pixel thay vì xấp xỉ chúng.

Danh sách kiểm tra

  1. Nguồn có phải vector không? Nếu có, lưu thành SVG.
  2. Có cần trong suốt không?
    • Có và nội dung dạng ảnh chụp: WebP có tổn hao với alpha hoặc AVIF.
    • Có và nội dung là logo hoặc icon: PNG hoặc WebP không tổn hao.
  3. Có cần hoạt ảnh không? WebP hoạt hình, APNG hoặc AVIF. Palette 256 màu của GIF kém cho ảnh chụp.
  4. Nội dung nặng về ảnh chụp hoặc gradient? Mặc định WebP có tổn hao, thêm AVIF nơi băng thông quan trọng.
  5. Nội dung là ảnh chụp màn hình hoặc UI nhiều chữ? Ưu tiên PNG hoặc WebP không tổn hao.
  6. Cần tương thích tối đa? Dùng phần tử <picture> với thứ tự AVIF → WebP → JPEG.

Công cụ liên quan

Bạn có thể thử trực tiếp các đánh đổi này trong trình nén ảnh của Patrache Studio được tham chiếu ở relatedToolUrl. Ảnh thường là một phần của pipeline asset lớn hơn, nên đọc kèm các hướng dẫn bổ trợ sẽ giúp bạn có tiêu chí thống nhất: Hợp nhất và chia PDF trong trình duyệt nói về điều xảy ra khi ảnh của bạn nằm trong hợp đồng hoặc bó tài liệu scan, còn Bảo mật mã QR đáng đọc nếu ảnh của bạn có mã QR quét được trên bao bì hoặc poster sản phẩm.

Tài liệu tham khảo

Công cụ liên quan

tools.patrache.studio/image/compress/