Pertanyaan Umum (FAQ)

Apa itu WebP? Mengapa saya harus menggunakannya?

WebP adalah metode kompresi lossy dan lossless yang dapat digunakan pada berbagai macam gambar fotografi, transparan, dan grafis yang ditemukan di web. Tingkat kompresi lossy dapat disesuaikan sehingga pengguna dapat memilih keseimbangan antara ukuran file dan kualitas gambar. WebP biasanya mencapai kompresi rata-rata 30% lebih banyak daripada JPEG dan JPEG 2000, tanpa kehilangan kualitas gambar (lihat Studi Komparatif).

Pada dasarnya, format WebP bertujuan untuk membuat gambar yang lebih kecil dan terlihat lebih baik yang dapat membantu membuat web lebih cepat.

Browser web mana yang mendukung WebP secara native?

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 lossy WebP
    • Google Chrome (desktop) 17+
    • Google Chrome untuk Android versi 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 11.10+
    • Browser web bawaan, Android 4.0+ (ICS)
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • Dukungan WebP lossy, lossless & alfa
    • Google Chrome (desktop) 23+
    • Google Chrome untuk Android versi 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 12.10+
    • Browser web bawaan, Android 4.2+ (JB-MR1)
    • Pale Moon 26+
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • Dukungan Animasi 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?

Anda hanya ingin 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 maupun sisi server. Beberapa penyedia CDN menawarkan deteksi dukungan WebP sebagai bagian dari layanan mereka.

Negosiasi konten sisi server melalui header Accept

Klien web biasanya mengirim header permintaan "Accept", yang menunjukkan format konten yang bersedia mereka terima sebagai respons. Jika browser menunjukkan sebelumnya bahwa browser akan "menerima" format image/webp, server web mengetahui bahwa server dapat mengirim gambar WebP dengan aman, sehingga sangat menyederhanakan negosiasi konten. Lihat link berikut untuk mengetahui informasi selengkapnya.

Modernizr

Modernizr adalah library JavaScript untuk mendeteksi dukungan fitur HTML5 dan CSS3 di browser web dengan mudah. 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 diskusi ini di HTML5 Rocks. Elemen <picture> didukung oleh lebih banyak browser setiap saat.

Di JavaScript Anda sendiri

Metode deteksi lainnya 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 tidak memblokir dan bersifat asinkron. Artinya, kode apa pun yang bergantung pada dukungan WebP sebaiknya dimasukkan ke dalam fungsi callback.

Mengapa Google merilis WebP sebagai open source?

Kami sangat meyakini pentingnya model open source. Dengan WebP di open source, siapa pun dapat menggunakan format ini dan menyarankan peningkatan. Dengan masukan dan saran Anda, kami yakin bahwa WebP akan menjadi format grafis yang lebih berguna 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 Anda ke format WebP. Lihat Menggunakan WebP untuk mengetahui detail selengkapnya.

Jika memiliki banyak gambar yang akan dikonversi, Anda dapat menggunakan shell platform untuk menyederhanakan operasi. Misalnya, untuk mengonversi semua file jpeg dalam folder, coba yang 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 sendiri?

Saat ini, Anda dapat melihat file WebP dengan mengonversinya ke format umum yang menggunakan kompresi tanpa kehilangan data, seperti PNG, lalu melihat file PNG di browser atau penampil gambar mana pun. Untuk mendapatkan gambaran cepat tentang kualitas WebP, lihat Galeri di situs ini untuk perbandingan foto berdampingan.

Bagaimana cara mendapatkan kode sumber?

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

Berapa ukuran maksimum gambar WebP?

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

Ruang warna apa yang didukung format WebP?

Sesuai dengan bitstream VP8, WebP lossy hanya berfungsi dengan format gambar Y'CbCr 4:2:0 8-bit (sering disebut YUV420). Lihat Bagian 2, "Format Overview" dari RFC 6386, VP8 Data Format and Decoding Guide untuk mengetahui detail selengkapnya.

WebP Lossless hanya berfungsi dengan format RGBA. Lihat spesifikasi Bitstream Lossless WebP.

Mengapa file WebP lossless saya berbeda dari file aslinya?

Fungsi Simple Encoding API (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) menggunakan setelan default library. Untuk lossless, berarti 'exact' dinonaktifkan. Nilai RGB di area yang sepenuhnya transparan (yaitu, area dengan nilai alfa yang sama dengan 0) akan diubah untuk meningkatkan kompresi. Untuk menghindarinya, gunakan WebPEncode() dan tetapkan WebPConfig::exact ke 1. Lihat dokumentasi Advanced Encoding API.

Dapatkah gambar WebP menjadi lebih besar daripada gambar sumbernya?

Ya, biasanya saat mengonversi dari format lossy ke WebP lossless atau sebaliknya. Hal ini terutama disebabkan oleh perbedaan ruang 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 warna aslinya. Situasi ini biasanya dapat terjadi saat 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 sumber biasanya akan menghasilkan file yang lebih besar. Hal ini tidak khusus untuk WebP, dan dapat terjadi saat mengonversi sumber JPEG ke format WebP atau PNG lossless, misalnya.
  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 dengan 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 file selalu lebih besar. Kemungkinan lain adalah menghindari penggunaan setelan kualitas, dan sebagai gantinya, 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 ke WebP lossy, atau sumber PNG ke WebP lossless tidak rentan terhadap kejutan ukuran file tersebut.

Apakah WebP mendukung tampilan progresif atau saling bertautan?

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

Rata-rata, mendekode gambar JPEG progresif setara dengan mendekode gambar dasar pengukuran sebanyak 3 kali.

