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 se puede ajustar para que el usuario elija el equilibrio entre el tamaño del archivo y la calidad de la imagen. Por lo general, WebP logra un promedio de un 30% más de compresión que JPEG y JPEG 2000, sin pérdida de calidad de la imagen (consulta el Estudio comparativo).

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

¿Qué navegadores web admiten WebP de forma nativa?

Los administradores de sitios web interesados en mejorar el rendimiento del sitio pueden crear fácilmente alternativas WebP optimizadas para sus imágenes actuales y publicarlas de forma segmentada en los navegadores que admiten WebP.

Compatibilidad con WebP con pérdida
- Google Chrome (para computadoras) 17 o 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 o versiones posteriores (ICS)
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur y versiones posteriores)
Compatibilidad con WebP con pérdida, sin pérdida y alfa
- Google Chrome (computadoras) 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, Android 4.2 y versiones posteriores (JB-MR1)
- Pale Moon 26 y versiones posteriores
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur y versiones posteriores)
Compatibilidad con animaciones WebP
- Google Chrome (computadoras y Android) 32 o versiones posteriores
- Microsoft Edge (mayores de 18 años)
- Firefox 65 y versiones posteriores
- Opera 19 y versiones posteriores
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur y versiones posteriores)

Consulta lo siguiente:

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

Te recomendamos que publiques imágenes WebP solo para los clientes que puedan mostrarlas correctamente y que vuelvas a los formatos heredados para los clientes que no puedan hacerlo. Afortunadamente, existen varias técnicas para detectar la compatibilidad con WebP, tanto del lado del cliente como del servidor. Algunos proveedores de CDN ofrecen detección de compatibilidad con WebP como parte de su servicio.

Negociación de contenido del servidor a través de encabezados Accept

Es común que los clientes web envíen un encabezado de solicitud "Accept", que indica qué formatos de contenido están dispuestos a aceptar en la respuesta. Si un navegador indica con anticipación que "aceptará" el formato image/webp, el servidor web sabe 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 que permite detectar de forma conveniente la compatibilidad con las funciones de HTML5 y CSS3 en los navegadores web. Busca las propiedades Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha y Modernizr.webp.animation.

Elemento `<picture>` de HTML5

HTML5 admite un elemento <picture>, que te permite enumerar varios objetivos de imagen alternativos en orden de prioridad, de modo que un cliente solicite la primera imagen candidata que pueda mostrar correctamente. Consulta esta discusión en HTML5 Rocks. El elemento <picture> es compatible con más navegadores todo el tiempo.

En tu propio código JavaScript

Otro método de detección consiste en intentar decodificar una imagen WebP muy pequeña que usa una función en particular y verificar si se realizó correctamente. 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 es bloqueante y es asíncrona. Esto significa que cualquier código que dependa de la compatibilidad con WebP debe colocarse, de preferencia, en la función de devolución de llamada.

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

Creemos firmemente 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 comentarios y sugerencias, creemos que WebP se volverá aún más útil como formato gráfico con el 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 imágenes personales al formato WebP. Consulta Cómo usar WebP para obtener más detalles.

Si tienes muchas imágenes para convertir, puedes usar la shell de tu plataforma para simplificar la operación. Por ejemplo, para convertir todos los archivos JPEG de una carpeta, prueba 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 juzgar la calidad de las imágenes WebP por mi cuenta?

Actualmente, puedes ver archivos WebP convirtiéndolos a un formato común que use compresión sin pérdida, 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 y compara fotos una al lado de la otra.

¿Cómo obtengo el código fuente?

El código del convertidor 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 se encuentran en el sitio de WebM. Consulta la página Contenedor RIFF para ver la especificación del contenedor.

¿Cuál es el tamaño máximo que puede tener una imagen WebP?

WebP es compatible con el flujo de bits de VP8 y usa 14 bits para el ancho y la altura. Las dimensiones máximas de píxeles de una imagen WebP son 16,383 × 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 4:2:0 de 8 bits (a menudo llamado YUV420). Para obtener más detalles, consulta la sección 2, "Format Overview" de RFC 6386, VP8 Data Format and Decoding Guide.

