Lazy Loading vs Compresión: La Forma Correcta de Acelerar Imágenes
Ejecutaste Lighthouse en la página de aterrizaje de marketing y la puntuación es 47. La primera recomendación dice "diferir imágenes fuera de pantalla" y recuerdas haber añadido loading="lazy" a cada imagen el mes pasado. Lo hiciste. Lo publicaste. Funcionó. Luego revisas la segunda recomendación: "servir imágenes en formatos de última generación y dimensiones adecuadas". Esa sigue en rojo. Te quedas mirando la pantalla, ligeramente traicionado, y te preguntas cuál de estos dos consejos es realmente el que arregla la velocidad de la página.
"Solo añade lazy loading" y "solo comprime tus imágenes" son los dos consejos de rendimiento de imágenes más comunes en 2026, a menudo dados como si fueran intercambiables. No lo son. Resuelven problemas diferentes, en distintas partes del ciclo de vida de la página, y aplicar uno como sustituto del otro garantiza que dejes la mitad de la mejora sobre la mesa. Aquí está la forma correcta de pensar en ambos y el orden en que aplicarlos.
Antecedentes: las dos técnicas en términos simples
La compresión reduce la cantidad de bytes que pesa cada imagen. Un JPG de 2 MB comprimido a 400 KB ahora es un 80 por ciento más pequeño. Cada visitante descarga 1.6 MB menos. El ahorro de ancho de banda es universal en todo el ciclo de vida de la página — no importa cuándo se cargue la imagen; los bytes son más pequeños.
El lazy loading difiere la descarga de imágenes fuera de pantalla hasta que el usuario se desplaza cerca de ellas. Una página con 30 imágenes puede que solo descargue las 4 que son visibles en la parte superior. Las 26 debajo del pliegue nunca se descargan para los visitantes que rebotan. El ahorro depende del comportamiento del usuario — ayudan completamente a los visitantes que rebotan, y nada a los que se desplazan.
Son palancas independientes sobre la misma métrica general. Tirar de ambas te da el beneficio completo. Tirar de una sola deja un rendimiento medible sobre la mesa.
El orden de las operaciones
Comprime primero. Lazy-loading después.
La compresión beneficia a todos los que cargan cualquier imagen, incluida la imagen principal sobre el pliegue que el lazy loading no puede ayudar. El lazy loading solo beneficia a las imágenes debajo del pliegue y solo para los visitantes que no se desplazan. Si solo tienes tiempo para hacer una, comprime.
Hacer ambas es sencillo y multiplica la ganancia. Una página con 30 imágenes de 1 MB cada una (30 MB en total) se convierte en:
- Después de comprimir a 250 KB cada una: 7.5 MB en total — reducción del 75 por ciento
- Después de aplicar lazy loading a las 26 imágenes debajo del pliegue: 1 MB de carga inicial para un rebote, 7.5 MB en total para un desplazamiento completo
El visitante que rebotó descargó 1 MB en lugar de 30 MB. El visitante que se desplazó descargó 7.5 MB en lugar de 30 MB. Ambas mejoras vinieron de hacer ambas técnicas.
Cómo funciona realmente la compresión
La compresión JPG tiene tres palancas: calidad, submuestreo de croma y resolución. La mayoría de los JPG "comprimidos" en la web están en calidad 92 o superior desde la exportación predeterminada de Photoshop o Lightroom. Bajar a calidad 80 a 85 ahorra del 30 al 50 por ciento de bytes sin diferencia visible.
Los objetivos correctos:
- Imágenes principales: Calidad 82 a 85, 2x resolución de pantalla, WebP o AVIF preferido
- Imágenes de cuerpo: Calidad 78 a 82, 1.5x resolución de pantalla
- Miniaturas: Calidad 70 a 78, resolución de pantalla exacta
Usa comprimir JPG para verificar que la calidad objetivo se vea bien antes de aplicarla en todo un sitio. Convierte a WebP para un 30 por ciento adicional sobre la compresión de calidad.
Cómo funciona realmente el lazy loading
En 2026, el lazy loading nativo del navegador es la implementación correcta. Añade loading="lazy" a cualquier imagen que esté debajo del pliegue:
<img src="figure-5.webp" loading="lazy" alt="..." width="800" height="500">El navegador maneja la conexión de IntersectionObserver, la detección de desplazamiento y el momento de iniciar la carga. No se requiere ninguna librería JavaScript. Compatible con Chrome desde 76, Safari 15.4, y todos los navegadores principales en 2026.
Advertencia crítica: nunca apliques lazy loading a la imagen LCP. La imagen principal, la foto del producto sobre el pliegue, la imagen destacada del artículo — estas deben tener loading="eager" (o no establecerlo, que por defecto es eager). Aplicar lazy loading al elemento LCP retrasa su carga y perjudica el Core Web Vital.
Paso a paso: aplicando ambos correctamente
- Haz un inventario de las imágenes de la página. Enumera cada etiqueta
<img>y anota si está sobre o debajo del pliegue en la ventana de visualización objetivo más pequeña. - Audita las dimensiones y el peso de las fuentes mediante información de imagen en una muestra representativa.
- Redimensiona las fuentes a aproximadamente 2x las dimensiones de pantalla y vuelve a exportar.
- Convierte a WebP o AVIF mediante JPG a WebP o JPG a AVIF.
- Comprime con la calidad objetivo correcta usando Comprimir JPG o comprimir imagen.
- Aplica
loading="lazy"a cada imagen debajo del pliegue. - Aplica
fetchpriority="high"y precarga a la imagen LCP. - Mide antes y después con Lighthouse y confírmalo con datos de campo de CrUX.
El error de sustitución
El modo de fallo más común es "añadí lazy loading, mi sitio es rápido ahora". Por lo general no lo es. El lazy loading ayuda al Time to Interactive y reduce los bytes totales para los que rebotan, pero no hace casi nada por el LCP, que está dominado por la imagen principal. Si tu JPG principal es de 2.8 MB y solo añadiste lazy loading, tu LCP sigue siendo de 4 segundos en móvil.
El error inverso: "comprimí todas las imágenes, no necesito lazy loading". Si tienes 40 imágenes en una página de artículo larga e incluso con 200 KB cada una, el total es 8 MB. Un visitante que rebota sigue pagando por 7.2 MB de bytes que nunca vio. El lazy loading lo habría ahorrado.
Errores comunes y cómo solucionarlos
- Error: aplicar lazy loading a la imagen LCP. Solución: establece explícitamente
loading="eager"en las imágenes principales y verifica con PageSpeed Insights. - Error: comprimir iconos PNG como JPG. Solución: mantén los activos con transparencia como PNG o conviértelos mediante JPG a PNG cuando sea necesario; SVG es la opción correcta para iconos.
- Error: aplicar ambas técnicas sin verificar la LCP. Solución: identifica primero el elemento LCP y luego optimiza específicamente.
- Error: usar una biblioteca JS de lazy loading cuando la nativa funciona. Solución: reemplaza la biblioteca por el atributo nativo
loadingy elimina una dependencia. - Error: establecer la calidad JPG en 60 para "comprimir mucho". Solución: 78-82 es el punto óptimo; valores más bajos introducen artefactos visibles.
- Error: no establecer ancho/alto en imágenes con lazy loading. Solución: cada imagen necesita dimensiones explícitas para evitar el CLS.
Ejemplos reales
Medium.com aplica un lazy loading nativo agresivo en cada imagen fuera del pliegue y comprime las principales mediante su pipeline interno. La LCP media en páginas de artículos es de 1.6 segundos en 4G, una cifra difícil de superar en editorial.
El feed principal de Pinterest aplica lazy loading a todo lo que está debajo de la primera fila de pines. Combinado con el uso de WebP, la carga inicial de la página es inferior a 500 KB aunque el feed contenga cientos de pines.
Un sitio de concesionario de coches (anonimizado) aplicó solo lazy loading y no vio cambios en la LCP. Después de añadir compresión a la foto principal del coche (3.2 MB JPG a 280 KB WebP), la LCP bajó de 5.1 segundos a 1.9 segundos. El lazy loading solo ayudó después de que la compresión desbloqueara la imagen principal.
En qué no ayuda el lazy loading
- El primer viewport. Las imágenes sobre el pliegue se cargan de forma eager independientemente. La compresión es la única palanca ahí.
- Vista previa de impresión. Las imágenes con lazy loading pueden no renderizarse en las vistas previas de impresión a menos que el usuario ya haya hecho scroll sobre ellas.
- Motores de búsqueda. Googlebot puede hacer scroll, pero los despliegues lentos de lazy loading han causado históricamente problemas de indexación. Establece ancho y alto explícitos en las imágenes con lazy loading para que el diseño reserve espacio.
En qué no ayuda la compresión
- Número total de solicitudes. 30 imágenes comprimidas siguen siendo 30 solicitudes HTTP, cada una con overhead de handshake. El multiplexado HTTP/2 ayuda, pero el número en sí no cambia.
- Cargadores de imágenes basados en JavaScript. Si las cargas de imágenes ocurren mediante frameworks JS (Next.js Image, Gatsby Image), la compresión debe aplicarse en tiempo de compilación; la compresión en tiempo de ejecución llega demasiado tarde.
- Percepción del ancho de banda del visitante. Un usuario con Wi-Fi lento que descarga 30 imágenes de 200 KB cada una sigue viendo una página lenta si todas se cargan a la vez. El lazy loading escalona la demanda.
Compresión vs lazy loading de un vistazo
| Aspecto | Compresión | Carga diferida |
|---|---|---|
| Ayuda a la LCP | Sí | No (y perjudica si se aplica mal) |
| Ayuda al TTI | Algo | Sí |
| Ayuda a los que rebotan | Algo | Mucho |
| Ayuda a los que hacen scroll | Todos | Ninguno |
| Esfuerzo de aplicación | Media | Bajo |
| Riesgo si se aplica mal | Artefactos visibles | Regresión de LCP |
La pila 2026: haz ambos, en este orden
- Redimensiona las imágenes de origen a aproximadamente 2x las dimensiones de visualización previstas. Una imagen de visualización de 1,200 px comienza como una fuente de 2,400 px.
- Comprime y convierte a formato moderno. WebP calidad 80 o AVIF calidad 70. Verifica con el convertidor de imágenes o comprimir JPG como comprobación puntual.
- Añade fetchpriority=high a la imagen principal y precárgala desde el head.
- Añade loading=lazy a cada imagen fuera del pliegue.
- Establece ancho y alto explícitos en todas las imágenes para evitar cambios de diseño.
- Sirve mediante CDN con HTTP/2 o HTTP/3.
- Mide con PageSpeed Insights antes y después.
Los números de una auditoría real
Una auditoría de mediados de 2026 de una página de blog con 30 imágenes mostró:
- Antes: 28 MB de peso total, LCP 4.8 s, TTI 8.2 s en 4G
- Solo con compresión: 6 MB en total, LCP 2.1 s, TTI 4.6 s
- Con compresión + carga diferida: 6 MB en total al hacer scroll, 0.9 MB iniciales, LCP 2.1 s, TTI 1.8 s en la primera renderización
La compresión ganó en LCP (la imagen principal pasó de 2.4 MB a 380 KB). La carga diferida ganó en TTI y en visitantes que rebotaron (29 imágenes diferidas). Cualquiera de las dos por sí sola habría dejado mejoras significativas sobre la mesa.
Consejos avanzados
- Usa
decoding="async"en imágenes que no sean LCP para evitar bloquear el hilo principal. - Establece una regla CSS de content-visibility en las secciones que están debajo del pliegue para que el navegador omita el trabajo de maquetación hasta que se haga scroll.
- Genera un marcador de posición de imagen de baja calidad (LQIP) como base64 en línea para una renderización instantánea antes de que llegue la imagen de alta resolución.
- Usa la calculadora de tamaño de archivo de imagen para presupuestar tus recuentos de bytes de antemano.
- Audita las imágenes periódicamente — los editores de contenido que suben archivos enormes son la causa principal de regresiones.
- Considera
loading="lazy"también en iframes; las inserciones de YouTube suelen ser el segundo elemento LCP más grande después de las imágenes. - Prueba con una conexión limitada (Slow 3G en DevTools) para sentir lo que experimentan los usuarios reales.
Preguntas frecuentes
¿La carga diferida funciona en todos los navegadores en 2026?
Sí: Chrome, Safari, Firefox y Edge son compatibles con loading="lazy" nativo.
¿Debería usar también una biblioteca JavaScript de carga diferida?
No, el método nativo es suficiente y evita una dependencia.
¿Con qué agresividad debo comprimir?
Calidad 78-82 para JPG, 75-80 para WebP, 65-75 para AVIF. Valores más bajos corren el riesgo de artefactos visibles.
¿La carga diferida afecta al SEO?
No negativamente si se establecen width/height. Googlebot puede renderizar contenido cargado de forma diferida.
¿La carga diferida romperá mi galería de imágenes?
Generalmente no, pero las galerías que calculan la maquetación a partir de las dimensiones de la imagen necesitan los atributos width/height.
¿Puedo cargar de forma diferida imágenes de fondo?
No de forma nativa: background-image no se puede cargar de forma diferida. Conviértelo a <img> si es necesario.
¿Cómo sé qué imagen es mi LCP?
PageSpeed Insights lo resalta explícitamente. La pestaña de rendimiento de Chrome DevTools también lo etiqueta.
Plan de acción para mañana
Si tienes una hora: identifica tu imagen LCP, conviértela mediante JPG a WebP y Comprimir JPG, y envía la versión optimizada. Eso por sí solo mueve la aguja de forma visible.
Si tienes una tarde: haz la pila completa de siete pasos anterior. Pasa una muestra representativa por comprimir imagen para confirmar los objetivos de calidad, luego automatiza el resto en un script de compilación o CDN. El resultado es un sitio mediblemente más rápido, mejores Core Web Vitals y facturas de ancho de banda más bajas, todo gracias a la combinación correcta de dos técnicas que la gente sigue tratando como sustitutas. Combínalo con el convertidor de imágenes para el trabajo continuo con formatos.
Costo de decodificación: la tercera palanca de la que nadie habla
La compresión reduce los bytes transferidos; la carga diferida aplaza las descargas. Ambas ignoran el tercer costo: la decodificación. En un teléfono Android de gama media, decodificar un JPG de 4 MP tarda de 80 a 150 ms de tiempo en el hilo principal. Decodificar 20 imágenes así en secuencia puede bloquear la interfaz durante 1.5 a 3 segundos, visible como tirones al hacer scroll o toques que no responden.
El atributo decoding="async" en <img> le indica al navegador que decodifique fuera del hilo principal cuando sea posible. El comportamiento predeterminado en 2026 suele ser asíncrono, pero la declaración explícita ayuda en contextos WebView más antiguos (navegadores integrados en aplicaciones de Facebook, Instagram, Twitter). Combinado con dimensiones de imagen más pequeñas, el costo de decodificación cae a menos de 20 ms por imagen y los tirones al hacer scroll desaparecen.
Formato de imagen y consumo de energía
Un costo poco discutido de las imágenes grandes es el consumo de batería. Decodificar un JPG pesado quema ciclos de CPU, que queman batería. En una sesión móvil que carga 30 JPG de tamaño heroico, el impacto acumulativo en la batería puede ser medible: fracciones de un porcentaje, pero multiplicado por miles de visitas a páginas al día en millones de dispositivos.
Tanto WebP como AVIF decodifican más rápido por byte que JPG (archivos más pequeños, decodificadores modernos), por lo que la conversión de formato tiene un beneficio energético pequeño pero real. Para un panel de impacto ambiental, los ahorros se traducen en reducciones modestas en la energía del centro de datos y del dispositivo cliente, algo que los compradores empresariales con conciencia de sostenibilidad siguen cada vez más.
Cuando la carga diferida sale mal
Dos modos de fallo que vale la pena conocer. Primero, los feeds de desplazamiento infinito que cargan de forma diferida de manera agresiva pueden privar de recursos a la imagen LCP porque el IntersectionObserver activa la carga de imágenes fuera de pantalla antes de que termine la imagen principal. Solución: establece explícitamente fetchpriority="high" en la imagen principal y confirma que la imagen LCP no esté también marcada como loading="lazy".
Segundo, las imágenes con carga diferida dentro de iframes con carga diferida (como una tarjeta de Twitter insertada con una miniatura diferida de YouTube) pueden crear cadenas de doble diferimiento donde el usuario hace scroll y espera 200 a 400 ms adicionales para que se resuelva la cadena. Solución: como máximo una capa de carga diferida por árbol de contenido. Los iframes sobre el pliegue deben ser inmediatos incluso si su contenido es diferido.
Compresión y percepción de velocidad
Los milisegundos puros importan menos que la velocidad percibida. Una página que renderiza un marcador de posición en 200 ms y la imagen principal en 1.4 s se siente más rápida que una página que no renderiza nada durante 1.0 s y luego lo muestra todo de golpe. La compresión te lleva a «todo de golpe» más pronto; las estrategias de marcador de posición (LQIP, blurhash, CSS de color dominante) hacen que la espera se sienta más corta.
Implementa un fondo de color dominante en cada contenedor de imagen mediante paleta de colores. El fondo CSS se pinta con la página; la imagen aparece gradualmente a medida que llega. La diferencia visual es pequeña, pero la ganancia de rendimiento percibida es real, especialmente en conexiones lentas donde la imagen tarda 2+ segundos en descargarse.
Para ir más allá del color, genera un blurhash de 20 bytes a partir de cada imagen e insértalo como un marcador de posición SVG en base64. El marcador de posición tiene aproximadamente los colores correctos en aproximadamente los lugares correctos, y la imagen de alta resolución aparece gradualmente. Este patrón fue pionero de Medium y ahora es estándar en Instagram, Pinterest y la mayoría de los sitios con muchas imágenes.
El enfoque de HTTP/2 y HTTP/3
La compresión y la carga diferida interactúan con el protocolo subyacente. HTTP/2 multiplexa muchas solicitudes de imágenes en una sola conexión TCP, por lo que la sobrecarga por solicitud disminuye. HTTP/3 usa QUIC sobre UDP, que maneja mejor la pérdida de paquetes que TCP y produce cargas de página con muchas imágenes más rápidas en conexiones móviles inestables.
Si tu CDN ya sirve sobre HTTP/3, las ventajas de la carga diferida se acumulan: las imágenes diferidas pueden cargarse en paralelo sin hacer cola detrás de la imagen principal. Si todavía usas HTTP/1.1 con un grupo de conexiones pequeño, la carga diferida es realmente necesaria para evitar la inanición de conexiones. La mayoría de las CDN modernas (Cloudflare, Fastly, Akamai) usan HTTP/3 por defecto en 2026; si la tuya no lo hace, considera cambiarla.
Midiendo los ahorros honestamente
Es fácil exagerar el impacto de cualquiera de las dos técnicas. El ciclo de medición honesto: recopila métricas base durante una semana (LCP, peso total de la página, tasa de rebote), implementa la compresión, mide durante otra semana. Implementa la carga diferida, mide durante otra semana. Las dos pasadas te permiten atribuir los cambios correctamente.
Cuidado con las variables de confusión. Un pico de tráfico de una campaña de marketing puede mover las métricas por razones no relacionadas con tu trabajo de imágenes. Los efectos del día de la semana (fin de semana con mucho móvil, entre semana con mucho escritorio) cambian la mezcla. Los lanzamientos de versiones de navegadores (Chrome 130 vs 131) pueden cambiar la distribución de formatos compatibles. Espera al menos 7 días de condiciones estables antes de declarar una victoria.
La calibración de calidad visual
Antes de aplicar configuraciones de compresión agresivas en producción, calibra según la percepción real del espectador. Muestra a 10 colegas dos versiones de una imagen principal — calidad 95 y calidad 78 — y pregunta cuál se ve mejor. Si menos de 7 de 10 identifican correctamente la diferencia, la calidad 78 es tu objetivo seguro. Si 9 de 10 notan la diferencia, necesitas calidad 85 o superior.
La calibración importa porque la calidad subjetiva varía según el contenido. Los tonos de piel perdonan la compresión; las fotos de productos sobre fondos blancos no. Realiza la calibración por tipo de contenido en lugar de elegir un umbral global. El resultado es una tabla de calidad por clase de activo que refleja lo que tu audiencia real puede percibir.