Apakah WebP benar-benar lebih kecil daripada JPG untuk gambar situs web?

Kami membandingkan JPG, WebP, dan AVIF pada foto yang sama sebesar 538,6 KB di slider yang sama, dan JPG menang. Berikut adalah alasan mengapa itu terjadi dan apa yang ditunjukkan oleh perbandingan yang adil.

August 9, 2026

Setiap panduan memberi tahu Anda bahwa WebP sekitar 30% lebih kecil daripada JPG pada kualitas yang sama. Studi milik Google adalah sumber angka tersebut. Kami melakukan perbandingan di kompresor kami sendiri dengan satu foto 3840x2160, texture.jpg sebesar 538,6 KB, dan pada posisi slider yang sama, JPEG menang: 286,1 KB dibandingkan 290,3 KB untuk WebP. AVIF, format yang seharusnya mengalahkan keduanya, berada di 312,7 KB.

Tidak ada yang rusak. Ketiga format membaca slider itu dengan cara yang berbeda, dan salah satunya melakukannya dengan sengaja. Setelah Anda tahu yang mana, hasilnya kembali seperti yang Anda harapkan, dan Anda mendapatkan kebiasaan yang layak dibawa ke alat apa pun yang sudah Anda gunakan.

Mengapa WebP lebih besar daripada JPG pada slider yang sama?

Kompresor kami memiliki keanehan yang banyak alat miliki dan hampir tidak ada yang menyebutkannya. Ketika format output adalah JPEG dan input sudah berupa JPEG, ia membaca tabel kuantisasi dari file sumber, memperkirakan kualitas file tersebut disimpan, lalu mengalikan slider Anda dengan perkiraan itu. Sumber yang mendapatkan skor 60 dengan slider di 80 dikodekan pada 48. WebP dan AVIF tidak mendapatkan perlakuan seperti itu, jadi 80 berarti 80 dan encoder melakukan apa yang diperintahkan. Proses di atas adalah JPEG pada 48 efektif melawan WebP pada 80 literal. File yang dikompresi lebih keras lebih kecil.

Rescale mendapatkan tempatnya. Mengkode ulang JPEG yang sudah lossy pada 80 ketika ditulis pada 60 menambah byte tanpa menambah detail kembali, jadi kami memperlakukan slider sebagai fraksi dari apa yang tersisa di file. Masalah yang lebih dalam adalah milik JPEG itu sendiri: spesifikasi menyimpan tabel kuantisasi mentah dan tidak pernah menyimpan angka kualitas, jadi 75 di Photoshop, 75 di MozJPEG, dan 75 di beberapa skrip PHP adalah tiga file yang berbeda. Menyamakan angka pada dua slider dan menyebutnya sebagai tes yang adil tidak berhasil.

Bagaimana ukuran terlihat ketika Anda membandingkannya dengan benar?

Pada 63, WebP menulis 200,6 KB dari sumber 538,6 KB itu. AVIF pada pengaturan yang sama menjadi 186,9 KB, dan 63 adalah angka yang dipilih mode pintar kami untuk AVIF, jadi itu bukan angka yang kami pilih untuk memuji format tersebut. Sesuaikan ukuran output terlebih dahulu, lalu buka kedua file dalam ukuran penuh dan putuskan mana yang dapat Anda terima. Itu adalah perbandingan yang layak.

Haruskah saya hanya menggunakan AVIF?

Dalam hal byte, AVIF menang. Dalam hal kesabaran, ia kalah. Mengkodekan bingkai 3840x2160 ke AVIF memakan waktu sekitar 10 hingga 11 detik di browser, sementara JPEG dan WebP kembali secara instan. Semua ini adalah WebAssembly yang berjalan di mesin Anda sendiri, jadi itu CPU Anda yang melakukan pengkodean intra AV1, dan biayanya meningkat seiring dengan jumlah piksel. Ada satu hal kedua yang perlu diketahui: jika encoder WASM gagal, kami kembali ke encoder kanvas browser, dan kanvas dapat menulis JPEG, PNG, dan WebP tetapi sama sekali tidak memiliki jalur AVIF. Untuk batch besar, Google merekomendasikan alat avifenc bawaan dibandingkan dengan build WebAssembly, dan biaya sepuluh pengkodean AVIF dalam satu tab juga diukur.

Apa yang saya hilangkan ketika saya mengubah JPG menjadi WebP?

