Apa yang sebenarnya dihemat WebP lossless dibanding PNG

Versi singkat

WebP lossless sering kali lebih kecil daripada PNG untuk piksel yang sama. Itulah alasan praktis orang menggunakannya.

Namun kata "sering" penting. WebP lossless bukan pengganti ajaib untuk setiap PNG. Ia cenderung paling banyak menghemat pada gambar dengan transparansi, tangkapan layar, tangkapan UI, dan konten campuran grafis/foto. Ia dapat menghemat sedikit, atau sesekali kalah, pada aset yang sangat kecil, PNG palet yang sangat dioptimalkan, dan ikon sederhana.

Jika Anda mengoptimalkan situs web nyata, pertanyaan yang tepat bukan "Apakah WebP lebih baik daripada PNG?" Melainkan: "PNG mana milik saya yang menjadi jauh lebih kecil sebagai WebP lossless, tanpa menimbulkan masalah kompatibilitas atau alur kerja?"

Itu pertanyaan yang lebih sempit, dan jauh lebih mudah dijawab.

Apa arti "lossless" di sini

Lossless berarti piksel yang didekode cocok persis dengan piksel sumber. Jika sebuah PNG dikonversi ke WebP lossless lalu didekode lagi, piksel gambarnya seharusnya identik.

Itu tidak berarti filenya sama. Metadata, penanganan profil warna, chunk PNG tambahan, informasi gamma, stempel waktu, dan chunk khusus alat dapat berubah, dihapus, atau direpresentasikan secara berbeda tergantung pipeline konversi Anda.

Perbedaan ini penting jika Anda berurusan dengan gambar arsip, alur kerja cetak, citra ilmiah, bukti hukum, atau situasi apa pun di mana container file membawa informasi non-piksel yang penting. Untuk pengiriman web biasa, sebagian besar tim terutama peduli pada piksel visual, transparansi, dimensi, dan konsistensi warna.

Jika Anda menerbitkan gambar yang disediakan pengguna, metadata juga merupakan isu privasi. Kami membahas topik yang lebih luas itu dalam cara menghapus metadata EXIF sebelum membagikan foto secara online, tetapi prinsip yang sama berlaku di sini: optimasi gambar harus eksplisit tentang apa yang dipertahankan dan apa yang dihapus.

Mengapa PNG terkompresi dengan baik, dan di mana batasnya

PNG adalah format yang sangat baik. Ia menjadi default web karena alasan yang kuat:

• Lossless.
• Mendukung transparansi alpha.
• Didukung secara luas.
• Dapat diprediksi dan sederhana untuk digunakan.
• Sangat baik untuk grafis datar, tangkapan layar, logo, dan aset UI.

Kompresi PNG bekerja dengan memfilter baris gambar lalu menerapkan kompresi DEFLATE. Kombinasi itu efektif, terutama ketika piksel yang berdekatan mirip.

Masalahnya bukan PNG itu buruk. Masalahnya adalah PNG sudah tua. Model kompresinya memiliki lebih sedikit trik dibanding format yang lebih baru. Setelah Anda mengoptimalkan PNG dengan encoder yang baik, Anda mungkin masih menyisakan byte yang bisa dihemat karena format itu sendiri tidak dapat merepresentasikan beberapa pola seefisien WebP lossless.

Di situlah WebP lossless masuk.

Apa yang dilakukan WebP lossless secara berbeda

WebP lossless menggunakan sistem kompresi yang dirancang khusus untuk gambar, bukan lapisan kompresi serbaguna yang ditempelkan pada baris yang difilter. Di balik layar, ia dapat menggunakan teknik seperti predictive coding, transformasi warna, palet, referensi ke belakang, dan entropy coding untuk merepresentasikan pola piksel yang berulang atau dapat diprediksi secara ringkas.

Anda tidak perlu menghafal detail implementasinya. Model mental yang berguna adalah ini:

PNG mengompresi baris dengan baik. WebP lossless memiliki lebih banyak cara untuk mendeskripsikan struktur gambar.

Fleksibilitas tambahan itulah yang membuat WebP lossless sering dapat menghasilkan file yang lebih kecil dari gambar sumber yang sama.

