¿Cómo optimizar las imágenes para la web? La guía 2026 de AVIF, WebP y LCP
Optimizas las imágenes tratándolo como una disciplina de cuatro atributos, no como una tarea de una línea — y acertando los cuatro en cada imagen. Sirve un formato moderno (AVIF, con WebP y JPEG de respaldo) con un elemento <picture>; redimensiona cada imagen a sus dimensiones de visualización y ofrece anchos responsivos con srcset y sizes; marca la imagen hero principal —normalmente tu elemento Largest Contentful Paint— con fetchpriority="high" y nunca le hagas lazy-load, mientras haces lazy-load de todo lo que está bajo la línea de flotación; y pon width y height explícitos para que el diseño no se desplace. Esto importa más que casi cualquier otro trabajo de velocidad porque las imágenes causan el LCP en cerca del 85% de las páginas de escritorio y son alrededor de la mitad del peso total, así que una hero sin optimizar pierde la batalla más importante de Core Web Vitals antes de que el resto de la página corra. Hazlo una vez en tu pipeline de build y cada página sale optimizada.
¿Por qué las imágenes son el arreglo de rendimiento de mayor retorno?
Porque son a la vez lo más pesado y lo más visible de la mayoría de las páginas. Según el Web Almanac 2025 de HTTP Archive, las imágenes son responsables del Largest Contentful Paint en cerca del 85% de las páginas de escritorio y el 76% de las móviles, y representan alrededor del 48% del peso total de la página en el sitio mediano (Logos Web Designs, 2026). Casi todas las páginas —el 99,9%— cargan al menos una imagen (DEV / Cloudinary, 2026).
Junta esos dos hechos y la prioridad es obvia: si tu imagen hero está sin optimizar —el formato equivocado, sin variantes responsivas, sin pista de prioridad— pierdes la batalla más importante de Core Web Vitals antes de que el resto del sitio tenga oportunidad de correr (Logos Web Designs, 2026). Por eso el retorno es tan alto. Una sola estrategia de imágenes bien hecha puede recortar los tiempos de carga por un margen grande, y como el LCP suele ser una imagen, la métrica que afecta tu posicionamiento se mueve con ella. Este es el lado de los recursos del trabajo de Core Web Vitals, vuelto concreto.
¿Qué formato debes usar?
AVIF primero, WebP de respaldo, JPEG o PNG como red de seguridad — entregados para que el navegador elija el mejor que soporta. AVIF comprime cerca de un 50% más pequeño que JPEG y alrededor de un 30% más que WebP a calidad similar, con cerca del 94,9% de soporte de navegadores a inicios de 2026; WebP es cerca de 25-35% más pequeño que JPEG con cerca del 96,4% de soporte (Logos Web Designs, 2026; Two Row Studio, 2026). El elemento <picture> maneja la selección en un solo bloque de HTML:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="..." width="1200" height="630">
</picture>
Una regla rápida cubre la mayoría de los casos: las fotos van a AVIF (con respaldo WebP/JPEG), los gráficos con transparencia a WebP (con respaldo PNG), y los logos e iconos a SVG, que guarda instrucciones de dibujo en vez de píxeles y escala sin pérdida (imgpact, 2026). Un compromiso honesto: AVIF puede ser costoso de codificar a escala, así que si subes imágenes constantemente, una opción razonable es WebP como salida por defecto con AVIF reservado para las páginas de alto impacto (Mohtaweb, 2026).
¿Qué tan agresivamente debes comprimir?
Más de lo que casi todos asumen — el truco es hallar el punto justo antes de que la calidad caiga de forma visible. Para fotos, WebP en calidad 75-85 produce archivos visualmente indistinguibles de JPEG calidad 85, a cerca de un cuarto o un tercio del tamaño, y AVIF en 60-70 normalmente iguala a JPEG 85 (Logos Web Designs, 2026). Baja de AVIF 60 y empiezas a ver artefactos de bloque característicos en regiones de color plano como cielos y paredes, así que ese es el piso para las fotografías (Logos Web Designs, 2026).
Dos ajustes lo afinan. Las ilustraciones y capturas —contenido sintético con áreas planas y bordes nítidos— toleran una compresión más agresiva que las fotografías, así que puedes bajarles más la calidad (Logos Web Designs, 2026). Y nunca exportes en calidad 100, que gasta bytes sin ganancia visible. La forma confiable de elegir es probar visualmente un conjunto representativo de tus propias imágenes —rostros, degradados, texto— con una herramienta como Squoosh, en vez de confiar en un único número global (Mohtaweb, 2026).
¿Cómo sirves el tamaño correcto?
Nunca enviando una imagen más grande de lo que la pantalla mostrará. El desperdicio más común es subir una foto de 4000×3000 para mostrarla a 800×600 — el navegador descarga la resolución completa y luego la reduce, gastando ancho de banda sin beneficio visible (imgpact, 2026). Redimensiona cada imagen a sus dimensiones máximas de visualización antes de publicarla.
Después deja que el navegador elija el tamaño correcto por dispositivo con imágenes responsivas. Los atributos srcset y sizes ofrecen varios anchos y dejan que el navegador elija según la pantalla, para que un teléfono no se vea forzado a descargar un archivo de tamaño de escritorio:
<img src="foto-800.jpg"
srcset="foto-400.jpg 400w, foto-800.jpg 800w, foto-1200.jpg 1200w"
sizes="(max-width: 600px) 400px, 800px"
alt="..." width="800" height="600" loading="lazy">
Las pantallas de alta densidad como Retina y 4K necesitan una imagen 1,5x o 2x para verse nítidas, pero puedes comprimirlas más agresivamente, porque los artefactos de compresión son más difíciles de ver a alta densidad de píxeles (Two Row Studio, 2026). Una advertencia: los conversores de formato que ignoran el tamaño responsivo todavía pueden desperdiciar mucho ancho de banda al servir un formato moderno en las dimensiones equivocadas — arregla srcset y sizes primero, luego los formatos y la calidad (Mohtaweb, 2026).
¿Qué protege tus Core Web Vitals?
Dos atributos hacen casi todo el trabajo, uno para el LCP y otro para el CLS. Lo de mayor impacto que puedes hacer por el LCP es marcar tu imagen sobre la línea de flotación con fetchpriority="high": los propios ingenieros de Google documentaron pruebas donde añadir ese atributo mejoró el LCP de 2,6 segundos a 1,9 segundos — una ganancia del 27% con un solo fragmento de HTML (Logos Web Designs, 2026). El error espejo es hacerle lazy-load a esa misma imagen: hacer lazy-load de la imagen LCP retrasa la métrica que intentas mejorar y es un fallo directo de Core Web Vitals, así que carga siempre de forma anticipada lo que está sobre la línea de flotación (imgpact, 2026).
El lazy-load igual importa — solo que para todo lo demás. Añadir loading="lazy" a las imágenes bajo la línea de flotación las difiere hasta que el usuario se acerca al hacer scroll, lo que reduce la competencia por el ancho de banda y puede dejar que la imagen LCP descargue más rápido (MDN, 2026). El segundo atributo protector son las dimensiones: pon width y height explícitos en cada imagen para que el navegador reserve el espacio correcto antes de que el archivo cargue. Sin ellos, el navegador no sabe qué tan alto hacer el contenedor, el contenido de abajo salta cuando llega la imagen, y tu puntuación de CLS se dispara (Logos Web Designs, 2026). La mecánica de ambas métricas está en nuestra guía sobre cómo aprobar los Core Web Vitals.
¿Cuál es el orden correcto para hacer esto?
La imagen más grande primero, una plantilla a la vez. Identifica la imagen LCP —normalmente la hero o destacada— con Lighthouse o Chrome DevTools, crea tres anchos responsivos de ella en AVIF y WebP, conecta el <picture>, el srcset y el sizes, asegúrate de que no tenga lazy-load, y pon su width y height (Mohtaweb, 2026). Vuelve a probar esa página, confirma que el LCP se movió, y aplica el mismo patrón a la siguiente plantilla.
Esta secuencia importa porque evita una trampa común: optimizar todo a la vez, y descubrir después que una actualización de tema o un plugin entra en conflicto con tus cambios (Mohtaweb, 2026). Una plantilla, una victoria medida, y luego escala. Trabajar de lo más grande a lo más chico también significa que gastas tu esfuerzo donde la métrica de verdad vive, en vez de comprimir docenas de imágenes pequeñas de abajo que nunca fueron el cuello de botella.
¿Deberías automatizarlo?
Sí — afinar cada imagen a mano no escala, y los mejores equipos lo mueven al build. La práctica recomendada es un pipeline de imágenes en tiempo de build que genera automáticamente variantes AVIF, WebP y JPEG en varios anchos responsivos, con fetchpriority, width/height explícitos y el atributo loading correcto conectados en las plantillas, para que cada despliegue salga con activos perfectamente optimizados (Logos Web Designs, 2026). Herramientas como Vite, un componente de imagen de framework, o una CDN de imágenes como Cloudinary o ImageKit pueden hacer esa conversión y ese redimensionado por ti (LearnHubly, 2026).
Aquí es donde una arquitectura estática y de build-primero tiene una ventaja estructural: el pipeline de imágenes corre una vez en tiempo de build y hornea el formato, el tamaño y los atributos correctos en el HTML, así la página es rápida por construcción en vez de parcheada por un plugin después. Es el mismo principio detrás de nuestra guía sobre si Astro es bueno para el SEO y el rendimiento — haz el trabajo en tiempo de build, entrega el resultado, y no queda nada que frene al visitante.
No olvides el texto alternativo
Cada imagen necesita texto alternativo descriptivo, y cumple doble función. El texto alternativo es lo que un lector de pantalla anuncia y lo que se muestra si la imagen no carga, lo que lo vuelve un requisito de accesibilidad; también le da a los buscadores y a los asistentes de IA una descripción de la imagen, lo que es un beneficio de SEO (Two Row Studio, 2026). El estándar al que apuntar es específico y con significado — “panel de WordPress mostrando métricas de Core Web Vitals”, no “imagen123.jpg” ni un atributo en blanco (Two Row Studio, 2026).
La única excepción son las imágenes decorativas que no llevan información: dales un alt="" vacío para que la tecnología asistiva las salte en vez de leer un nombre de archivo. Manejar bien el texto alternativo también es parte del trabajo de accesibilidad en nuestra checklist WCAG 2.2 — otro caso donde un buen hábito sirve al rendimiento, la accesibilidad y la búsqueda a la vez.
¿Cómo las entregas rápido una vez optimizadas?
Dos hábitos de entrega rematan el trabajo. Cachea las imágenes optimizadas de forma agresiva, sobre todo cuando los nombres de archivo van versionados con un hash de contenido, para que un visitante que regresa nunca vuelva a descargar una imagen que no cambió (Mohtaweb, 2026). Y sírvelas desde una CDN, para que el archivo viaje desde un servidor cercano al visitante y no a través del mundo — las CDN de optimización de imágenes también pueden hacer la conversión de formato y el redimensionado en el borde (Hashmeta, 2026). La optimización decide cuántos bytes envías; la caché y la CDN deciden qué tan rápido llegan esos bytes, y una página rápida necesita ambas. En una construcción estática y alojada en el borde, las dos son lo predeterminado y no un añadido que pegas después.
El beneficio
Los números son inusualmente grandes para lo mecánico que es el trabajo. Una pasada completa de optimización de imágenes suele reducir el peso total de imagen de la página en un 60-80%, y como el LCP suele ser una imagen, eso se ve directo en la métrica: hay casos documentados de sitios con muchas imágenes que bajan de más de cuatro segundos a cerca de uno tras la conversión a AVIF y la entrega responsiva (imgpact, 2026; LearnHubly, 2026).
Ese es todo el argumento para tratar las imágenes como el primer lugar donde mirar cuando una página es lenta. Son la mitad de tu peso de página y la causa más probable de un LCP que falla, los arreglos están bien entendidos y son casi todos mecánicos, y el resultado es un sitio más rápido que posiciona y convierte mejor. Para ver dónde encaja esto en el cuadro más grande de la velocidad como factor de posicionamiento e ingresos, nuestro pilar sobre Core Web Vitals y velocidad web es el lugar al que ir después.
Frequently asked
- ¿Cómo se optimizan las imágenes para la web?
- Trátalo como una disciplina de cuatro atributos y no como una tarea de una línea. Sirve formatos modernos — AVIF con un respaldo de WebP y JPEG, entregados con un elemento picture. Redimensiona las imágenes a sus dimensiones de visualización y ofrece anchos responsivos con srcset y sizes. Marca la imagen hero principal (LCP) con fetchpriority='high' y nunca le hagas lazy-load, mientras haces lazy-load de todo lo que está bajo la línea de flotación. Y pon width y height explícitos en cada imagen para evitar el desplazamiento de diseño. Salta cualquiera de esos cuatro y los demás rinden de menos.
- ¿Uso AVIF o WebP en 2026?
- Usa ambos, con AVIF primero. AVIF comprime cerca de un 50% más pequeño que JPEG y alrededor de un 30% más que WebP a calidad similar, y tiene cerca del 95% de soporte de navegadores; WebP es cerca de 25-35% más pequeño que JPEG con cerca del 96% de soporte. El enfoque estándar es un elemento picture que sirve AVIF a los navegadores que lo soportan, WebP como respaldo, y JPEG o PNG como última red de seguridad. Si subes imágenes constantemente y codificar AVIF es muy costoso a escala, usa WebP por defecto y reserva AVIF para las páginas de alto impacto.
- ¿Debo hacer lazy-load de las imágenes?
- Sí para las imágenes bajo la línea de flotación, nunca para tu imagen hero o LCP. Añadir loading='lazy' a las imágenes de abajo las difiere hasta que el usuario se acerca al hacer scroll, lo que libera ancho de banda para que la imagen importante cargue más rápido. Pero hacer lazy-load de la imagen LCP retrasa justo la métrica que intentas mejorar y es un fallo directo de Core Web Vitals. Carga de forma anticipada todo lo que está sobre la línea de flotación, e idealmente marca la imagen LCP con fetchpriority='high'.
- ¿Qué ajuste de calidad de imagen debo usar?
- Para fotos, WebP en calidad 75-85 se ve visualmente indistinguible de JPEG 85 a una fracción del tamaño, y AVIF en 60-70 normalmente iguala a JPEG 85. Bajar de AVIF 60 empieza a mostrar artefactos de bloque en áreas planas como cielos y paredes. Las ilustraciones y capturas toleran una compresión más agresiva. Nunca exportes en calidad 100, y prueba los ajustes visualmente con una herramienta como Squoosh en vez de adivinar.
- ¿Cuánto más rápido será mi sitio al optimizar las imágenes?
- Mucho, porque las imágenes suelen ser lo más pesado de la página. Una pasada completa de optimización de imágenes suele recortar el peso total de imagen en un 60-80%, y como las imágenes causan el Largest Contentful Paint en la mayoría de las páginas, eso a menudo se traduce en una gran mejora del LCP — hay casos documentados de sitios con muchas imágenes que pasan de más de cuatro segundos a cerca de uno. Es, en general, el cambio de rendimiento de mayor retorno que puedes hacer.