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, por lo que el usuario puede elegir la compensación entre el tamaño del archivo y la calidad de la imagen. WebP generalmente logra un promedio de un 30% más de compresión que los archivos JPEG y JPEG 2000, sin perder la calidad de la imagen (consulta el Estudio comparativo).

Básicamente, el formato WebP tiene como objetivo crear imágenes más pequeñas y con mejor aspecto que puedan ayudar a que la Web sea más rápida.

¿Qué navegadores web admiten WebP de forma nativa?

Los webmasters interesados en mejorar el rendimiento de su sitio pueden crear fácilmente alternativas de WebP optimizadas para sus imágenes actuales y entregarlas de forma específica a 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 o superior
- Navegador web nativo, Android 4.0+ (ICS)
- Safari 14 o versiones posteriores (iOS 14 o versiones posteriores, macOS Big Sur+).
Compatibilidad con WebP, con pérdida y sin pérdida
- Google Chrome (computadoras de escritorio) más de 23
- Google Chrome para Android versión 25 o posterior
- Microsoft Edge 18 y versiones posteriores
- Firefox 65 y versiones posteriores
- Opera 12.10 o versiones posteriores
- Navegador web nativo, Android 4.2+ (JB-MR1)
- Luna pálida para mayores de 26 años
- Safari 14 o versiones posteriores (iOS 14 o 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
- Opera 19 y versiones posteriores
- Safari 14 o versiones posteriores (iOS 14 o versiones posteriores, macOS Big Sur+).

También consulta lo siguiente:

¿Cómo puedo detectar la compatibilidad de los navegadores con WebP?

Te recomendamos que entregues imágenes WebP solo a los clientes que puedan mostrarlas de forma correcta y recurras a los formatos heredados para los clientes que no pueden mostrarlas. 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 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 con anticipación 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.

Moderniz

Modernizr es una biblioteca de JavaScript para detectar de manera conveniente la compatibilidad con las funciones 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 varias orientaciones de imagen alternativas en orden de prioridad, de modo que el cliente solicite la primera imagen candidata que pueda mostrar 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 es decodificar una imagen WebP muy pequeña que use una función en particular y verificar el éxito. 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 está bloqueada ni es asíncrona. Esto significa que es preferible incluir cualquier código que dependa de la compatibilidad con WebP 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, cualquiera puede trabajar con el formato y sugerir mejoras. Con tus comentarios y sugerencias, creemos que WebP será cada vez más útil como formato gráfico a lo largo del tiempo.

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

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

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

Actualmente, puedes ver los archivos WebP si los conviertes a un formato común que utiliza compresión sin pérdida, como PNG, y luego puedes ver los archivos PNG en cualquier navegador o visor de imágenes. Para tener una idea rápida de la calidad WebP, consulta la Galería de este sitio para ver las comparaciones de 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 WebP. El código para el decodificador liviano y la especificación de VP8 se encuentran en el sitio de WebM. Consulta la página de Contenedores RIFF para obtener la especificación del contenedor.

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

WebP es compatible con la transmisión en bits con VP8 y usa 14 bits para el ancho y la altura. Las dimensiones máximas de píxeles de una imagen WebP son de 16,383 x 16,383.

¿Qué espacios de color admite el formato WebP?

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

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

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

Sí, por lo general, cuando se realiza una conversión 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 en comparación con ARGB) y la conversión entre estos elementos.

Existen tres situaciones típicas:

Si la imagen de origen está en formato ARGB sin pérdida, el submuestreo espacial a YUV420 introducirá colores nuevos que serán más difíciles de comprimir que los originales. Por lo general, esta situación 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 dar como resultado un tamaño de archivo más grande.
Si la fuente está en formato con pérdida, el uso de compresión 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 específico de WebP y puede ocurrir cuando se convierte una fuente JPEG a formatos WebP o PNG sin pérdidas, por ejemplo.
Si la fuente está en formato con pérdida y estás intentando comprimirla como un archivo WebP con pérdida con 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, por lo general se genera un archivo más grande, incluso si ambos formatos tienen pérdida. La evaluación de la calidad de la fuente suele ser imposible, por lo que se recomienda reducir la calidad del destino de WebP si el tamaño del archivo es siempre mayor. Otra posibilidad es evitar usar la configuración de calidad y, en su lugar, orientar a un tamaño de archivo determinado con la opción -size en la herramienta de cwebp o la API equivalente. Por ejemplo, la orientación al 80% del tamaño original del archivo podría resultar más sólida.

Ten en cuenta que convertir una fuente JPEG a WebP con pérdida o una fuente PNG a WebP sin pérdida no es propenso a tales sorpresas de tamaño de archivo.

¿ WebP es compatible con 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 presiones demasiado la CPU y la memoria del cliente de decodificación, ya que cada evento de actualización implica un pase completo a través del sistema de descompresión.

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

Como alternativa, WebP ofrece decodificación incremental, en la que todos los bytes entrantes disponibles del bitbit se utilizan para intentar producir una fila de muestra que se muestre lo antes posible. Esto ahorra memoria, CPU y vuelve a pintar el cliente en tiempo real, y proporciona indicaciones 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 de libwebp en mi proyecto de Android?

WebP es compatible con las vinculaciones de JNI con las interfaces simples de decodificador y decodificador en el directorio swig/.

Cómo compilar la biblioteca en Eclipse:

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