Google secara historis menggambarkan gambar WebP lossless sebagai sekitar 26% lebih kecil daripada PNG secara rata-rata dalam studinya sendiri. Anggap itu sebagai tolok ukur arah, bukan janji. Gambar Anda bukan rata-rata. Design system, tangkapan layar, foto produk, ilustrasi, aset ekspor, dan unggahan CMS Anda akan memiliki perilakunya sendiri.

Di mana WebP lossless biasanya paling banyak menghemat

Gambar transparan

PNG umum digunakan karena transparansi alpha. WebP lossless juga mendukung alpha, dan sering mengompresinya secara efisien.

Ini berguna untuk:

• Potongan produk
• Stiker dan badge
• Overlay antarmuka
• Diagram dengan latar belakang transparan
• Logo yang diekspor lebih besar dari yang diperlukan

Penghematan dapat terasa ketika channel alpha berisi area besar yang dapat diprediksi, tepi lembut, atau bentuk berulang. Jika Anda memiliki katalog penuh gambar produk transparan, WebP lossless layak diuji sejak awal.

Tangkapan layar dan tangkapan UI

Tangkapan layar sering berisi area datar yang besar, komponen antarmuka berulang, teks, ikon, bayangan, dan beberapa area fotografis. Campuran itu bisa canggung untuk PNG, terutama pada dimensi besar.

WebP lossless sering menangani gambar ini dengan baik. Tangkapan layar UI satu halaman penuh yang berukuran 900 KB sebagai PNG teroptimasi mungkin menjadi 500–700 KB sebagai WebP lossless. Kadang penghematannya lebih besar. Kadang lebih kecil. Tetapi kategorinya menjanjikan.

Jika tangkapan layar tersebut muncul dalam dokumentasi, halaman pemasaran, alur onboarding, atau studi kasus, efek agregatnya bisa nyata.

Konten campuran ilustrasi dan gambar

Banyak grafis web modern bukan ilustrasi murni maupun foto murni. Bayangkan hero image yang berisi UI produk, gradien, ikon kecil, label teks, dan foto yang disematkan.

PNG mungkin mempertahankannya dengan sempurna tetapi menghasilkan file besar. WebP atau AVIF lossy dapat menimbulkan artefak di sekitar teks dan tepi jika didorong terlalu keras. WebP lossless dapat menjadi jalan tengah yang masuk akal ketika tepi yang presisi penting.

Untuk pohon keputusan yang lebih luas lintas format gambar, termasuk AVIF dan WebP lossy, lihat Format gambar pada 2026: kapan AVIF mengalahkan WebP dan kapan tidak.

Di mana PNG mungkin masih lebih baik

Ikon kecil dan aset sederhana

Untuk file yang sangat kecil, overhead format penting. Ikon PNG 650 byte bukan kandidat konversi yang jelas. WebP mungkin menghemat 80 byte, atau justru menjadi lebih besar.

Pada skala itu, kompleksitas operasional mungkin melebihi manfaatnya. Jika file sudah sangat kecil, tidak memblokir render, dan di-cache untuk waktu lama, Anda mungkin punya hal yang lebih penting untuk diperbaiki.

PNG palet yang dioptimalkan dengan cermat

Sebagian PNG jauh lebih kecil daripada yang orang perkirakan karena menggunakan palet terbatas. PNG indexed-color yang baik bisa sulit dikalahkan untuk grafis sederhana.

Ini terutama berlaku untuk:

• Logo kecil
• Pixel art
• Ikon datar
• Diagram sederhana
• Grafis dengan sedikit warna

Berhati-hatilah saat membandingkan WebP dengan ekspor PNG yang asal-asalan. Jika PNG datang langsung dari alat desain dengan metadata yang tidak perlu dan pengaturan kompresi yang buruk, WebP mungkin terlihat jauh lebih baik. Itu tidak berarti WebP mengalahkan PNG yang teroptimasi baik dengan margin yang sama.

Pengujian yang adil membandingkan WebP lossless dengan PNG teroptimasi, bukan file apa pun yang kebetulan diunggah.