Atau, WebP menawarkan decoding inkremental, di mana semua byte bitstream masuk yang tersedia digunakan untuk mencoba dan menghasilkan baris sampel yang dapat ditampilkan sesegera mungkin. Hal ini menghemat memori, CPU, dan upaya pengecatan ulang di klien sekaligus memberikan petunjuk visual tentang status download. Fitur decoding inkremental 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/.

Membangun library di Eclipse:

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

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

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

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

  8. Bangun 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 di-build secara manual dengan ndk-build dan Android.mk yang disertakan. Beberapa langkah yang dijelaskan di atas dapat digunakan kembali dalam kasus tersebut.

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 Anda menggunakan simple API, 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 dengan 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 tanpa kehilangan data. Teknik kompresi lossy WebP sangat cocok untuk gambar animasi yang dibuat dari video dunia nyata, yang merupakan sumber gambar animasi yang semakin populer.

  3. WebP memerlukan byte yang lebih sedikit daripada GIF1. GIF animasi yang dikonversi menjadi WebP lossy berukuran 64% lebih kecil, sedangkan WebP lossless berukuran 19% lebih kecil. Hal ini terutama penting di jaringan seluler.

  4. WebP memerlukan lebih sedikit waktu untuk didekode saat ada pencarian. Di Blink, men-scroll atau mengubah tab dapat menyembunyikan dan menampilkan gambar, sehingga animasi dijeda lalu dilanjutkan ke titik yang berbeda. Penggunaan CPU yang berlebihan yang menyebabkan animasi mengalami penurunan frame juga dapat mengharuskan dekoder mencari ke depan dalam animasi. Dalam skenario ini, WebP animasi membutuhkan total waktu dekode 0,57x lebih banyak2 daripada GIF, sehingga menghasilkan lebih sedikit jank selama men-scroll dan pemulihan yang lebih cepat dari lonjakan penggunaan CPU. Hal ini disebabkan oleh dua keunggulan WebP dibandingkan GIF:

    • Gambar WebP menyimpan metadata tentang apakah setiap frame berisi alfa atau tidak, sehingga tidak perlu mendekode frame untuk menentukan hal ini. Hal ini menghasilkan inferensi yang lebih akurat tentang frame sebelumnya yang menjadi dasar suatu frame, sehingga mengurangi decoding yang tidak perlu pada frame sebelumnya.

    • Seperti encoder video modern, encoder WebP secara heuristik menambahkan frame utama secara berkala (yang tidak dilakukan oleh sebagian besar encoder GIF). Hal ini meningkatkan kualitas pencarian dalam animasi panjang secara signifikan. Untuk memfasilitasi penyisipan frame tersebut tanpa meningkatkan ukuran gambar secara signifikan, WebP menambahkan tanda 'metode penggabungan' untuk setiap frame selain metode pelepasan frame yang digunakan GIF. Hal ini memungkinkan keyframe digambar seolah-olah seluruh gambar telah dihapus ke warna latar belakang tanpa memaksa frame sebelumnya berukuran penuh.

Kekurangan WebP animasi dibandingkan dengan GIF animasi

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

  2. Dukungan WebP tidak seluas dukungan GIF, yang secara efektif bersifat universal.

  3. Menambahkan dukungan WebP ke browser akan meningkatkan jejak kode dan permukaan serangan. Di Blink, ini adalah sekitar 1.500 baris kode tambahan (termasuk library demux WebP dan decoder gambar WebP sisi Blink). Perhatikan bahwa masalah ini dapat dikurangi pada masa mendatang jika WebP dan WebM berbagi kode decoding yang lebih umum, atau jika kemampuan WebP tercakup dalam WebM.

Mengapa tidak mendukung WebM di <img>?

Dalam jangka panjang, mendukung format video di dalam tag <img> mungkin akan lebih masuk akal. Namun, melakukannya sekarang, dengan maksud agar WebM di <img> dapat mengisi peran WebP animasi yang diusulkan, bermasalah:

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

  2. Dukungan codec dan penampung video sangat bervariasi di berbagai browser dan perangkat. Untuk memfasilitasi transkode konten otomatis (misalnya, untuk proxy penghemat bandwidth), browser perlu menambahkan header terima yang menunjukkan format yang didukung tag gambar mereka. Bahkan 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 secara efektif dibekukan, dan jika vendor yang mengirimkannya setuju untuk mengirimkan WebP animasi, perilaku WebP di semua UA harus konsisten; dan karena header terima "image/webp" sudah digunakan untuk menunjukkan dukungan WebP, tidak ada perubahan header terima baru yang diperlukan.

  3. Stack video Chromium dioptimalkan untuk pemutaran yang lancar, dan mengasumsikan hanya ada satu atau dua video yang diputar dalam satu waktu. Akibatnya, penerapan ini agresif dalam mengonsumsi resource sistem (thread, memori, dll.) untuk memaksimalkan kualitas pemutaran. Penerapan seperti itu tidak dapat diskalakan dengan baik untuk banyak video simultan dan perlu didesain ulang agar sesuai untuk digunakan dengan halaman web yang berisi banyak gambar.

  4. Saat ini, WebM tidak menggabungkan semua teknik kompresi dari WebP. Hasilnya, gambar ini dikompresi jauh 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 menjadi WebP animasi menggunakan alat 'gif2webp' dengan setelan default (dibuat dari struktur sumber libwebp terbaru pada 10/08/2013). Angka perbandingan adalah nilai rata-rata di seluruh gambar ini.

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

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

4 Rendering WebP animasi memerlukan Google Chrome versi 32+