WebP lossless thực sự giúp bạn tiết kiệm gì so với PNG

Phiên bản ngắn gọn

WebP lossless thường nhỏ hơn PNG với cùng các pixel. Đó là lý do thực tế khiến nhiều người dùng nó.

Nhưng chữ "thường" rất quan trọng. WebP lossless không phải là giải pháp thay thế kỳ diệu cho mọi PNG. Nó có xu hướng tiết kiệm nhiều nhất với ảnh có độ trong suốt, ảnh chụp màn hình, ảnh chụp UI, và nội dung pha trộn giữa đồ họa/ảnh chụp. Nó có thể tiết kiệm rất ít, hoặc đôi khi thua, với asset rất nhỏ, PNG palette đã được tối ưu mạnh, và icon đơn giản.

Nếu bạn đang tối ưu một website thực tế, câu hỏi đúng không phải là "WebP có tốt hơn PNG không?" Mà là: "Những PNG nào của tôi nhỏ đi đáng kể khi chuyển sang WebP lossless, mà không tạo ra vấn đề về tương thích hoặc quy trình làm việc?"

Đó là một câu hỏi hẹp hơn, và dễ trả lời hơn nhiều.

"Lossless" ở đây có nghĩa là gì

Lossless nghĩa là các pixel sau khi giải mã khớp chính xác với pixel nguồn. Nếu một PNG được chuyển sang WebP lossless rồi giải mã lại, các pixel của ảnh phải giống hệt nhau.

Điều đó không có nghĩa là tệp vẫn y như cũ. Metadata, cách xử lý color profile, các chunk PNG phụ trợ, thông tin gamma, timestamp, và các chunk riêng của công cụ có thể bị thay đổi, loại bỏ, hoặc biểu diễn khác đi tùy theo pipeline chuyển đổi của bạn.

Sự phân biệt này quan trọng nếu bạn đang làm việc với ảnh lưu trữ, quy trình in ấn, ảnh khoa học, bằng chứng pháp lý, hoặc bất kỳ tình huống nào mà container của tệp mang thông tin phi pixel quan trọng. Với việc phân phối web thông thường, hầu hết đội ngũ chủ yếu quan tâm đến pixel hiển thị, độ trong suốt, kích thước, và tính nhất quán màu sắc.

Nếu bạn xuất bản ảnh do người dùng cung cấp, metadata cũng là một vấn đề quyền riêng tư. Chúng tôi đã đề cập chủ đề rộng hơn đó trong cách xóa metadata EXIF trước khi chia sẻ ảnh trực tuyến, nhưng cùng nguyên tắc cũng áp dụng ở đây: tối ưu ảnh cần nói rõ nó giữ lại gì và loại bỏ gì.

Vì sao PNG nén tốt, và nó dừng lại ở đâu

PNG là một định dạng rất tốt. Nó trở thành mặc định trên web vì những lý do chính đáng:

• Nó là lossless.
• Nó hỗ trợ alpha transparency.
• Nó được hỗ trợ rộng rãi.
• Nó dễ dự đoán và đơn giản để làm việc.
• Nó rất phù hợp cho đồ họa phẳng, ảnh chụp màn hình, logo, và UI asset.

Cơ chế nén PNG hoạt động bằng cách lọc các hàng ảnh rồi áp dụng nén DEFLATE. Sự kết hợp đó hiệu quả, đặc biệt khi các pixel gần nhau tương tự nhau.

Vấn đề không phải là PNG tệ. Vấn đề là PNG đã cũ. Mô hình nén của nó có ít thủ thuật hơn so với các định dạng mới hơn. Sau khi bạn đã tối ưu một PNG bằng một encoder tốt, bạn vẫn có thể đang bỏ lỡ byte vì bản thân định dạng không thể biểu diễn một số mẫu hiệu quả như WebP lossless.

Đó là lúc WebP lossless xuất hiện.

WebP lossless làm khác đi điều gì

WebP lossless dùng một hệ thống nén được thiết kế riêng cho ảnh, thay vì một lớp nén đa dụng được gắn vào các hàng đã lọc. Bên dưới, nó có thể dùng các kỹ thuật như predictive coding, color transform, palette, tham chiếu ngược, và entropy coding để biểu diễn gọn các mẫu pixel lặp lại hoặc dễ dự đoán.

Bạn không cần ghi nhớ chi tiết triển khai. Mô hình tư duy hữu ích là:

PNG nén các hàng rất tốt. WebP lossless có nhiều cách hơn để mô tả cấu trúc ảnh.

Sự linh hoạt bổ sung đó là lý do WebP lossless thường có thể tạo ra tệp nhỏ hơn từ cùng ảnh nguồn.