WebP sin pérdida funciona exclusivamente con el formato RGBA. Consulta la especificación del flujo de bits sin pérdida de WebP.

¿Por qué mi archivo WebP sin pérdida difiere del original?

Las funciones de la API de Simple Encoding (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) usan la configuración predeterminada de la biblioteca. Para la compresión sin pérdida, esto significa que la opción "exacta" está inhabilitada. Los valores RGB en las áreas completamente transparentes (es decir, las áreas con valores alfa iguales a 0) se modificarán para mejorar la compresión. Para evitar esto, usa WebPEncode() y establece WebPConfig::exact en 1. Consulta la documentación de la API de Advanced Encoding.

¿Puede una imagen WebP ser más grande que su imagen fuente?

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 en el espacio de color (YUV420 frente a ARGB) y a la conversión entre estos.

Existen tres situaciones típicas:

Si la imagen de origen está en formato ARGB sin pérdida, la reducción de la resolución espacial a YUV420 introducirá nuevos colores que son más difíciles de comprimir que los originales. Esta situación suele ocurrir cuando la fuente está en formato PNG con pocos colores: convertirla a WebP con pérdida (o, de manera similar, a un JPEG con pérdida) podría generar un tamaño de archivo más grande.
Si la fuente está en formato con pérdida, usar la compresión WebP sin pérdida para capturar la naturaleza con pérdida de la fuente generalmente generará un archivo más grande. Esto no es específico de 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 estás intentando comprimirla como un WebP con pérdida con un parámetro de configuración de mayor calidad. Por ejemplo, intentar convertir un archivo JPEG guardado con una calidad de 80 a un archivo WebP con una calidad de 95 suele generar un archivo más grande, incluso si ambos formatos son con pérdida. A menudo, es imposible evaluar la calidad de la fuente, por lo que se recomienda reducir la calidad de WebP objetivo si el tamaño del archivo es constantemente mayor. Otra posibilidad es evitar usar el parámetro de configuración de calidad y, en cambio, establecer un tamaño de archivo determinado con la opción -size en la herramienta cwebp o la API equivalente. Por ejemplo, segmentar el 80% del tamaño del archivo original podría resultar más sólido.

Ten en cuenta que convertir una fuente JPEG a WebP con pérdida o una fuente PNG a WebP sin pérdida no suele generar sorpresas en el tamaño del archivo.

¿WebP admite la visualización progresiva o entrelazada?

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

En promedio, decodificar una imagen JPEG progresiva equivale a decodificar la de referencia 3 veces.

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

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

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

Compila la biblioteca en Eclipse:

