Pertanyaan Umum (FAQ)

Apa itu WebP? Mengapa saya harus menggunakannya?

WebP adalah metode kompresi lossy dan lossless yang dapat digunakan pada berbagai gambar fotografi, tembus pandang, dan grafis yang ditemukan di web. Derajat kompresi lossy dapat disesuaikan sehingga pengguna dapat memilih kompromi antara ukuran file dan kualitas gambar. WebP biasanya mendapatkan kompresi rata-rata 30% lebih tinggi daripada JPEG dan JPEG 2000, tanpa kehilangan kualitas gambar (lihat Studi Perbandingan).

Format WebP pada dasarnya bertujuan untuk membuat gambar yang lebih kecil dan terlihat lebih baik yang dapat membantu membuat web lebih cepat.

Browser web mana yang secara native mendukung WebP?

Webmaster yang tertarik untuk meningkatkan performa situs dapat dengan mudah membuat alternatif WebP yang dioptimalkan untuk gambar saat ini, dan menayangkannya secara bertarget ke browser yang mendukung WebP.

  • Dukungan WebP WebP
    • Google Chrome (desktop) 17+
    • Google Chrome untuk Android versi 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 11.10+
    • Browser web native, Android 4.0+ (ICS)
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • Dukungan WebP lossy, lossless & amp; alpha
    • Google Chrome (desktop) 23+
    • Google Chrome untuk Android versi 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 12.10+
    • Browser web asli, Android 4.2+ (JB-MR1)
    • Pale Pale 26+
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • Dukungan WebP WebP
    • Google Chrome (desktop dan Android) 32+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 19+
    • Safari 14+ (iOS 14+, macOS Big Sur+)

Lihat juga:

Bagaimana cara mendeteksi dukungan browser untuk WebP?

Sebaiknya Anda hanya menayangkan gambar WebP ke klien yang dapat menampilkannya dengan benar, dan kembali ke format lama untuk klien yang tidak dapat menampilkannya. Untungnya ada beberapa teknik untuk mendeteksi dukungan WebP, baik di sisi klien dan sisi server. Beberapa penyedia CDN menawarkan deteksi dukungan WebP sebagai bagian dari layanan mereka.

Negosiasi konten sisi server melalui header Terima

Biasanya klien web mengirim header permintaan "Setuju", yang menunjukkan format konten mana yang bersedia mereka terima sebagai respons. Jika browser menunjukkan di awal bahwa browser akan "menerima" format image/webp, server web akan tahu bahwa browser tersebut dapat mengirim gambar WebP dengan aman, sehingga sangat menyederhanakan negosiasi konten. Lihat link berikut untuk informasi selengkapnya.

Modernizr

Modernizr adalah library JavaScript untuk mendeteksi dukungan fitur HTML5 dan CSS3 dengan mudah di browser web. Cari properti Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha, dan Modernizr.webp.animation.

Elemen <picture> HTML5

HTML5 mendukung elemen <picture>, yang memungkinkan Anda mencantumkan beberapa target gambar alternatif dalam urutan prioritas, sehingga klien akan meminta gambar kandidat pertama yang dapat ditampilkan dengan benar. Lihat pembahasan ini di HTML5 Rocks. Elemen <picture> didukung oleh lebih banyak browser sepanjang waktu.

Di JavaScript Anda sendiri

Metode deteksi lain adalah mencoba mendekode gambar WebP yang sangat kecil yang menggunakan fitur tertentu, dan memeriksa keberhasilannya. Contoh:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

Perhatikan bahwa pemuatan gambar bersifat non-pemblokiran dan asinkron. Ini berarti bahwa kode apa pun yang bergantung pada dukungan WebP sebaiknya dimasukkan ke dalam fungsi callback.

Mengapa Google merilis WebP sebagai open source?

Kami sangat yakin dengan pentingnya model open source. Dengan WebP dalam open source, siapa saja dapat menggunakan format ini dan menyarankan peningkatan. Dengan masukan dan saran Anda, kami yakin bahwa WebP akan menjadi lebih berguna sebagai format grafis dari waktu ke waktu.

Bagaimana cara mengonversi file gambar pribadi saya ke WebP?

Anda dapat menggunakan utilitas command line WebP untuk mengonversi file gambar pribadi ke format WebP. Lihat Menggunakan WebP untuk detail selengkapnya.

Jika memiliki banyak gambar untuk dikonversi, Anda dapat menggunakan shell platform untuk menyederhanakan operasi. Misalnya, untuk mengonversi semua file jpeg dalam satu folder, coba langkah berikut:

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Bagaimana cara menilai kualitas gambar WebP untuk diri sendiri?

