Se usó la API de Cloud Translation para traducir esta página.

Preguntas frecuentes

¿Qué es WebP? ¿Por qué debería usarla?

WebP es un método de compresión con y sin pérdida que se puede usar en una gran variedad de imágenes fotográficas, translúcidas y gráficas que se encuentran en la Web. El grado de compresión con pérdida es ajustable para que el usuario pueda elegir la compensación entre el tamaño del archivo y la calidad de la imagen. Por lo general, WebP logra un 30% más de compresión que JPEG y JPEG 2000, sin pérdida en la calidad de la imagen (consulta Estudio comparativo).

El formato WebP básicamente tiene como objetivo crear imágenes más pequeñas y atractivas que puedan ayudar a que la Web sea más rápida.

¿Qué navegadores web tienen compatibilidad nativa con WebP?

Los webmasters que deseen mejorar el rendimiento del sitio pueden crear fácilmente alternativas de WebP optimizadas para sus imágenes actuales y publicarlas de forma específica para navegadores compatibles con WebP.

Compatibilidad con WebP con pérdida
- Google Chrome (computadoras de escritorio) 17 y versiones posteriores
- Google Chrome para Android, versión 25 o posterior
- Microsoft Edge 18 y versiones posteriores
- Firefox 65 y versiones posteriores
- Opera 11.10 y versiones posteriores
- Navegador web nativo, Android 4.0 y versiones posteriores (ICS)
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur+)
Compatibilidad de WebP con pérdida, sin pérdida y alfa
- Google Chrome (computadoras de escritorio) 23 y versiones posteriores
- Google Chrome para Android, versión 25 o posterior
- Microsoft Edge 18 y versiones posteriores
- Firefox 65 y versiones posteriores
- Opera 12.10 y versiones posteriores
- Navegador web nativo con Android 4.2 y versiones posteriores (JB-MR1)
- Luna pálida 26+
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur+)
Compatibilidad con animaciones WebP
- Google Chrome (computadoras de escritorio y Android) 32 y versiones posteriores
- Microsoft Edge 18 y versiones posteriores
- Firefox 65 y versiones posteriores
- Ópera 19 y versiones posteriores
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur+)

Consulta lo siguiente:

¿Cómo puedo detectar la compatibilidad del navegador con WebP?

Querrás entregar imágenes WebP solo a los clientes que puedan mostrarlas de manera correcta y recurrir a los formatos heredados para los clientes que no puedan hacerlo. Afortunadamente, existen varias técnicas para detectar la compatibilidad con WebP en el cliente y en el servidor. Algunos proveedores de CDN ofrecen detección de compatibilidad con WebP como parte de su servicio.

Negociación de contenido del servidor mediante encabezados Aceptar

Es común que los clientes web envíen un encabezado de solicitud "Aceptar", que indica qué formatos de contenido están dispuestos a aceptar como respuesta. Si un navegador indica de antemano que "aceptará" el formato image/webp, el servidor web sabrá que puede enviar imágenes WebP de forma segura, lo que simplifica en gran medida la negociación de contenido. Consulta los siguientes vínculos para obtener más información.

Modernizr

Modernizr es una biblioteca de JavaScript para detectar de forma conveniente la compatibilidad con funciones HTML5 y CSS3 en navegadores web. Busca las propiedades Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha y Modernizr.webp.animation.

Elemento HTML5 `<picture>`

HTML5 admite un elemento <picture>, que te permite enumerar varias imágenes objetivo alternativas en orden de prioridad, de modo que un cliente solicite la primera imagen candidata para que se muestre correctamente. Consulta este debate sobre HTML5 Rocks. El elemento <picture> es compatible con más navegadores todo el tiempo.

En tu propio JavaScript

Otro método de detección consiste en intentar decodificar una imagen WebP muy pequeña que use una función en particular y verificar si funciona. Ejemplo:

// 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];
}

Ten en cuenta que la carga de imágenes no genera bloqueos y es asíncrona. Esto significa que cualquier código que dependa de la compatibilidad con WebP preferentemente debe colocarse en la función de devolución de llamada.

¿Por qué Google lanzó WebP como de código abierto?

Creemos profundamente en la importancia del modelo de código abierto. Con WebP en código abierto, cualquier persona puede trabajar con el formato y sugerir mejoras. Con tus entradas y sugerencias, creemos que WebP se volverá aún más útil como formato gráfico con el paso del tiempo.

¿Cómo puedo convertir mis archivos de imágenes personales a WebP?