Gambar yang seharusnya lossy

Ini kesalahan yang tidak banyak dibicarakan: tim mengonversi PNG ke WebP lossless ketika gambar itu seharusnya bukan PNG sejak awal.

Foto adalah kasus yang paling umum. Foto full-color yang disimpan sebagai PNG bisa sangat besar. Mengonversinya ke WebP lossless mungkin mengurangi file, tetapi biasanya masih jauh lebih besar daripada WebP atau AVIF lossy berkualitas tinggi.

Jika pengguna tidak dapat melihat perbedaannya, lossless sering kali merupakan tujuan yang keliru. Fotografi produk, gambar editorial, latar belakang, dan potret biasanya lebih cocok dalam format lossy dengan pengaturan kualitas yang masuk akal.

Lossless sebaiknya disimpan untuk kasus ketika piksel persis penting: tangkapan layar UI, diagram, grafis dengan banyak teks, transparansi, bagan yang dihasilkan, dan aset yang terlihat menurun kualitasnya di bawah kompresi lossy.

Apa yang dihemat selain byte

Penghematan yang jelas adalah ukuran transfer. File gambar yang lebih kecil biasanya berarti bandwidth lebih rendah, unduhan lebih cepat, dan perilaku lebih baik pada koneksi lambat.

Namun ada manfaat sekunder:

• Data yang digunakan pengunjung pada paket terbatas lebih sedikit
• Populasi cache gambar lebih cepat
• Bandwidth CDN berkurang
• Volume penyimpanan dan cadangan lebih rendah pada skala besar
• Tekanan lebih kecil pada anggaran performa

Penghematan ini tidak terdistribusi merata. Satu PNG 2 MB yang dikonversi menjadi WebP 900 KB lebih berarti daripada lima puluh ikon yang masing-masing dikurangi 100 byte.

Inilah mengapa optimasi gambar harus diprioritaskan berdasarkan dampak halaman, bukan ideologi format. Jika Lighthouse menandai pengiriman gambar, bacalah sebagai petunjuk, bukan vonis. Panduan kami tentang cara membaca laporan Lighthouse tanpa panik menjelaskan cara memisahkan masalah performa yang bermakna dari diagnostik yang berisik.

Trade-off biaya decode

File yang lebih kecil bukan satu-satunya variabel performa. Browser juga perlu mendekode gambar sebelum mengecatnya.

Dekode PNG sudah matang dan biasanya cepat. Dekode WebP juga didukung luas dan efisien, tetapi dalam beberapa kasus dapat memakan lebih banyak CPU. Pada perangkat modern ini jarang menjadi penghalang, tetapi pada ponsel kelas bawah, halaman yang penuh gambar, atau aset besar di above-the-fold, hal ini layak diukur.

Aturan praktisnya: jika WebP lossless memangkas PNG besar sebesar 30–50%, penghematan jaringan biasanya mendominasi. Jika hanya memangkas PNG kecil sebesar 3%, trade-off tersebut kemungkinan tidak layak dipikirkan.

Pekerjaan performa penuh dengan keputusan ambang seperti ini. Jangan mengoptimalkan setiap byte dengan intensitas yang sama.

Metode pengujian sederhana

Gunakan kumpulan yang representatif, bukan satu gambar.

Buat folder dengan contoh dari situs Anda yang sebenarnya:

• Logo dan ikon
• Tangkapan layar
• Potongan produk
• Diagram
• PNG yang diunggah CMS
• Gambar pratinjau sosial
• Grafis hero besar

Lalu bandingkan tiga hal:

1. PNG asli seperti yang diunggah
2. PNG yang dioptimalkan
3. Versi WebP lossless

Untuk alur kerja command-line, tim sering menggunakan alat seperti oxipng, pngcrush, zopflipng, atau cwebp -lossless. Alat yang tepat kurang penting dibanding disiplin membandingkan hal yang setara.

Lacak:

• Ukuran file
• Kesetaraan piksel setelah decode
• Rendering visual di browser target
• Kebenaran transparansi
• Tampilan warna
• Waktu build
• Gesekan alur kerja CMS atau desain