Saat ini, Anda dapat melihat file WebP dengan mengonversinya ke dalam format umum yang menggunakan kompresi lossless, seperti PNG, lalu melihat file PNG di browser atau penampil gambar apa pun. Untuk mendapatkan gambaran singkat tentang kualitas WebP, lihat Galeri di situs ini untuk perbandingan foto secara berdampingan.

Bagaimana cara mendapatkan kode sumber?

Kode konverter tersedia di bagian download halaman project open source WebP. Kode untuk decoder ringan dan spesifikasi VP8 ada di situs WebM. Lihat halaman Penampung RIFF untuk spesifikasi penampung.

Berapa ukuran maksimum gambar WebP?

WebP kompatibel dengan bitstream dengan VP8 dan menggunakan lebar dan tinggi 14 bit. Dimensi piksel maksimum gambar WebP adalah 16383 x 16383.

Ruang warna apa yang didukung format WebP?

Sesuai dengan bitstream VP8, lossy WebP berfungsi secara eksklusif dengan format gambar Y'CbCr 4:2:0 8 bit (sering disebut YUV420). Lihat Bagian 2, "Ringkasan Format" dari RFC 6386, Panduan Format dan Dekode VP8 untuk detail selengkapnya.

Lossless WebP berfungsi secara eksklusif dengan format RGBA. Lihat spesifikasi Bitstream lossless WebP.

Dapatkah gambar WebP tumbuh lebih besar dari gambar sumbernya?

Ya, biasanya saat mengonversi dari format lossy ke WebP lossless atau sebaliknya. Hal ini terutama disebabkan oleh perbedaan warna (YUV420 vs ARGB) dan konversi di antara keduanya.

Ada tiga situasi umum:

  1. Jika gambar sumber dalam format ARGB lossless, downsampling spasial ke YUV420 akan memperkenalkan warna baru yang lebih sulit dikompresi daripada yang asli. Situasi ini biasanya dapat terjadi jika sumber dalam format PNG dengan sedikit warna: mengonversi ke WebP lossy (atau, serupa dengan JPEG lossy), berpotensi menghasilkan ukuran file yang lebih besar.
  2. Jika sumbernya dalam format lossy, menggunakan kompresi WebP lossless untuk menangkap sifat lossy dari sumber biasanya akan menghasilkan file yang lebih besar. Hal ini tidak khusus untuk WebP dan dapat terjadi saat mengonversi sumber JPEG menjadi format WebP atau PNG lossless.
  3. Jika sumbernya dalam format lossy dan Anda mencoba mengompresinya sebagai WebP lossy dengan setelan kualitas yang lebih tinggi. Misalnya, mencoba mengonversi file JPEG yang disimpan dalam kualitas 80 menjadi file WebP dengan kualitas 95 biasanya akan menghasilkan file yang lebih besar, meskipun kedua format tersebut bersifat lossy. Menilai kualitas sumber sering kali tidak mungkin dilakukan, jadi sebaiknya turunkan kualitas WebP target jika ukuran filenya lebih besar secara konsisten. Kemungkinan lainnya adalah menghindari penggunaan setelan kualitas, dan menargetkan ukuran file tertentu menggunakan opsi -size di alat cwebp, atau API yang setara. Misalnya, menargetkan 80% ukuran file asli mungkin terbukti lebih andal.

Perhatikan bahwa mengonversi sumber JPEG menjadi WebP lossy, atau sumber PNG ke WebP lossless tidak rentan terhadap kejutan ukuran file tersebut.

Apakah WebP mendukung tampilan progresif atau bertautan?

WebP tidak menawarkan refresh decoding progresif atau yang bertautan dalam cara JPEG atau PNG. Hal ini mungkin akan memberikan terlalu banyak tekanan pada CPU dan memori klien dekode karena setiap peristiwa pemuatan ulang melibatkan penerusan penuh melalui sistem dekompresi.

Rata-rata, mendekode gambar JPEG progresif sama dengan mendekode dasar pengukuran satu kali 3 kali.

Selain itu, WebP menawarkan decoding inkremental, tempat semua byte masuk yang tersedia dari bitstream digunakan untuk mencoba dan menghasilkan baris sampel yang dapat ditampilkan sesegera mungkin. Ini akan menghemat upaya memori, CPU, dan re-paint pada klien sekaligus memberikan isyarat visual tentang status download. Fitur decoding tambahan tersedia melalui Advanced Decoding API.

Bagaimana cara menggunakan binding Java libwebp di project Android saya?

