WebP

Un archivo WebP se basa en el contenedor RIFF, el mismo encuadre utilizado por WAV. Dentro de ese contenedor, una imagen estática se puede codificar de dos maneras. El modo Lossy se basa en el códec intra-frame VP8, el mismo códec de vídeo que impulsa el vídeo WebM; este predice bloques de píxeles y almacena una descripción compacta del error, razón por la cual los archivos fotográficos se reducen tan drásticamente. El modo Lossless predice cada píxel a partir de sus vecinos y almacena la diferencia, con un espíritu similar al de PNG pero con una gama más amplia de modos de predicción. El contenedor también puede albergar un alpha channel para la transparencia y una secuencia de animation frames cronometrados en milisegundos, de modo que un solo archivo puede sustituir a un GIF. Debido a que el formato es un contenedor único, un servidor puede elegir entre cargas útiles lossy, lossless o animadas desde la misma extensión .webp sin cambiar la forma en que se escribe la URL.

Audita las imágenes de las plantillas que generan la mayor parte de tu tráfico orgánico y sirve una versión WebP para cualquier imagen de hero, de producto o de artículo que se envíe como JPEG o PNG. Genera archivos con los tamaños que tu diseño realmente necesita en lugar de la resolución nativa del archivo original, y mantén el máster original en tu DAM para que puedas volver a codificarlo más adelante si el codificador mejora. Utiliza el elemento picture o un encabezado de negociación de contenido para que los navegadores que no pueden decodificar WebP sigan recibiendo una alternativa funcional. En Next/Image, wp_get_attachment_image o en el pipeline de imágenes de tu CDN, establece WebP como la salida preferida. Por último, actualiza tus sitemaps de imágenes XML y tu esquema image:secure_url para que los motores de búsqueda puedan encontrar los nuevos archivos.

Abre una página en Chrome, abre las DevTools, cambia a la pestaña Network y filtra por Img. La columna Type muestra image/webp para los archivos servidos; la columna Size muestra los bytes transferidos. Para confirmar que se utilizó el codificador, haz clic derecho en una miniatura, elige Open in new tab y comprueba la URL o los encabezados de respuesta. En cuanto a la parte de búsqueda, los informes de Core Web Vitals en Search Console y CrUX muestran el Largest Contentful Paint y los elementos de LCP relacionados con imágenes, los cuales un archivo WebP más pequeño puede reducir. En Lighthouse, la auditoría Serve images in next-gen formats enumera cada imagen de mapa de bits que no sea WebP o AVIF. Los registros de rastreo (crawl logs) que registran el Content-Type de respuesta también mostrarán la mezcla de formatos en todo el sitio.

• Subir un archivo WebP pero enlazarlo desde una etiqueta img con una extensión .jpg codificada manualmente, de modo que el navegador siga obteniendo el original.
• Olvidar proporcionar un fallback para versiones antiguas de Safari e Internet Explorer, que muestran silenciosamente un icono de imagen rota en lugar del WebP.
• Guardar un WebP dentro de un contenedor JPEG existente, dejando el archivo con una extensión .jpg y el encabezado Content-Type incorrecto.
• Volver a codificar un JPEG que ya es con pérdida como un WebP con pérdida y esperar una segunda ronda de grandes ahorros; los artefactos visibles ya están integrados.
• Servir un archivo maestro de 4000px en un espacio de 400px, incluso en WebP, y tratar el formato como un sustituto del dimensionamiento responsivo.

WebP no es el único formato de próxima generación y, para contenido puramente fotográfico, AVIF suele superarlo en compresión, a costa de una codificación más lenta y un soporte más débil en herramientas antiguas. WebP también se confunde habitualmente con WebM, que es el contenedor de video basado en VP8 y VP9; ambos comparten códecs pero son archivos distintos para tareas diferentes. El formato es adecuado para capturas de pantalla, fotos de productos e iconos, pero no es un formato vectorial, y los logotipos que se benefician del escalado infinito siguen siendo mejores en SVG. WebP sin pérdida (lossless), aunque es más pequeño que PNG, es más grande que su hermano con pérdida (lossy); convertir cada PNG en WebP sin pérdida es una oportunidad perdida para el contenido fotográfico.

Antes: /uploads/2024/03/hero.jpg — 2,840,192 bytes, servido como image/jpeg, utilizado dentro de un espacio hero de 1200x630 y nuevamente a 200x105 en la cuadrícula de posts relacionados. Después: /uploads/2024/03/hero-1200.webp — 318,440 bytes (lossy, q=75) para el hero, y /uploads/2024/03/hero-200.webp — 14,902 bytes (lossy, q=70) para la miniatura, ambos servidos como image/webp a través de un CDN con un fallback de JPEG. El HTML utiliza un elemento <picture> para que un navegador sin soporte para WebP reciba el JPEG original. La auditoría Serve images in next-gen formats de Lighthouse baja a cero en la página, y el tiempo de renderizado del elemento LCP disminuye aproximadamente medio segundo en una conexión móvil de gama media.

El mismo término en las palabras que alguien usa al hablar con un asistente en lugar de escribir en un buscador: escrito desde la situación, y por eso cada pregunta lleva la situación de la que salió.

• Google — WebP documentation and reference implementation
• Google — Image best practices for SEO
• WebP
• Wikidata — Q62617958