Spreadsheet sederhana sudah cukup. Tambahkan ukuran file asli, ukuran PNG teroptimasi, ukuran WebP lossless, persentase yang dihemat, dan halaman tempat gambar muncul.

Lalu urutkan berdasarkan total byte yang dihemat. Urutan itu biasanya akan memberi tahu Anda apa yang perlu dilakukan.

Pengiriman: jangan sembarangan merusak klien lama

Dukungan WebP kini luas di browser modern. Untuk sebagian besar situs web publik, penggunaannya aman. Namun, jika Anda memiliki embedded webview, klien email, browser enterprise lawas, aplikasi native, atau crawler yang tidak biasa dalam campuran, uji sebelum mengganti PNG sepenuhnya.

Pola konservatifnya adalah mempertahankan PNG sebagai fallback dan menyajikan WebP ketika didukung:

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

Pendekatan ini membosankan, dan membosankan itu baik. Pengguna dengan dukungan WebP mendapatkan file yang lebih kecil. Semua yang lain mendapatkan PNG.

Jika sistem build Anda memberi fingerprint pada aset dan CDN Anda meng-cache dengan benar, ini tidak sulit dipelihara. Jika CMS Anda membuat format alternatif terasa merepotkan, mulai dari gambar terbesar dan paling sering diulang, alih-alih mencoba mengonversi seluruh pustaka media dalam satu sprint.

Privasi dan pemrosesan lokal

Konversi gambar sering terjadi dalam pipeline build atau layanan media sisi server. Itu baik-baik saja untuk banyak tim. Namun jika Anda menangani tangkapan layar sensitif, unggahan pelanggan, atau dokumen internal, perhatikan di mana file diproses.

Peralatan gambar sisi browser sudah cukup baik untuk banyak konversi sederhana, pratinjau, dan pemeriksaan metadata. Ada batasannya, tetapi pemrosesan lokal dapat mengurangi unggahan gambar pribadi yang tidak perlu. Kami membahas trade-off tersebut dalam mengapa memproses gambar di browser adalah kemenangan privasi.

Untuk aset internal, poin utamanya adalah kejelasan kebijakan. Ketahui apakah gambar meninggalkan perangkat, di mana versi yang ditransformasi disimpan, dan apakah metadata dipertahankan.

Aturan praktis

Gunakan WebP lossless ketika ketiganya benar:

• Sumber saat ini adalah PNG.
• Piksel persis atau transparansi yang bersih penting.
• WebP lossless menghemat jumlah yang bermakna setelah dibandingkan dengan PNG teroptimasi.

Pertahankan PNG ketika:

• Filenya sangat kecil.
• PNG sudah dioptimalkan palet dan kompetitif.
• Batasan kompatibilitas tidak biasa.
• Kompleksitas operasional tidak sebanding dengan byte yang dihemat.

Gunakan WebP atau AVIF lossy ketika:

• Gambar bersifat fotografis.
• Piksel persis tidak penting.
• Pengaturan kualitas dapat mengurangi ukuran secara drastis tanpa kerusakan yang terlihat.

Strategi gambar terbaik jarang berupa satu format di mana-mana. Biasanya itu adalah sekumpulan kecil aturan yang diterapkan secara konsisten.

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

💡 Coba ini: Jalankan PNG yang sama melalui Image Converter untuk menghasilkan versi WebP lossless dan bandingkan ukuran file secara langsung.

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

Jadi, apa yang sebenarnya dihemat WebP lossless?

Ia menghemat byte di tempat PNG sudah kehabisan trik kompresi. Kadang itu berarti 10% yang sederhana. Kadang itu berarti memangkas gambar transparan besar hampir separuhnya. Di seluruh situs nyata, penghematan biasanya terkonsentrasi pada sebagian kecil aset.

Itulah bagian pentingnya. WebP lossless bukan peningkatan moral dari PNG. Ia adalah opsi praktis untuk pekerjaan tertentu: gambar web lossless yang lebih kecil dengan transparansi dan dukungan browser modern yang luas.

Gunakan ketika angkanya membenarkan. Biarkan PNG apa adanya ketika tidak.