WebP mencakup dukungan untuk binding JNI ke antarmuka encoder dan decoder sederhana di direktori swig/.

Membuat library di Eclipse:

  1. Pastikan Anda telah menginstal plugin ADT bersama dengan alat NDK dan jalur NDK Anda ditetapkan dengan benar (Preferensi > Android > NDK).
  2. Buat project baru: File > New > Project > Android Application Project.
  3. Lakukan clone atau ekstrak libwebp ke folder bernama jni dalam project baru.
  4. Tambahkan swig/libwebp_java_wrap.c ke daftar LOCAL_SRC_FILES.
  5. Klik kanan project baru dan pilih Android Tools > Add Native Support ... untuk menyertakan library dalam build.

  6. Buka properti project dan buka C/C++ Build > Behaviour. Tambahkan ENABLE_SHARED=1 ke bagian Build (Incremental build) untuk mem-build libwebp sebagai library bersama.

    Catatan Menetapkan NDK_TOOLCHAIN_VERSION=4.8 secara umum akan meningkatkan performa build 32-bit.

  7. Tambahkan swig/libwebp.jar ke folder project libs/.

  8. Build project Anda. Tindakan ini akan membuat libs/<target-arch>/libwebp.so.

  9. Gunakan System.loadLibrary("webp") untuk memuat library saat runtime.

Perhatikan bahwa library dapat dibuat secara manual dengan ndk-build dan Android.mk yang disertakan. Dalam beberapa kasus, beberapa langkah yang dijelaskan di atas dapat digunakan kembali.

Bagaimana cara menggunakan libwebp dengan C#?

WebP dapat dibuat sebagai DLL yang mengekspor libwebp API. Fungsi ini kemudian dapat diimpor di C#.

  1. Bangun libwebp.dll. Tindakan ini akan menyetel WEBP_EXTERN dengan benar untuk mengekspor fungsi API.

    libwebp> nmake /f Makefile.vc CFG=release-dynamic

  2. Tambahkan libwebp.dll ke project Anda dan impor fungsi yang diinginkan. Perhatikan bahwa jika menggunakan API sederhana, Anda harus memanggil WebPFree() untuk mengosongkan buffer yang ditampilkan.

    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Mengapa saya harus menggunakan WebP animasi?

Keunggulan WebP animasi dibandingkan GIF animasi

  1. WebP mendukung warna RGB 24-bit dengan saluran alfa 8-bit, dibandingkan dengan warna 8-bit dan alfa 1-bit GIF.

  2. WebP mendukung kompresi lossy dan lossless; bahkan, satu animasi dapat menggabungkan frame lossy dan lossless. GIF hanya mendukung kompresi lossless. Teknik kompresi WebP WebP sangat cocok untuk gambar animasi yang dibuat dari video dunia nyata, yaitu sumber gambar animasi yang semakin populer.

  3. WebP membutuhkan byte yang lebih sedikit daripada GIF1. GIF animasi yang dikonversi ke WebP lossy berukuran 64% lebih kecil, sedangkan WebP lossless berukuran 19% lebih kecil. Hal ini sangat penting pada jaringan seluler.

  4. WebP membutuhkan waktu yang lebih singkat untuk mendekode dengan adanya pencarian. Di Blink, scroll atau mengubah tab dapat menyembunyikan dan menampilkan gambar, sehingga animasi dijeda, lalu dilewati ke titik yang berbeda. Penggunaan CPU yang berlebihan yang mengakibatkan animasi melepaskan frame juga dapat mengharuskan decoder untuk mencari maju dalam animasi. Dalam skenario ini, WebP animasi membutuhkan waktu dekode total 0,57x lebih banyak2 daripada GIF, sehingga menghasilkan lebih sedikit jank selama scroll dan pemulihan yang lebih cepat dari lonjakan penggunaan CPU. Hal ini terjadi karena dua keunggulan WebP dibandingkan GIF:

    • Gambar WebP menyimpan metadata tentang apakah setiap frame berisi alfa, sehingga tidak perlu mendekode frame untuk membuat penentuan ini. Hal ini menyebabkan inferensi yang lebih akurat terkait frame sebelumnya yang menjadi dependensi frame tertentu, sehingga mengurangi decoding yang tidak perlu dari frame sebelumnya.

    • Sama seperti encoder video modern, encoder WebP secara heuristik menambahkan frame utama secara berkala (yang tidak dilakukan oleh sebagian besar encoder GIF). Ini secara dramatis meningkatkan pencarian dalam animasi panjang. Untuk memudahkan penyisipan frame tersebut tanpa meningkatkan ukuran gambar secara signifikan, WebP menambahkan flag 'metode blender' untuk setiap frame selain metode pembuangan frame yang digunakan GIF. Hal ini memungkinkan keyframe untuk menggambar seolah-olah seluruh gambar telah dihapus ke warna latar belakang tanpa memaksa frame sebelumnya menjadi ukuran penuh.