Tiga hal konkret. Metadata hilang terlebih dahulu: mengompresi atau mengonversi mendekode gambar menjadi piksel mentah dan mengkode ulangnya, jadi EXIF, koordinat GPS, profil ICC, dan thumbnail yang disematkan semuanya hilang dari output. Orientasi bertahan, karena browser menerapkannya selama dekode. Jika Anda memerlukan tanggal pengambilan, simpan file aslinya. Dan JPG lossy yang dikode ulang sebagai WebP lossy adalah generasi kedua dari kehilangan yang ditumpuk pada yang pertama, jadi lakukan sekali dari sumber terbaik yang Anda miliki.

Chroma adalah kehilangan kedua. WebP lossy terkunci pada subsampling 4:2:0, tanpa opsi 4:4:4 di mana pun dalam format, jadi tangkapan layar dari kode yang disorot sintaks atau logo yang berada di merah jenuh dapat terlihat lebih buruk di WebP daripada di JPEG dengan bobot yang sama. Foto tidak peduli. Rendering adalah yang ketiga: JPEG progresif melukis bingkai penuh yang kasar lebih awal dan mengasah saat byte tiba, dan WebP tidak memiliki mode progresif, jadi yang besar tidak menunjukkan apa-apa sampai cukup banyak yang tiba. Pada gambar hero di atas koneksi yang lemah, itu mengubah seberapa cepat halaman terasa meskipun file lebih kecil.

Apakah WebP masih menang jika gambar memiliki transparansi?

JPEG tidak dapat melakukan transparansi. Tidak ada saluran alpha di mode JPEG mana pun, jadi untuk logo atau potongan, kontes sebenarnya adalah PNG melawan WebP, dan kasus untuk masing-masing dari dua format tersebut diukur pada file yang sama ini. Angka PNG kami menetapkan standar yang harus Anda kalahkan: alpha.png pada 900x606 dan 942,4 KB turun menjadi 383,9 KB melalui oxipng lossless pada level 3, dan menjadi 98,3 KB setelah imagequant menguranginya menjadi palet, yang merupakan pengurangan 90% dengan transparansi tetap utuh. WebP menyimpan alpha-nya tanpa kehilangan bahkan di dalam file lossy, jadi tepi potongan tetap bersih dengan cara apa pun. Jika Anda membuat potongan di tempat pertama, penghapus latar belakang kami selalu menulis PNG dengan alpha, dan PNG itu dapat langsung dimasukkan ke dalam kompresor setelahnya.

Mana yang seharusnya saya gunakan di situs?

Kirim WebP untuk foto. Setiap browser saat ini mendekodenya, termasuk Safari, dan penghematan itu nyata setelah Anda berhenti membandingkan angka slider. Simpan JPG di mana file harus dibuka di perangkat lunak lama, atau di mana hero besar mendapatkan manfaat dari rendering progresif lebih dari 30 KB. Panduan format gambar MDN adalah referensi untuk diperiksa sebelum Anda mengkomit seluruh perpustakaan ke satu format.

Periksa piksel terlebih dahulu. Foto 3840px adalah empat kali lebih lebar daripada kolom konten 960px yang akan ditampilkan, dan tidak ada codec yang memberikan kembali apa yang diberikan oleh pengubahan ukuran secara gratis, jadi pengubah ukuran dengan preset 25/50/75 adalah satu klik dan biasanya mengalahkan argumen format secara langsung. Tangga kualitas lebih penting daripada format juga. texture.jpg yang sama menjadi 212,4 KB pada 60 dan 131 KB pada 30, dan mode pintar menetap pada 286,1 KB, 47% lebih rendah, tanpa menanyakan apa pun kepada Anda.

Bagaimana cara menjalankan tes ini pada gambar saya sendiri?

Buka kompresor, masukkan foto Anda dan beralih ke manual. Pilih JPG, catat ukurannya. Alihkan dropdown format ke WebP pada slider yang sama dan catat angka itu. Kemudian tarik slider WebP ke bawah sampai kedua file berada dalam beberapa KB satu sama lain, dan lihat keduanya berdampingan dalam ukuran penuh, karena itu adalah satu-satunya perbandingan yang memberi tahu Anda sesuatu. Batch dibatasi pada 10 file dan 50 MB. Jika Anda lebih suka melewatkan slider sepenuhnya, JPG ke WebP mengkodekan pada kualitas tetap 80 tanpa pengubahan ukuran, WebP ke JPG kembali ke arah sebaliknya dengan transparansi yang dipadukan ke putih, dan panduan PDF mencakup satu konversi yang membuat file lebih besar.