Puedes usar la utilidad de línea de comandos de WebP para convertir tus archivos de imagen personales al formato WebP. Consulta Cómo usar WebP para obtener más información.

Si tienes que convertir muchas imágenes, puedes usar la shell de tu plataforma para simplificar la operación. Por ejemplo, para convertir todos los archivos jpeg en una carpeta, intenta lo siguiente:

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

¿Cómo puedo evaluar la calidad de imagen WebP por mí mismo?

Actualmente, puedes ver archivos WebP convirtiéndolos a un formato común que utiliza una compresión sin pérdidas, como PNG, y, luego, ver los archivos PNG en cualquier navegador o visor de imágenes. Para tener una idea rápida de la calidad de WebP, consulta la Galería en este sitio para comparar fotos en paralelo.

¿Cómo obtengo el código fuente?

El código del conversor está disponible en la sección de descargas de la página del proyecto de código abierto de WebP. El código del decodificador ligero y la especificación de VP8 están en el sitio de WebM. Consulta la página Contenedor de RIFF para obtener la especificación del contenedor.

¿Cuál es el tamaño máximo de una imagen WebP?

WebP es compatible con VP8 y usa 14 bits para el ancho y la altura. La dimensión máxima de píxeles de una imagen WebP es de 16,383 x 16,383.

¿Qué espacios de color admite el formato WebP?

De acuerdo con el flujo de bits de VP8, WebP con pérdida funciona exclusivamente con un formato de imagen Y'CbCr de 8 bits de 4:2:0 (a menudo llamado YUV420). Consulta la sección 2, “Descripción general del formato” de RFC 6386, Guía de formato de datos y decodificación de VP8 para obtener más detalles.

El formato WebP sin pérdidas funciona exclusivamente con el formato RGBA. Consulta la especificación de transmisión de bits sin pérdida de WebP.

¿Puede una imagen WebP crecer más que su imagen de origen?

Sí. Por lo general, cuando se convierte de un formato con pérdida a WebP sin pérdida, o viceversa. Esto se debe principalmente a la diferencia de espacio de color (YUV420 frente a ARGB) y a la conversión entre estos.

Hay tres situaciones típicas:

Si la imagen de origen está en formato ARGB sin pérdida, la reducción de muestreo espacial a YUV420 introducirá colores nuevos que son más difíciles de comprimir que los originales. Por lo general, esto puede ocurrir cuando la fuente está en formato PNG con pocos colores: la conversión a WebP con pérdida (o, de manera similar a un JPEG con pérdida), puede generar un tamaño de archivo mayor.
Si la fuente está en formato con pérdida, el uso de la compresión de WebP sin pérdida para capturar la naturaleza con pérdida de la fuente generalmente dará como resultado un archivo más grande. Esto no es particular para WebP y puede ocurrir cuando se convierte una fuente JPEG a formatos WebP o PNG sin pérdida, por ejemplo.
Si la fuente está en formato con pérdida y intentas comprimirlo como un WebP con pérdida y una configuración de mayor calidad. Por ejemplo, si intentas convertir un archivo JPEG guardado en calidad 80 en un archivo WebP con calidad 95, el resultado será un archivo más grande, incluso si ambos formatos tienen pérdida. A menudo, resulta imposible evaluar la calidad de la fuente, por lo que se recomienda reducir la calidad WebP de destino si el tamaño del archivo es constantemente mayor. Otra posibilidad es evitar el uso de la configuración de calidad y, en su lugar, orientar a un tamaño de archivo determinado mediante la opción -size en la herramienta de cwebp o la API equivalente. Por ejemplo, orientarse al 80% del tamaño original del archivo podría ser más sólido.

Ten en cuenta que la conversión de una fuente JPEG a WebP con pérdida o de una fuente de PNG a WebP sin pérdida no suele darse sorpresas en el tamaño de los archivos.

¿WebP admite pantallas progresivas o entrelazadas?

WebP no ofrece una actualización de decodificación progresiva o entrelazada en el sentido de JPEG o PNG. Es probable que esto aplique demasiada presión a la CPU y la memoria del cliente de decodificación, ya que cada evento de actualización implica un pase completo por el sistema de descompresión.

En promedio, la decodificación de una imagen JPEG progresiva equivale a decodificar el modelo de referencia 3 veces.