Google từng mô tả ảnh WebP lossless trung bình nhỏ hơn PNG khoảng 26% trong các nghiên cứu của họ. Hãy xem đó là một mốc tham chiếu định hướng, không phải lời hứa. Ảnh của bạn không phải là một giá trị trung bình. Design system, ảnh chụp màn hình, ảnh sản phẩm, minh họa, asset xuất ra, và ảnh tải lên CMS của bạn sẽ có hành vi riêng.

WebP lossless thường tiết kiệm nhiều nhất ở đâu

Ảnh trong suốt

PNG thường được dùng vì alpha transparency. WebP lossless cũng hỗ trợ alpha, và thường nén nó hiệu quả.

Điều này hữu ích cho:

• Ảnh sản phẩm đã tách nền
• Sticker và badge
• Lớp phủ giao diện
• Sơ đồ có nền trong suốt
• Logo được xuất lớn hơn cần thiết

Mức tiết kiệm có thể đáng chú ý khi kênh alpha chứa các vùng lớn dễ dự đoán, mép mềm, hoặc hình dạng lặp lại. Nếu bạn có một catalogue đầy ảnh sản phẩm trong suốt, WebP lossless đáng được kiểm thử sớm.

Ảnh chụp màn hình và ảnh chụp UI

Ảnh chụp màn hình thường chứa các vùng phẳng lớn, thành phần giao diện lặp lại, văn bản, icon, bóng đổ, và một số vùng ảnh chụp. Sự pha trộn đó có thể khó xử lý với PNG, đặc biệt ở kích thước lớn.

WebP lossless thường xử lý tốt những ảnh này. Một ảnh chụp UI toàn trang có kích thước 900 KB dưới dạng PNG đã tối ưu có thể trở thành 500–700 KB dưới dạng WebP lossless. Đôi khi mức tiết kiệm lớn hơn. Đôi khi nhỏ hơn. Nhưng đây là một nhóm đầy triển vọng.

Nếu những ảnh chụp màn hình đó xuất hiện trong tài liệu, trang marketing, luồng onboarding, hoặc case study, hiệu ứng cộng dồn có thể rất thực tế.

Nội dung pha trộn giữa minh họa và ảnh

Nhiều đồ họa web hiện đại không hoàn toàn là minh họa thuần túy cũng không hoàn toàn là ảnh chụp. Hãy nghĩ đến một hero image chứa UI sản phẩm, gradient, icon nhỏ, nhãn văn bản, và ảnh nhúng.

PNG có thể giữ nguyên nó hoàn hảo nhưng tạo ra tệp lớn. Lossy WebP hoặc AVIF có thể tạo artifact quanh chữ và cạnh nếu bị nén quá mạnh. WebP lossless có thể là một điểm cân bằng hợp lý khi các cạnh chính xác là điều quan trọng.

Để có cây quyết định rộng hơn giữa các định dạng ảnh, bao gồm AVIF và lossy WebP, xem Định dạng ảnh năm 2026: khi nào AVIF vượt WebP và khi nào không.

Khi nào PNG vẫn có thể tốt hơn

Icon rất nhỏ và asset đơn giản

Với các tệp rất nhỏ, overhead của định dạng trở nên quan trọng. Một icon PNG 650 byte không phải là ứng viên chuyển đổi hiển nhiên. WebP có thể tiết kiệm 80 byte, hoặc cũng có thể lớn hơn.

Ở quy mô đó, độ phức tạp vận hành có thể lớn hơn lợi ích. Nếu tệp vốn đã rất nhỏ, không chặn render, và được cache trong thời gian dài, có lẽ bạn có việc khác đáng sửa hơn.

PNG palette được tối ưu cẩn thận

Một số PNG nhỏ hơn nhiều so với mọi người nghĩ vì chúng dùng palette giới hạn. Một PNG indexed-color tốt có thể rất khó vượt qua với đồ họa đơn giản.

Điều này đặc biệt đúng với:

• Logo nhỏ
• Pixel art
• Icon phẳng
• Sơ đồ đơn giản
• Đồ họa có ít màu

Hãy cẩn thận khi so sánh WebP với các bản xuất PNG cẩu thả. Nếu PNG đến thẳng từ công cụ thiết kế với metadata không cần thiết và thiết lập nén kém, WebP có thể trông tốt hơn rất nhiều. Điều đó không có nghĩa WebP vượt một PNG được tối ưu tốt với cùng biên độ.

Một phép thử công bằng là so sánh WebP lossless với PNG đã tối ưu, không phải bất kỳ tệp nào tình cờ được tải lên.