Nota Si estableces NDK_TOOLCHAIN_VERSION=4.8, el rendimiento de la compilación de 32 bits en general mejorará.
Agrega swig/libwebp.jar a la carpeta del proyecto libs/.
Compila tu proyecto. Se 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 objeto 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 un DLL que exporta la API de libwebp. Estas funciones 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 los búferes que se muestren.

[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é debo usar WebP animado?

Ventajas de WebP animado en comparación con GIF animado

WebP es compatible con el color RGB de 24 bits con un canal alfa de 8 bits, en comparación con el color 8 bits de GIF y el 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. El GIF solo admite 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 reales, una fuente cada vez más popular de imágenes animadas.
WebP requiere menos bytes que GIF¹. Los GIF animados convertidos en WebP con pérdida son un 64% más pequeños, mientras que los WebP sin pérdida son un 19% más pequeños. Esto es particularmente importante en redes móviles.
WebP tarda menos 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 omitan en un punto diferente. El uso excesivo de la CPU que provoca que las animaciones descarten fotogramas también puede requerir que el decodificador busque en la animación. En estos casos, el WebP animado toma 0.57 veces más tiempo de decodificación total² que el GIF, lo que da como resultado 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 en lugar de GIF:
- Las imágenes WebP almacenan los metadatos sobre si cada marco contiene alfa, lo que elimina la necesidad de decodificar el marco para realizar esta determinación. Esto genera una inferencia más precisa de los marcos anteriores de los que depende un fotograma determinado, lo que reduce la decodificación innecesaria de los fotogramas anteriores.
- De forma muy similar a un codificador de video moderno, el codificador WebP agrega heurística fotogramas clave a intervalos regulares (la mayoría de los codificadores GIF no lo hacen). Esto mejora drásticamente las búsquedas en animaciones largas. A fin de facilitar la inserción de estos marcos sin aumentar de manera significativa el tamaño de la imagen, WebP agrega una marca de “método de fusión” para cada marco, además del método de eliminación de fotogramas que usa GIF. Esto permite que un fotograma clave se dibuje como si toda la imagen se hubiera borrado en el color de fondo sin forzar al marco anterior a tamaño completo.

Desventajas de WebP animado en comparación con GIF animado

Ante la falta de búsqueda, la decodificación lineal de WebP requiere más uso de CPU que GIF. WebP con pérdida lleva 2.2 veces más tiempo de decodificación que GIF, mientras que WebP sin pérdida toma 1.5 veces más.
La compatibilidad con WebP no es tan amplia como la compatibilidad con GIF, que es efectivamente universal.
Agregar compatibilidad con WebP a los navegadores aumenta la huella de código y la superficie de ataque. En Blink, hay aproximadamente 1,500 líneas de código adicionales (incluida la biblioteca de dimex de WebP y el decodificador de imágenes WebP de lado 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 la de WebM.

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

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

Cuando se decodifica un fotograma que se basa en marcos anteriores, WebM requiere un 50% más de memoria que un WebP animado para contener la cantidad mínima de fotogramas anteriores³.
La compatibilidad con el códec de video y con los contenedores varía ampliamente según el navegador y el dispositivo. A fin de facilitar la transcodificación de contenido automática (p.ej., para proxies de ahorro de ancho de banda), los navegadores deberán agregar encabezados de aceptación que indiquen los formatos que admiten sus etiquetas de imagen. Incluso esto podría no ser suficiente, ya que los tipos de MIME, como "video/webm" o "video/mpeg", aún no indican la compatibilidad con códecs (p. ej., VP8 frente a VP9). Por otro lado, el formato WebP está efectivamente bloqueado, y si los proveedores que lo envían aceptan enviar WebP animados, el comportamiento de WebP en todos los UA debe ser coherente; y como el encabezado de aceptación "image/webp" ya se usa para indicar compatibilidad con WebP, no es necesario realizar nuevos cambios de encabezado de aceptación.
La pila de videos 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 consume recursos de sistemas (subprocesos, memoria, etc.) para maximizar la calidad de reproducción. Este tipo de implementación no se adapta bien a muchos videos simultáneos y se debería rediseñar a fin de que sea apto para usarse con páginas web que tengan muchas imágenes.
Actualmente, WebM no incorpora todas las técnicas de compresión de WebP. Como resultado, esta imagen se comprime considerablemente mejor con WebP que las alternativas:

¹ Para todas las comparaciones entre GIF animados y WebP animados, usamos un corpus de alrededor de 7,000 imágenes GIF animadas tomadas de forma aleatoria de la Web. Estas imágenes se convirtieron a WebP animadas mediante la herramienta “gif2webp” con la configuración predeterminada (compilada con el árbol de fuentes de libwebp más reciente hasta el 08/10/2013). Los números comparativos son los valores promedio en estas imágenes.

² Los tiempos de decodificación se calcularon con la última versión de libwebp + ToT Blink al 08/10/2013 mediante una herramienta comparativa. “Decodificar el tiempo con búsqueda” se calcula como “Decodificación de los primeros cinco marcos, borra la caché del búfer de fotogramas, decodifica los siguientes cinco marcos, etcétera”.

³ WebM conserva 4 marcos de referencia YUV en la memoria, de modo que cada fotograma almacena los píxeles (ancho + 96)*(altura + 96). Para YUV 4:2:0, necesitamos 4 bytes por 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 el fotograma anterior (en RGBA) disponible, que es 4*width*height bytes de memoria.

⁴ La renderización animada de WebP requiere la versión de Google Chrome 32 o una versión posterior.