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 kompromi antara ukuran file dan kualitas gambar. WebP biasanya mencapai rata-rata kompresi 30% lebih banyak daripada JPEG dan JPEG 2000, tanpa kehilangan kualitas gambar (lihat Studi Komparatif).

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

Browser web mana yang secara native mendukung WebP?

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

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

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

Negosiasi konten sisi server melalui header Terima

Biasanya klien web mengirim header permintaan "Accept", yang menunjukkan format konten yang ingin mereka terima sebagai respons. Jika browser sebelumnya mengindikasikan bahwa browser akan "menerima" format image/webp, server web akan mengetahui bahwa browser tersebut dapat dengan aman mengirim gambar WebP, sehingga sangat menyederhanakan negosiasi konten. Lihat link berikut untuk informasi lebih lanjut.

Modernisasi

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 diskusi ini tentang HTML5 Rocks. Elemen <picture> didukung oleh lebih banyak browser sepanjang waktu.

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 bersifat non-pemblokiran dan asinkron. Artinya, setiap kode yang bergantung pada dukungan WebP sebaiknya dimasukkan ke dalam fungsi callback.

Mengapa Google merilis WebP sebagai open source?

Kami sangat percaya akan pentingnya model open source. Dengan WebP dalam open source, siapa pun dapat menggunakan format tersebut dan menyarankan peningkatan. Dengan input dan saran Anda, kami yakin bahwa WebP akan menjadi lebih berguna sebagai format grafis seiring 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 image yang akan dikonversi, Anda dapat menggunakan shell platform untuk menyederhanakan operasi. Misalnya, untuk mengonversi semua file jpeg dalam 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. Untuk mendapatkan gambaran singkat tentang kualitas WebP, lihat Galeri di situs ini untuk mengetahui perbandingan foto secara berdampingan.

Bagaimana cara mendapatkan kode sumber?

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

Berapa ukuran maksimum gambar WebP?

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

Ruang warna apa saja yang didukung oleh format WebP?

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

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

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 ruang warna (YUV420 vs ARGB) dan konversi di antaranya.

Ada tiga situasi yang umum terjadi:

  1. Jika gambar sumber memiliki format ARGB lossless, pengurangan sampel spasial ke YUV420 akan memperkenalkan warna baru yang lebih sulit dikompresi daripada warna aslinya. Situasi ini biasanya dapat terjadi jika sumber menggunakan format PNG dengan sedikit warna: mengonversi ke WebP lossy (atau, mirip dengan JPEG lossy) berpotensi menghasilkan ukuran file yang lebih besar.
  2. Jika sumber 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.
  3. Jika sumbernya dalam format lossy, coba kompresi sebagai WebP lossy dengan setelan kualitas yang lebih tinggi. Misalnya, mencoba mengonversi file JPEG yang disimpan dengan kualitas 80 ke file WebP dengan kualitas 95 biasanya akan menghasilkan file yang lebih besar, meskipun kedua format tersebut lossy. Menilai kualitas sumber sering kali tidak memungkinkan, jadi sebaiknya turunkan kualitas WebP target jika ukuran file terus-menerus lebih besar. Kemungkinan lainnya adalah menghindari penggunaan setelan kualitas, dan menargetkan ukuran file tertentu menggunakan opsi -size dalam alat cwebp, atau API yang setara. Misalnya, menargetkan 80% ukuran file asli mungkin akan terbukti lebih efektif.

Perlu diketahui bahwa mengonversi sumber JPEG ke WebP lossy, atau sumber PNG ke WebP lossy tidak rentan terhadap kejutan ukuran file tersebut.

Apakah WebP mendukung tampilan progresif atau yang bertautan?

WebP tidak menawarkan refresh decoding progresif atau bertautan dalam arti JPEG atau PNG. Hal ini mungkin 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 baseline satu kali 3 kali.

Selain itu, WebP menawarkan decoding inkremental, dengan semua byte masuk yang tersedia dari bitstream digunakan untuk mencoba dan membuat baris contoh yang dapat ditampilkan sesegera mungkin. Tindakan ini akan menghemat memori, CPU, dan upaya pengecatan ulang pada klien sekaligus memberikan tanda visual tentang status download. Fitur decoding inkremental tersedia melalui Advanced Decoding API.

Bagaimana cara menggunakan binding Java libwebp di project Android saya?

WebP menyertakan 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 telah 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 Anda.

  6. Buka properti project lalu 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 kasus tersebut, beberapa langkah yang dijelaskan di atas dapat digunakan kembali.

Bagaimana cara menggunakan libwebp dengan C#?

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

  1. Buat 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 API sederhana, Anda harus memanggil WebPFree() untuk membebaskan 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?

