En 2021 tenía un cliente WooCommerce en Birmingham, una tienda de artículos para el hogar con alrededor de 4,000 fotos de productos, todas JPEGs gigantes tomadas con una cámara DSLR Canon y subidas sin procesamiento alguno. Su Largest Contentful Paint estaba en 7.2 segundos. Brutal. Convertí todo a WebP usando Squoosh CLI, volví a ejecutar Lighthouse, y bajé el LCP a 2.8 segundos en una sola tarde. El cliente lloró. De verdad.Squoosh CLI, re-ran Lighthouse, and got LCP down to 2.8 seconds in a single afternoon. The client cried. Genuinely.
Pero aquí está la cosa: ese mismo truco habría hecho muy poco por un cliente diferente con el que trabajé el mes siguiente, un sitio de portafolio de fotoperiodismo donde la fidelidad de color y las exportaciones de calidad para imprenta realmente importaban. WebP era la llamada equivocada ahí. Usé JPEG con configuraciones agresivas de exportación de Lightroom en su lugar, y la brecha de rendimiento era negligible porque las imágenes ya tenían el tamaño adecuado.
Así que hablemos de esto apropiadamente. No "WebP siempre es mejor" ni "JPEG es un clásico por una razón." La respuesta real es más situacional de lo que cualquiera de los dos bandos admite.
---
Qué está realmente diferente bajo la superficie
JPEG existe desde 1992. Utiliza compresión por transformada discreta del coseno, que es excelente para fotografías pero empieza a fallar en ratios de compresión altos porque introduce esos artefactos bloqueados tan familiares. La mayoría de desarrolladores web lo saben.
WebP fue lanzado por Google en 2010 y utiliza un modelo de codificación predictiva tomado del códec de video VP8. En resumen: modela las relaciones espaciales entre píxeles de manera más inteligente, lo que significa que puede comprimir más calidad en menos bytes. Según la propia investigación de Google, las imágenes WebP sin pérdida son 28% más pequeñas que los PNGs, y WebP con pérdida es 25-34% más pequeño que JPEGs comparables a calidad equivalente.Google's own research, WebP lossless images are 26% smaller than PNGs, and lossy WebP is 25-34% smaller than comparable JPEGs at equivalent quality.
Esos números se mantienen en la práctica. Mayormente.
Dónde se ve la diferencia realmente
Los ahorros del 25-34% tienden a materializarse en fotografías naturales con degradados suaves, fotos de productos sobre fondos blancos e imágenes de estilo de vida. La brecha se reduce considerablemente en detalles de alta frecuencia: texturas de tela apretada, follaje denso, patrones arquitectónicos con mucha repetición. He hecho pruebas con comparaciones lado a lado en ImageMagick muchas veces. En ciertos shots muy detallados, la diferencia de tamaño cae por debajo del 10%, y a veces WebP incluso pierde en la misma configuración de calidad.ImageMagick side-by-side comparisons plenty of times. On certain highly detailed shots, the size difference drops to under 10%, and sometimes WebP even loses at the same quality setting.
---
Soporte de Navegadores en 2026: ¿Sigue siendo una Conversación?
Honestamente, el soporte de navegadores fue el argumento real para seguir con JPEG allá por 2018. Internet Explorer. Safari siendo lento en adoptar. Todo eso.
Se acabó. Can I Use muestra soporte global de WebP por encima del 97% en este punto. Safari agregó soporte completo en la versión 14 allá por 2020. IE está muerto y enterrado. No hay un segmento de audiencia significativo que no pueda recibir una imagen WebP en 2026.Can I Use puts global WebP support at over 97% at this point. Safari added full support in version 14 back in 2020. IE is dead and buried. There's no meaningful audience segment that can't receive a WebP image in 2026.
El único caso extremo que todavía encuentro es: si sirves imágenes como adjuntos de correo electrónico o las incrustas en exportaciones de PDF generadas del lado del servidor, algunos pipelines de renderización más antiguos fallan con WebP. Eso es todo. Para todo lo entregado por navegador, el argumento de soporte ha terminado.
---
Core Web Vitals: Dónde la elección de formato realmente marca la diferencia
LCP (Largest Contentful Paint) es la métrica de Core Web Vitals más afectada directamente por el formato de imagen. Mide cuánto tiempo tarda en cargar el elemento visible más grande. Si ese elemento es una imagen (y casi siempre lo es en sitios de marketing y comercio electrónico), entonces el formato, el tamaño y el método de entrega importan enormemente.
Aquí hay un desglose práctico de dónde he visto que la elección de formato marca una diferencia real:
- Imágenes hero: Casi siempre son el elemento LCP. Si tu hero es un JPEG de 1.2MB con 1920px de ancho, convertir a WebP con calidad 82 te llevará rutinariamente a 380-450KB sin pérdida de calidad visible. These are almost always the LCP element. If your hero is a 1.2MB JPEG at 1920px wide, converting to WebP at quality 82 will routinely get you to 380-450KB without visible quality loss.
- Cuadrículas de imágenes de producto: Muchas imágenes pequeñas cargando simultáneamente. El ahorro consistente de 25%+ de WebP se compone aquí. Cuadrícula más rápida = menos bloqueo total en móvil. Lots of small images loading simultaneously. WebP's consistent 25%+ savings compound here. Faster grid = lower total blocking on mobile.
- Imágenes inline en posts de blog: Genuinamente bajo impacto. Un JPEG de 200KB versus un WebP de 140KB en medio de un artículo de 3,000 palabras no va a mover tu LCP. Genuinely low impact. A 200KB JPEG versus a 140KB WebP in the middle of a 3,000-word article isn't moving your LCP.
- Iconos y logos: Ninguno. Usa SVG. Tengo que decir esto cada vez. Neither. Use SVG. I have to say this every single time.
- Miniaturas en páginas de archivo: WebP gana aquí, especialmente cuando cargas 20-30 miniaturas en una cuadrícula. Ahí es donde el ahorro de bytes se acumula rápidamente. WebP wins here, especially when you're loading 20-30 thumbnails in a grid. That's where byte savings stack up fast.
Seahawk tuvo un proyecto fintech el año pasado donde el sitio de marketing tenía 14 imágenes above-the-fold rotando en un carrusel hero. Una locura, pero el cliente insistió. Convertir las 14 de JPEG a WebP con calidad 80 y entregarlas vía Cloudflare CDN redujo su LCP de 4.1 a 2.3 segundos en móvil. El carrusel seguía siendo una idea terrible, pero al menos cargaba rápidamente.
---
La Cuestión de AVIF
Cada vez que escribo sobre WebP alguien pregunta sobre AVIF. Justo.
AVIF es el siguiente paso. Se basa en el códec de video AV1, produce archivos aún más pequeños que WebP (a menudo 20-30% más pequeños en fotografías), y maneja correctamente contenido HDR. El soporte de navegadores es ahora sólido para Chrome, Firefox y Safari. El problema es la velocidad de codificación. AVIF es lento de codificar, lento de manera significativa. Ejecutar una conversión por lotes de 4,000 imágenes de productos a través de AVIF en un VPS te tomará mucho tiempo. WebP es significativamente más rápido de producir.Browser support is now solid for Chrome, Firefox, and Safari. The problem is encoding speed. AVIF is slow to encode, meaningfully slow. Running a batch conversion of 4,000 product images through AVIF on a VPS will take you a long time. WebP is significantly faster to produce.
Mi pensamiento actual: usa WebP como tu formato de entrega predeterminado. Si estás construyendo un sitio de alto tráfico donde las ganancias de compresión extra de AVIF justifican el overhead de codificación, sirve AVIF a navegadores que lo soportan con un respaldo a WebP. El elemento <picture> con <source type="image/avif"> maneja esto sin necesidad de JavaScript.<picture> element with <source type="image/avif"> handles this without any JavaScript.
No dejes que la parálisis de AVIF te mantenga en JPEG. WebP es el default pragmático correcto en este momento.
---
Mi Flujo de Trabajo Real para Elegir un Formato
Después de 9 años y más de 12,000 sitios, así es aproximadamente cómo lo pienso:
- ¿Es una fotografía o una imagen fotorrealista? Comienza con WebP con pérdida a calidad 80-85. Compáralo contra JPEG a calidad 75. Toma el más pequeño que pase la prueba de entrecerrar los ojos. Start with WebP lossy at quality 80-85. Compare against JPEG at quality 75. Take the smaller one that passes the squint test.
- ¿Es un gráfico, logo o ilustración con colores planos? SVG si es posible, PNG si no. WebP sin pérdida es una opción pero raramente la mejor. SVG if possible, PNG if not. WebP lossless is an option but rarely the best one.
- ¿Es una captura de pantalla con texto? PNG. Siempre PNG. JPEG y WebP introducen artefactos alrededor de los bordes del texto que se ven terribles. PNG. Always PNG. JPEG and WebP both introduce artefacts around text edges that look terrible.
- ¿Se sirve a través de un CDN moderno que hace negociación de formato automáticamente? Si estás en Cloudflare con Polish habilitado, o usando Cloudinary, o Imgix, honestamente no necesitas preocuparte mucho. Detectarán el navegador y servirán el formato óptimo. Deja que las herramientas lo manejen. If you're on Cloudflare with Polish enabled, or using Cloudinary, or Imgix, then honestly you don't need to worry much. They'll detect the browser and serve the optimal format. Let the tooling handle it.
- ¿Es un sitio WordPress? Instala ShortPixel o Imagify y configúralos para convertir al subir. Listo. No necesitas gestionar esto manualmente en absoluto. Install ShortPixel or Imagify and configure them to convert on upload. Done. You don't need to manually manage this at all.
Una palabra sobre configuraciones de calidad
Calidad 80 no es calidad 60. Veo desarrolladores configurar calidad WebP en 60 porque "sigue siendo mejor que JPEG" y luego se preguntan por qué los clientes se quejan de fotos de productos opacas. Haz el control visual adecuadamente. Ejecuto cada decisión de formato a través de Squoosh en el navegador, alternando entre original y salida con la herramienta de vista dividida. Toma 3 minutos por tipo de imagen y evita discusiones con clientes.
---
Cuándo JPEG Sigue Siendo la Respuesta Correcta
Lo diré claramente porque no veo a suficientes personas diciéndolo: JPEG no es obsoleto.
Si estás construyendo un sitio donde las imágenes serán descargadas y re-editadas (portafolios de fotografía, librerías de imágenes de stock, bibliotecas de activos de prensa), JPEG sigue siendo sensato. Es universalmente compatible en cada aplicación de edición de imágenes en la Tierra. La calidad de exportación WebP en herramientas como Photoshop ha mejorado dramáticamente, pero el ecosistema alrededor de JPEG para flujos de trabajo de post-procesamiento es simplemente más maduro.
Además, si tus imágenes ya están bien optimizadas como JPEG (digamos, menos de 100KB para una imagen de 800px de ancho), la conversión a WebP produce quizás 15-20KB de ahorro. No es cero, pero no vale la pena el tiempo de ingeniería si estás haciendo la conversión manualmente. Elige tus batallas.
Y si estás imprimiendo. Obvio. WebP es un formato web. No lo uses para nada que termine en papel.
---
Herramientas prácticas que vale la pena conocer
Estas son las herramientas que realmente uso, no una lista inflada:
- [Squoosh](https://squoosh.app/): Basado en navegador, sin instalación, brillante para comparaciones puntuales y encontrar la configuración de calidad correcta antes de automatizar cualquier cosa. Browser-based, no install, brilliant for one-off comparisons and finding the right quality setting before automating anything.
- Squoosh CLI: Conversión por lotes desde la terminal. La uso para migraciones a nivel de proyecto. Batch conversion from the terminal. I use this for project-level migrations.
- ShortPixel: El mejor plugin de WordPress para conversión automatizada al subir. La configuración con pérdida es sensata lista para usar. Best WordPress plugin for automated conversion on upload. The lossy setting is sensible out of the box.
- Cloudflare Polish: Si ya estás en Cloudflare Pro, actívalo. Convierte y comprime en el perímetro automáticamente. Sin código requerido. If you're already on Cloudflare Pro, turn this on. It converts and compresses at the edge automatically. Zero code required.
- Cloudinary: La opción para operaciones editoriales o de comercio electrónico más grandes donde necesitas negociación de formatos, dimensionamiento responsivo y entrega CDN como servicio administrado. The choice for larger editorial or e-commerce operations where you need format negotiation, responsive sizing, and CDN delivery as a managed service.
- ImageMagick: conversión desde la línea de comandos para flujos de trabajo del lado del servidor. Más lento que Squoosh CLI pero más flexible para canalizaciones con scripts. Command-line conversion for server-side workflows. Slower than Squoosh CLI but more flexible for scripted pipelines.
---
FAQ
¿WebP siempre es más pequeño que JPEG?
No. Desearía que la gente dejara de decir esto. En imágenes altamente detalladas, de alta frecuencia (piensa en: fotografía macro de texturas ásperas, tomas arquitectónicas densamente detalladas), la diferencia de tamaño puede ser insignificante o incluso invertirse dependiendo de la configuración del codificador. Prueba tus imágenes específicas en lugar de asumir.
¿Necesito mantener el JPEG original si convierto a WebP?
Sí. Siempre mantén tus originales. WebP es un formato de entrega, no un formato de archivo. Si ejecutas un sitio WordPress con ShortPixel, el plugin mantiene el original por defecto. No cambies esa configuración.
¿Convertir a WebP dañará mi SEO de imágenes?
No. Google indexa imágenes WebP sin ningún problema. Asegúrate de que tu texto alternativo sea descriptivo y que tus nombres de archivo tengan sentido. El formato no tiene efecto en los rankings de búsqueda de imágenes.
¿Qué hay del elemento `<picture>` versus simplemente servir WebP directamente?
Si el 97%+ de tus usuarios soporta WebP, servir WebP directamente mediante una etiqueta <img> está bien. El elemento <picture> con fuentes de respaldo tenía sentido cuando Safari era la excepción. Ahora es principalmente útil para el patrón AVIF-con-respaldo-WebP que mencioné antes.<img> tag is fine. The <picture> element with source fallbacks made sense when Safari was the holdout. Now it's mainly useful for the AVIF-with-WebP-fallback pattern I mentioned earlier.
¿El formato de imagen afecta el CLS (Cumulative Layout Shift)?
El formato en sí no. Pero si estás convirtiendo imágenes y no estableces atributos explícitos de width y height (o usas aspect-ratio en CSS), obtendrás cambios de diseño independientemente del formato. Este es uno de los errores más comunes que veo cuando las personas hacen migraciones de formato en masa. Arregla tus dimensiones.width and height attributes (or using aspect-ratio in CSS), you'll get layout shift regardless of format. This is one of the most common mistakes I see when people do bulk format migrations. Fix your dimensions.
---
Las decisiones sobre formato parecen pequeñas. No lo son. He visto una sola tarde de optimización de imágenes llevar un sitio de "fallar Core Web Vitals" a "pasar" y mover significativamente las tasas de conversión para clientes de comercio electrónico. WebP es la opción predeterminada correcta en 2026 para casi todas las fotografías entregadas por navegador. Pero es una opción predeterminada, no una regla. Sabe por qué estás tomando la decisión, prueba antes de automatizar, y mantén tus originales.