Asegúrate de tener instalado el complemento de ADT junto con las herramientas del NDK y de que la ruta del NDK esté configurada correctamente (Preferencias > 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 C/C++ Build > Behaviour. Agrega ENABLE_SHARED=1 a la sección Build (Incremental build) para compilar libwebp como una biblioteca compartida.

Nota: En general, establecer 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 en el tiempo de ejecución.

Ten en cuenta que la biblioteca se puede compilar de forma manual con ndk-build y el Android.mk incluido. En ese caso, se pueden reutilizar algunos de los pasos descritos anteriormente.

¿Cómo uso libwebp con C#?

WebP se puede compilar como un archivo DLL que exporta la API de libwebp. Luego, estas funciones se pueden importar en C#.

Compila libwebp.dll. Esto establecerá 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 los búferes que se devolvieron.

[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 WebP animado en comparación con GIF animado

WebP admite color RGB de 24 bits con un canal alfa de 8 bits, en comparación con el color de 8 bits y el alfa de 1 bit de GIF.
WebP admite la compresión con y sin pérdida. De hecho, una sola animación puede combinar fotogramas con y sin pérdida. El formato GIF solo admite la compresión sin pérdida. Las técnicas de compresión con pérdida de WebP son adecuadas para las imágenes animadas creadas a partir de videos del mundo real, una fuente cada vez más popular de imágenes animadas.
WebP requiere menos bytes que GIF¹. Los GIFs animados convertidos a WebPs con pérdida son un 64% más pequeños, mientras que los WebPs sin pérdida son un 19% más pequeños. Esto es especialmente importante en las redes móviles.
WebP tarda menos en decodificarse cuando se realizan búsquedas. En Blink, desplazarse o cambiar de pestaña puede ocultar y mostrar imágenes, lo que provoca que las animaciones se pausen y, luego, se adelanten a un punto diferente. El uso excesivo de la CPU que provoca que las animaciones pierdan fotogramas también puede requerir que el decodificador busque hacia adelante en la animación. En estas situaciones, WebP animado tarda 0.57 veces el tiempo total de decodificación² que GIF, lo que genera menos tirones 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 determinarlo. Esto permite inferir con mayor precisión de qué fotogramas anteriores depende un fotograma determinado, lo que reduce la decodificación innecesaria de fotogramas anteriores.
- Al igual que un codificador de video moderno, el codificador de WebP agrega de forma heurística fotogramas clave a intervalos regulares (lo que la mayoría de los codificadores de GIF no hacen). Esto mejora drásticamente la búsqueda en animaciones largas. Para facilitar la inserción de estos fotogramas sin aumentar significativamente el tamaño de la imagen, WebP agrega una marca de "método de combinación" para cada fotograma, además del método de descarte de fotogramas que usa GIF. Esto permite que un fotograma clave se dibuje como si toda la imagen se hubiera borrado al color de fondo sin forzar que el fotograma anterior sea de tamaño completo.

Desventajas de WebP animado en comparación con GIF animado

En ausencia de búsqueda, la decodificación lineal de WebP requiere más CPU que la de GIF. El formato WebP con pérdida tarda 2.2 veces más en decodificarse que el GIF, mientras que el formato WebP sin pérdida tarda 1.5 veces más.
La compatibilidad con WebP no está tan extendida como la compatibilidad con GIF, que es prácticamente universal.
Agregar compatibilidad con WebP a los navegadores aumenta la huella de código y la superficie de ataque. En Blink, esto equivale a aproximadamente 1,500 líneas de código adicionales (incluida la biblioteca de demux de WebP y el decodificador de imágenes WebP del lado de Blink). Ten en cuenta que este problema podría reducirse en el futuro si WebP y WebM comparten más código de decodificación común o si las capacidades de WebP se incluyen en las de WebM.

¿Por qué no se admite WebM en <img>?

A largo plazo, puede tener sentido admitir formatos de video dentro de la etiqueta <img>. Sin embargo, hacerlo ahora, con la intención de que WebM en <img> pueda cumplir el rol propuesto de WebP animado, es problemático:

Cuando se decodifica un fotograma que depende de fotogramas anteriores, WebM requiere un 50% más de memoria que WebP animado para almacenar la cantidad mínima de fotogramas anteriores³.
La compatibilidad con los códecs y contenedores de video varía mucho entre los navegadores y los dispositivos. Para facilitar la transcodificación automática de contenido (p.ej., para proxies que ahorran ancho de banda), los navegadores deberían agregar encabezados de aceptación que indiquen qué formatos admiten sus etiquetas de imagen. Incluso esto podría ser insuficiente, ya que los tipos MIME como "video/webm" o "video/mpeg" aún no indican la compatibilidad con el códec (p. ej., VP8 frente a VP9). Por otro lado, el formato WebP está efectivamente congelado, y si los proveedores que lo envían aceptan enviar WebP animado, el comportamiento de WebP en todos los UA debería 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 realizar nuevos cambios en el 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 en el consumo de recursos del sistema (subprocesos, memoria, etcétera) para maximizar la calidad de reproducción. Esta implementación no se adapta bien a muchos videos simultáneos y debería rediseñarse para que sea adecuada para su uso con páginas web con muchas imágenes.
Actualmente, WebM no incorpora todas las técnicas de compresión de WebP. Como resultado, esta imagen se comprime mucho mejor con WebP que con las alternativas:

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

² Los tiempos de decodificación se calcularon con la versión más reciente de libwebp y Blink de ToT al 8/10/2013 con una herramienta de comparativas. El "Tiempo de decodificación con búsqueda" se calcula como "Decodifica los primeros cinco fotogramas, borra la caché del búfer de fotogramas, decodifica los siguientes cinco fotogramas, y así sucesivamente".

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

⁴ La renderización de WebP animado requiere Google Chrome 32 o versiones posteriores

Preguntas frecuentes Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.