Kelebihan WebP animasi dibandingkan dengan GIF animasi

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

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

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

  4. WebP membutuhkan lebih sedikit waktu untuk mendekode saat ada pencarian. Di Kedip, men-scroll atau mengubah tab dapat menyembunyikan dan menampilkan gambar, sehingga animasi akan dijeda lalu dilewati maju ke titik yang berbeda. Penggunaan CPU berlebihan yang menyebabkan animasi menurunnya frame juga dapat mengharuskan decoder untuk mencari maju dalam animasi. Dalam skenario ini, WebP animasi memerlukan total waktu dekode 0,57x lebih banyak2 sebagai GIF, sehingga mengurangi jank selama scrolling dan pemulihan yang lebih cepat dari lonjakan penggunaan CPU. Hal ini karena dua keunggulan WebP dibandingkan GIF:

    • Gambar WebP menyimpan metadata yang menunjukkan apakah setiap frame berisi alfa atau tidak, sehingga tidak perlu mendekode frame untuk menentukan hal ini. Hal ini menyebabkan inferensi yang lebih akurat terhadap frame sebelumnya yang menjadi dependensi frame tertentu, sehingga mengurangi decoding yang tidak perlu dari frame sebelumnya.

    • Mirip dengan encoder video modern, encoder WebP secara heuris menambahkan frame utama pada interval yang teratur (yang tidak dilakukan oleh sebagian besar encoder GIF). Hal ini meningkatkan pencarian dalam animasi panjang secara signifikan. Untuk memudahkan penyisipan frame tersebut tanpa meningkatkan ukuran gambar secara signifikan, WebP menambahkan tanda'metode penggabungan' untuk setiap frame selain metode pembuangan frame yang digunakan GIF. Hal ini memungkinkan keyframe untuk menggambar seolah-olah seluruh gambar telah dikosongkan ke warna latar belakang tanpa memaksa frame sebelumnya menjadi ukuran penuh.

Kekurangan WebP animasi dibandingkan dengan GIF animasi

  1. Jika tidak ada yang perlu melakukan pencarian, decoding garis lurus WebP akan lebih membebani CPU daripada GIF. lossy WebP memerlukan waktu dekode 2,2x lebih banyak daripada GIF, sedangkan WebP lossless memerlukan waktu 1,5x lebih banyak.

  2. Dukungan WebP tidak seluas dukungan GIF, yang pada dasarnya bersifat universal.

  3. Menambahkan dukungan WebP ke browser akan meningkatkan jejak kode dan permukaan serangan. Di Blink, diperlukan sekitar 1.500 baris kode tambahan (termasuk library demux WebP dan dekoder gambar WebP Sisi Blink). Perlu diperhatikan bahwa masalah ini dapat berkurang di masa mendatang jika WebP dan WebM berbagi kode decoding yang lebih umum, atau jika kemampuan WebP disertakan dalam WebM.

Mengapa tidak mendukung WebM di <img> saja?

Masuk akal dalam jangka panjang untuk mendukung format video di dalam tag <img>. Namun, melakukannya sekarang, dengan maksud bahwa 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 menampung 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 perlu menambahkan header penerimaan yang menunjukkan format yang didukung tag gambarnya. Meskipun ini mungkin tidak cukup, karena jenis MIME seperti "video/webm" atau "video/mpeg" tetap 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 penerimaan "image/webp" sudah digunakan untuk menunjukkan dukungan WebP, perubahan header penerimaan baru tidak diperlukan.

  3. Stack video Chromium dioptimalkan untuk pemutaran yang lancar, dan mengasumsikan hanya ada satu atau dua video yang diputar pada satu waktu. Akibatnya, implementasi tersebut agresif menghabiskan resource sistem (thread, memori, dll.) untuk memaksimalkan kualitas pemutaran. Implementasi seperti ini tidak diskalakan dengan baik untuk banyak video serentak dan perlu didesain ulang agar sesuai untuk digunakan pada halaman web yang sarat gambar.

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

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

2 Waktu dekode dihitung menggunakan libwebp + ToT Blink terbaru per 10/08/2013 menggunakan alat tolok ukur. "Waktu dekode dengan pencarian" dihitung sebagai "Mendekode 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) piksel. Untuk YUV 4:2:0, kita memerlukan 4 byte per 6 piksel (atau 3/2 byte per piksel). Jadi, frame referensi ini menggunakan 4*3/2*(width+96)*(height+96) byte memori. Di sisi lain, WebP hanya memerlukan frame sebelumnya (dalam RGBA), yaitu 4*width*height byte memori.

4 Rendering WebP animasi memerlukan Google Chrome versi 32+