Como alternativa, WebP ofrece decodificación incremental, en la que todos los bytes entrantes disponibles del flujo de bits se usan para intentar producir una fila de muestra que se pueda mostrar lo antes posible. Esto ahorra memoria, CPU y esfuerzo de volver a pintar en el cliente, a la vez que proporciona señales visuales sobre el estado de la descarga. La función de decodificación incremental está disponible a través de la API de Decodificación avanzada.

¿Cómo uso las vinculaciones de Java libwebp en mi proyecto de Android?

WebP incluye compatibilidad con vinculaciones de JNI con interfaces simples de codificador y decodificador del directorio swig/.

Compila la biblioteca en Eclipse:

Asegúrate de tener el complemento ADT instalado junto con las herramientas del NDK y de que la ruta del NDK esté configurada correctamente (Preferences > Android > NDK).
Crea un proyecto nuevo: File > New > Project > Android Application Project.
Clona o descomprime libwebp en una carpeta llamada jni en el proyecto nuevo.
Agrega swig/libwebp_java_wrap.c a la lista LOCAL_SRC_FILES.
Haz clic con el botón derecho en el proyecto nuevo y selecciona Android Tools > Add Native Support ... para incluir la biblioteca en tu compilación.
Abre las propiedades del proyecto y ve a Compilación de C/C++ > Comportamiento. Se agregó ENABLE_SHARED=1 a la sección Build (Incremental build) para compilar libwebp como una biblioteca compartida.

Nota: En general, configurar NDK_TOOLCHAIN_VERSION=4.8 mejorará el rendimiento de la compilación de 32 bits.
Agrega swig/libwebp.jar a la carpeta del proyecto libs/.
Compila tu proyecto. Esto creará libs/<target-arch>/libwebp.so.
Usa System.loadLibrary("webp") para cargar la biblioteca durante el tiempo de ejecución.

Ten en cuenta que la biblioteca se puede compilar manualmente con ndk-build y el Android.mk incluido. Algunos de los pasos descritos anteriormente se pueden volver a usar en ese caso.

¿Cómo uso libwebp con C#?

WebP se puede compilar como una DLL que exporta la API de libwebp. Estas funciones luego se pueden importar en C#.

Compila libwebp.dll. Esto configurará WEBP_EXTERN correctamente para exportar las funciones de la API.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Agrega libwebp.dll a tu proyecto y, luego, importa las funciones deseadas. Ten en cuenta que, si usas la API simple, debes llamar a WebPFree() para liberar cualquier búfer que se muestre.

[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);
}

¿Por qué debería usar WebP animado?

Ventajas de los archivos WebP animados en comparación con los GIF animados

WebP admite color RGB de 24 bits con un canal alfa de 8 bits, en comparación con el color de 8 bits de GIF y el canal alfa de 1 bit.
WebP es compatible con la compresión con y sin pérdida. De hecho, una sola animación puede combinar fotogramas con y sin pérdida. GIF solo admite la compresión sin pérdidas. Las técnicas de compresión con pérdida de WebP son adecuadas para imágenes animadas creadas a partir de videos reales, una fuente cada vez más popular de imágenes animadas.
WebP requiere menos bytes que en formato GIF¹. Los GIF animados convertidos en WebP con pérdida son un 64% más pequeños, mientras que los WebP sin pérdidas son un 19% más pequeños. Esto es especialmente importante en las redes móviles.
WebP tarda menos tiempo en decodificarse en presencia de búsquedas. En Blink, el desplazamiento o el cambio de pestañas pueden ocultar y mostrar imágenes, lo que hace que las animaciones se detengan y, luego, se avancen a un punto diferente. El uso excesivo de la CPU que provoca que las animaciones dejen de ver fotogramas; también puede requerir que el decodificador busque hacia adelante en la animación. En estas situaciones, el formato WebP animado tarda 0.57 veces más tiempo de decodificación total² que el GIF, lo que genera menos bloqueos durante el desplazamiento y una recuperación más rápida de los picos de uso de CPU. Esto se debe a dos ventajas de WebP sobre GIF:
- Las imágenes WebP almacenan metadatos sobre si cada fotograma contiene alfa, lo que elimina la necesidad de decodificar el fotograma para tomar esta determinación. Esto genera una inferencia más precisa de los fotogramas anteriores de los que depende un fotograma determinado, lo que reduce la decodificación innecesaria de marcos anteriores.
- Al igual que un codificador de video moderno, el codificador WebP agrega heurísticamente fotogramas clave a intervalos regulares (lo cual no hace la mayoría de los codificadores de GIF). Esto mejora drásticamente la búsqueda en animaciones largas. Para facilitar la inserción de esos marcos sin aumentar significativamente el tamaño de la imagen, WebP agrega una marca del método de combinación para cada fotograma, además del método de eliminación de marcos que usa GIF. Esto permite que un fotograma clave se dibuje como si toda la imagen se hubiera cambiado al color de fondo sin forzar el tamaño original del fotograma anterior.