Kekurangan WebP animasi dibandingkan dengan GIF animasi

  1. Jika tidak ada pencarian, decoding garis lurus WebP lebih intensif CPU daripada GIF. WebP lossless membutuhkan waktu dekode 2,2 kali lebih banyak daripada GIF, sedangkan WebP lossless membutuhkan 1,5x lebih banyak.

  2. Dukungan WebP hampir tidak sama luasnya dengan dukungan GIF, yang pada dasarnya bersifat universal.

  3. Menambahkan dukungan WebP ke browser akan meningkatkan jejak kode dan permukaan serangan. Di Blink, link ini berisi sekitar 1500 baris kode tambahan (termasuk library demux WebP dan dekoder WebP sisi Blink). Perlu diketahui bahwa masalah ini dapat dikurangi di masa mendatang jika WebP dan WebM berbagi kode decoding yang lebih umum, atau jika kemampuan WebP disertakan di WebM.

Mengapa tidak mendukung WebM di <img> saja?

Sebaiknya gunakan format video dalam tag <img> dalam jangka panjang. Namun, melakukannya sekarang, dengan maksud agar WebM di <img> dapat mengisi peran yang diusulkan oleh WebP animasi, menjadi masalah:

  1. Saat mendekode frame yang mengandalkan frame sebelumnya, WebM memerlukan memori 50% lebih banyak daripada WebP animasi untuk mempertahankan jumlah minimum frame sebelumnya3.

  2. Dukungan codec dan penampung video sangat bervariasi di berbagai browser dan perangkat. Untuk memfasilitasi transcoding konten otomatis (misalnya untuk proxy penghematan bandwidth), browser harus menambahkan header penerimaan yang menunjukkan format yang didukung oleh tag gambarnya. Meskipun ini mungkin tidak cukup, karena jenis MIME seperti "video/webm" atau "video/mpeg" masih tidak menunjukkan dukungan codec (misalnya, VP8 vs. VP9). Di sisi lain, format WebP dibekukan secara efektif, dan jika vendor yang mengirimkannya setuju untuk mengirimkan WebP animasi, perilaku WebP di semua UA harus konsisten; dan karena header penerimaan "image/webp" sudah digunakan untuk menunjukkan dukungan WebP, tidak ada perubahan header header baru yang diperlukan.

  3. Tumpukan video Chromium dioptimalkan untuk pemutaran yang lancar, dan menganggap hanya ada satu atau dua video yang diputar pada satu waktu. Akibatnya, implementasi sangat agresif dalam menggunakan resource sistem (thread, memori, dll.) untuk memaksimalkan kualitas pemutaran. Penerapan tersebut tidak sesuai untuk banyak video secara bersamaan dan harus didesain ulang agar sesuai untuk digunakan dengan halaman web yang berisi banyak gambar.

  4. WebM saat ini tidak menggabungkan semua teknik kompresi dari WebP. Karena itu, gambar ini mengompresi secara signifikan lebih baik dengan WebP daripada alternatifnya:

1 Untuk semua perbandingan antara GIF animasi dan WebP animasi, kami menggunakan korpus sekitar 7.000 gambar GIF animasi yang diambil secara acak dari web. Gambar ini dikonversi ke WebP animasi menggunakan alat 'gif2webp' menggunakan setelan default (yang dibuat dari hierarki sumber libwebp terbaru per 08/10/2013). Angka komparatif adalah nilai rata-rata di semua gambar ini.

2 Waktu dekode dihitung menggunakan libwebp terbaru + ToT Blink per 08/10/2013 menggunakan alat benchmark. "Waktu dekode dengan pencarian" dihitung sebagai "Dekode lima frame pertama, menghapus cache buffer frame, mendekode lima frame berikutnya, dan seterusnya".

3 WebM menyimpan 4 frame referensi YUV di memori, dengan setiap penyimpanan frame (lebar+96)*(tinggi+96). Untuk YUV 4:2:0, kita memerlukan 4 byte per 6 piksel (atau 3/2 byte per piksel). Jadi, frame referensi ini menggunakan memori 4*3/2*(width+96)*(height+96) byte. Di sisi lain, WebP hanya memerlukan frame sebelumnya (dalam RGBA) yang tersedia, yaitu memori 4*width*height byte.

4 Rendering WebP animasi memerlukan Google Chrome versi 32+