Ảnh đáng lẽ nên dùng lossy

Đây là sai lầm thầm lặng: các đội chuyển PNG sang WebP lossless trong khi ngay từ đầu ảnh đó không nên là PNG.

Ảnh chụp là trường hợp thường gặp. Một ảnh chụp đầy đủ màu lưu dưới dạng PNG có thể rất lớn. Chuyển nó sang WebP lossless có thể giảm kích thước tệp, nhưng thường vẫn lớn hơn nhiều so với một WebP hoặc AVIF lossy chất lượng cao.

Nếu người dùng không cảm nhận được khác biệt, lossless thường là mục tiêu sai. Ảnh sản phẩm, ảnh biên tập, nền, và chân dung thường nên ở định dạng lossy với thiết lập chất lượng hợp lý.

Lossless nên được dành cho các trường hợp pixel chính xác là điều quan trọng: ảnh chụp UI, sơ đồ, đồ họa nhiều chữ, độ trong suốt, biểu đồ được tạo tự động, và asset xuống cấp thấy rõ khi nén lossy.

Nó tiết kiệm gì ngoài byte

Khoản tiết kiệm rõ ràng là kích thước truyền tải. Tệp ảnh nhỏ hơn thường đồng nghĩa với ít băng thông hơn, tải xuống nhanh hơn, và hoạt động tốt hơn trên kết nối chậm.

Nhưng còn có các lợi ích phụ:

• Khách truy cập dùng ít dữ liệu hơn trên gói có giới hạn
• Cache ảnh được lấp đầy nhanh hơn
• Giảm băng thông CDN
• Giảm dung lượng lưu trữ và sao lưu ở quy mô lớn
• Ít áp lực hơn lên ngân sách hiệu năng

Những khoản tiết kiệm này không phân bố đều. Một PNG 2 MB được chuyển thành WebP 900 KB quan trọng hơn năm mươi icon giảm 100 byte mỗi cái.

Đây là lý do tối ưu ảnh nên được ưu tiên theo tác động lên trang, không phải theo hệ tư tưởng định dạng. Nếu Lighthouse cảnh báo về phân phối ảnh, hãy xem đó là gợi ý, không phải phán quyết. Hướng dẫn của chúng tôi về cách đọc báo cáo Lighthouse mà không hoảng sợ giải thích cách tách vấn đề hiệu năng có ý nghĩa khỏi chẩn đoán nhiễu.

Đánh đổi về chi phí giải mã

Tệp nhỏ hơn không phải là biến số hiệu năng duy nhất. Trình duyệt cũng cần giải mã ảnh trước khi vẽ chúng.

Giải mã PNG đã trưởng thành và thường nhanh. Giải mã WebP cũng được hỗ trợ rộng rãi và hiệu quả, nhưng trong một số trường hợp có thể tốn CPU hơn. Trên thiết bị hiện đại, điều này hiếm khi là rào cản, nhưng trên điện thoại cấu hình thấp, trang nhiều ảnh, hoặc asset lớn phía trên màn hình đầu tiên, nó đáng được đo lường.

Quy tắc thực tế: nếu WebP lossless giảm một PNG lớn đi 30–50%, lợi ích mạng thường chiếm ưu thế. Nếu nó chỉ giảm một PNG nhỏ 3%, đánh đổi đó có lẽ không đáng bận tâm.

Công việc hiệu năng đầy những quyết định theo ngưỡng như vậy. Đừng tối ưu từng byte với cùng một mức độ quyết liệt.

Một phương pháp kiểm thử đơn giản

Dùng một lô đại diện, không phải một ảnh duy nhất.

Tạo một thư mục có ví dụ từ chính site của bạn:

• Logo và icon
• Ảnh chụp màn hình
• Ảnh sản phẩm đã tách nền
• Sơ đồ
• PNG được tải lên CMS
• Ảnh preview mạng xã hội
• Đồ họa hero lớn

Sau đó so sánh ba thứ:

1. PNG gốc như đã tải lên
2. PNG đã tối ưu
3. Phiên bản WebP lossless

Với quy trình dòng lệnh, các đội thường dùng công cụ như oxipng, pngcrush, zopflipng, hoặc cwebp -lossless. Công cụ cụ thể ít quan trọng hơn kỷ luật so sánh tương đương với tương đương.

Theo dõi:

• Kích thước tệp
• Tính bằng nhau của pixel sau khi giải mã
• Hiển thị trực quan trong trình duyệt mục tiêu
• Độ chính xác của transparency
• Diện mạo màu sắc
• Thời gian build
• Ma sát trong quy trình CMS hoặc thiết kế