Desventajas de WebP animado en comparación con GIF animado

En ausencia de búsqueda, la decodificación directa de WebP exige más CPU que la de GIF. El formato WebP con pérdida tarda 2.2 veces más tiempo de decodificación que el GIF, mientras que el formato WebP sin pérdidas demora 1.5 veces más.
La compatibilidad con WebP no es tan generalizada como la compatibilidad con GIF, que es efectivamente universal.
La incorporación de compatibilidad con WebP en navegadores aumenta la huella de código y la superficie de ataque. En Blink, se incluyen aproximadamente 1,500 líneas de código adicionales (incluida la biblioteca de demux de WebP y el decodificador de imágenes WebP de Blink). Ten en cuenta que este problema podría reducirse en el futuro si WebP y WebM comparten un código de decodificación más común o si las capacidades de WebP se suman en el de WebM.

¿Por qué no solo admitir WebM en <img>?

Puede tener sentido a largo plazo admitir formatos de video dentro de la etiqueta <img>. Sin embargo, hacerlo ahora, con la intención de que WebM en <img> pueda cumplir la función propuesta de WebP animado, resulta problemático:

Cuando se decodifica un fotograma que se basa en fotogramas anteriores, WebM requiere un 50% más de memoria que WebP animado para contener la cantidad mínima de fotogramas anteriores³.
La compatibilidad con códecs de video y contenedores varía ampliamente según los navegadores y los dispositivos. Para facilitar la transcodificación automática de contenido (p.ej., para proxies de ahorro de ancho de banda), los navegadores deberán agregar encabezados de aceptación que indiquen qué formatos admiten sus etiquetas de imagen. Incluso esto puede ser insuficiente, ya que los tipos de MIME como "video/webm" o "video/mpeg" no indican la compatibilidad con el códec (p. ej., VP8 frente a VP9). Por otro lado, el formato WebP se congela de forma efectiva y, si los proveedores que lo envían aceptan enviar WebP animados, el comportamiento de WebP en todos los UA debe ser coherente. Además, dado que el encabezado de aceptación "image/webp" ya se usa para indicar la compatibilidad con WebP, no es necesario nuevos cambios de encabezado de aceptación.
La pila de video de Chromium está optimizada para una reproducción fluida y supone que solo se reproducen uno o dos videos a la vez. Como resultado, la implementación es agresiva y consume recursos del sistema (subprocesos, memoria, etc.) para maximizar la calidad de reproducción. Esta implementación no se adapta bien a muchos videos simultáneos y tendría que rediseñarse para que sea adecuada para su uso en páginas web con muchas imágenes.
Actualmente, WebM no incorpora todas las técnicas de compresión de WebP. Por lo tanto, esta imagen se comprime significativamente mejor con WebP que las alternativas:

¹ Para todas las comparaciones entre GIF animado y WebP animado, utilizamos un corpus de aproximadamente 7,000 imágenes GIF animadas tomadas de la Web de forma aleatoria. Estas imágenes se convirtieron a WebP animados con la herramienta "gif2webp" con la configuración predeterminada (creada a partir del árbol de fuentes de libwebp más reciente a partir del 08/10/2013). Los números comparativos son los valores promedio de estas imágenes.

² Los tiempos de decodificación se calcularon con la versión más reciente de libwebp + ToT Blink al 8/10/2013 con una herramienta comparativa. "Tiempo de decodificación con búsqueda" se calcula como "Decodificar los primeros cinco fotogramas, borrar la caché del búfer de fotogramas, decodificar los siguientes cinco fotogramas, etc.".

³ WebM conserva 4 fotogramas de referencia YUV en la memoria, y cada fotograma almacena (ancho +96)*(altura + 96) píxeles. Para YUV 4:2:0, necesitamos 4 bytes por 6 píxeles (o 3/2 bytes por píxel). Por lo tanto, estas tramas de referencia usan 4*3/2*(width+96)*(height+96) bytes de memoria. Por otro lado, WebP solo necesitaría que el fotograma anterior (en RGBA) esté disponible, que es de 4*width*height bytes de memoria.

⁴ El procesamiento de WebP animado requiere la versión 32 de Google Chrome o una posterior.