Một bảng tính đơn giản là đủ. Thêm kích thước tệp gốc, kích thước PNG đã tối ưu, kích thước WebP lossless, phần trăm tiết kiệm, và trang nơi ảnh xuất hiện.

Sau đó sắp xếp theo tổng số byte tiết kiệm. Thứ tự sắp xếp đó thường sẽ cho bạn biết cần làm gì.

Phân phối: đừng tùy tiện làm hỏng client cũ

Hỗ trợ WebP hiện đã rộng rãi trên các trình duyệt hiện đại. Với hầu hết website công khai, dùng nó là an toàn. Tuy vậy, nếu bạn có embedded webview, email client, trình duyệt doanh nghiệp cũ, ứng dụng native, hoặc crawler bất thường trong tổ hợp của mình, hãy kiểm thử trước khi thay thế hẳn PNG.

Mẫu thận trọng là giữ PNG làm fallback và phục vụ WebP ở nơi được hỗ trợ:

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

Cách này nhàm chán, và nhàm chán là tốt. Người dùng có hỗ trợ WebP nhận tệp nhỏ hơn. Những người còn lại nhận PNG.

Nếu hệ thống build của bạn fingerprint asset và CDN của bạn cache đúng cách, việc này không khó duy trì. Nếu CMS của bạn khiến định dạng thay thế trở nên phiền phức, hãy bắt đầu với những ảnh lớn nhất và được lặp lại nhiều nhất thay vì cố chuyển toàn bộ media library trong một sprint.

Quyền riêng tư và xử lý cục bộ

Chuyển đổi ảnh thường diễn ra trong build pipeline hoặc dịch vụ media phía server. Điều đó ổn với nhiều đội. Nhưng nếu bạn xử lý ảnh chụp màn hình nhạy cảm, nội dung khách hàng tải lên, hoặc tài liệu nội bộ, hãy chú ý nơi tệp được xử lý.

Công cụ ảnh phía trình duyệt đã đủ tốt cho nhiều tác vụ chuyển đổi đơn giản, preview, và kiểm tra metadata. Vẫn có giới hạn, nhưng xử lý cục bộ có thể giảm việc tải lên không cần thiết các ảnh riêng tư. Chúng tôi đã đề cập các đánh đổi trong vì sao xử lý ảnh trong trình duyệt là một thắng lợi về quyền riêng tư.

Với asset nội bộ, điểm chính là sự rõ ràng về chính sách. Hãy biết ảnh có rời khỏi thiết bị không, các phiên bản đã biến đổi được lưu ở đâu, và metadata có được giữ lại không.

Một quy tắc kinh nghiệm thực tế

Dùng WebP lossless khi cả ba điều sau đều đúng:

• Nguồn hiện là PNG.
• Pixel chính xác hoặc transparency sạch là điều quan trọng.
• WebP lossless tiết kiệm đáng kể sau khi so sánh với PNG đã tối ưu.

Giữ PNG khi:

• Tệp rất nhỏ.
• PNG đã được tối ưu palette và vẫn cạnh tranh.
• Ràng buộc tương thích bất thường.
• Độ phức tạp vận hành không đáng so với số byte tiết kiệm.

Dùng lossy WebP hoặc AVIF khi:

• Ảnh là ảnh chụp.
• Pixel chính xác không quan trọng.
• Một thiết lập chất lượng có thể giảm kích thước mạnh mà không gây hư hại thấy được.

Chiến lược ảnh tốt nhất hiếm khi là một định dạng cho mọi nơi. Nó là một tập nhỏ các quy tắc được áp dụng nhất quán.

<!-- tool-cta:start -->

💡 Hãy thử cách này: Chạy cùng một PNG qua Image Converter để tạo phiên bản WebP không mất dữ liệu và so sánh trực tiếp kích thước tệp.

<!-- tool-cta:end -->

Vậy WebP lossless thực sự tiết kiệm gì?

Nó tiết kiệm byte ở nơi PNG đã hết thủ thuật nén. Đôi khi điều đó có nghĩa là mức 10% khiêm tốn. Đôi khi nó có nghĩa là cắt gần một nửa một ảnh trong suốt lớn. Trên một site thực tế, khoản tiết kiệm thường tập trung ở một số ít asset.

Đó là phần quan trọng. WebP lossless không phải là một nâng cấp đạo đức so với PNG. Nó là một lựa chọn thực tế cho một công việc cụ thể: ảnh web lossless nhỏ hơn, có transparency và được hỗ trợ rộng rãi trên trình duyệt hiện đại.

Hãy dùng nó nơi các con số chứng minh là đáng. Hãy để PNG yên ở nơi chúng không chứng minh điều đó.