Hay Dos Formas Completamente Distintas en que una Imagen Puede Ser Demasiado Grande

Cuando los desarrolladores piensan en optimización de imágenes, generalmente piensan en compresión: pasar el archivo por una herramienta, reducir la configuración de calidad, hacer los bytes más pequeños. Esa es una técnica legítima e importante. Pero no es de donde provienen los mayores ahorros en la mayoría de los sitios.

Los dos problemas son distintos y deben abordarse en el orden correcto:

1: La imagen tiene el tamaño incorrecto para su contenedor

Las dimensiones del archivo de imagen son mucho mayores que las dimensiones del elemento en el que se renderiza. Este es el problema más común y el que causa más desperdicio. He visto casos donde "desarrolladores" (me refiero a diseñadores) enviaban 2,400 píxeles de imagen a un elemento del navegador que lo renderizará a 600 píxeles de ancho. El navegador descarga los 2,400 píxeles completos, decodifica los 2,400 píxeles en memoria y luego escala la imagen para mostrarla. Los píxeles extra nunca se mostraron al usuario. Fueron desperdiciados por completo.

2: La imagen tiene el tamaño correcto pero está codificada de forma ineficiente

Las dimensiones son apropiadas, pero el formato del archivo está desactualizado (un JPEG del 2012), la configuración de calidad está al 100 "solo para estar seguros", o el archivo nunca ha sido comprimido desde que salió de una cámara o herramienta de diseño.

Ambos problemas desperdician ancho de banda. El primer problema desperdicia mucho más, y afecta a cada visitante de tu sitio independientemente de su dispositivo o velocidad de conexión.

El orden correcto es siempre servir las dimensiones correctas, luego comprimir esas dimensiones de manera eficiente. Comprimir una imagen de 2,400px que debería tener 400px de ancho sigue entregando cinco veces más píxeles de los que el navegador usará. Ninguna cantidad de compresión soluciona eso.

El Problema de Dimensionamiento en Números Reales

Hagamos esto concreto, porque los números son lo suficientemente impactantes como para cambiar la forma en que piensas sobre esto de manera permanente.

Toma una fotografía descargada de Unsplash o exportada desde una cámara. Una DSLR típica dispara a alrededor de 7,000 por 4,700 píxeles y produce un JPEG de aproximadamente 4 a 5 MB. Un fotógrafo podría exportar ese archivo y un desarrollador podría colocarlo directamente en un proyecto como imagen hero o ilustración de una publicación de blog.

Esa imagen se mostrará a un máximo de alrededor de 1,200 a 1,400 píxeles de ancho en la mayoría de los layouts de escritorio, y a 375 a 430 píxeles de ancho en una pantalla de teléfono móvil típica. La brecha entre el original y lo que realmente se renderiza en móvil no es pequeña.

Redimensionar esa imagen de 7,000 píxeles a 1,266 píxeles de ancho (apropiado para una pantalla de escritorio retina) reduce el tamaño del archivo de 4.3 MB a 495 KB. Eso es una reducción del 89% antes de aplicar cualquier compresión. Antes de tocar un control deslizante de calidad. Antes de cambiar el formato. Solo al hacer coincidir las dimensiones de la imagen con el contenedor en el que realmente se mostrará.

Ahora aplica compresión sobre esa imagen correctamente dimensionada: un JPEG a calidad 75 la lleva a alrededor de 161 KB. El ahorro acumulado de dimensionar correctamente y luego comprimir es de aproximadamente 96% del tamaño de archivo original.

Esa es la magnitud del desperdicio que ocurre cada día en sitios donde las imágenes provienen directamente de herramientas de diseño o bibliotecas de stock sin ningún paso de redimensionamiento.

Lo que "Optimización" Realmente Abarca

La optimización de imágenes es un término paraguas que cubre varios problemas relacionados pero distintos. Tratarla como "solo compresión" es la razón por la que tantos sitios todavía tienen mal rendimiento de imágenes incluso después de que alguien ha "optimizado" oficialmente las imágenes.

Así es como se ve el panorama completo:

Dimensiones. ¿La imagen tiene la cantidad correcta de píxeles para el espacio que ocupa? Una imagen de barra lateral que se renderiza a 300px de ancho no debería servirse a 2,000px de ancho.

Dimensionamiento responsivo. Los distintos dispositivos tienen diferentes pantallas. Un usuario de escritorio y un usuario móvil que visitan la misma página deberían recibir imágenes dimensionadas para sus respectivos viewports, no el mismo archivo. Esto es lo que resuelven los atributos srcset y sizes de HTML.

Formato. ¿La imagen usa un formato moderno y eficiente? JPEG es universal pero ineficiente. WebP produce la misma calidad visual con archivos aproximadamente un 30% más pequeños. AVIF lleva eso a un 50% más pequeño. Elegir el formato correcto es la segunda palanca después de obtener las dimensiones correctas.

Compresión. Para formatos con pérdida, la configuración de calidad controla qué tan agresivamente el codificador descarta datos. Ajustar esto correctamente (ni muy alto, ni muy bajo) es la compresión en el sentido tradicional.

Estrategia de carga. ¿Cuándo se descarga la imagen? Las imágenes por debajo del pliegue no deberían bloquear la carga inicial de la página. El atributo loading="lazy" le indica al navegador que difiera esas descargas. La imagen hero, en cambio, debe tratarse como un recurso prioritario, no como algo a cargar de forma diferida.

Entrega. ¿De dónde vienen las imágenes y qué tan rápido responde el CDN que las sirve? Esto está fuera del alcance de esta serie, pero incluso las imágenes perfectamente optimizadas pueden ser lentas si se sirven desde un origen lejano sin caché.

Esta serie aborda todo lo anterior excepto la entrega, construyendo desde los fundamentos de la elección de formato hasta un pipeline completo de optimización del lado del cliente en Svelte 5.

Por Qué Sigue Ocurriendo Esto

Si las imágenes sobredimensionadas son un problema tan común y costoso, ¿por qué persisten? La respuesta es principalmente la fricción, no la ignorancia.

Un diseñador exporta una imagen hero desde Figma a 2x para pantallas retina y se la envía al desarrollador. Se ve genial. El desarrollador la coloca en static/. Sigue viéndose genial en desarrollo. Nadie la señala durante la revisión. Se publica.

Un editor de contenido sube una fotografía para una publicación de blog. El CMS la acepta y la almacena. Nadie ha configurado el redimensionamiento automático. El original de 5MB completo se sirve a cada visitante.

Un desarrollador agrega una nueva sección a una página de marketing, copia una URL de imagen de la biblioteca de activos de la marca y la pega en una etiqueta <img>. La imagen de la biblioteca tiene 4,000 píxeles de ancho. La sección tiene 800 píxeles de ancho. Nadie verificó.

Ninguna de estas personas fue descuidada. Estaban haciendo su trabajo correctamente dentro del sistema que tenían. El problema es que el estado predeterminado de la mayoría de los flujos de trabajo de publicación web es servir la imagen que el creador subió, con las dimensiones en que fue creada, a cada dispositivo que visita la página.

La optimización requiere una intervención deliberada. Sin una herramienta, un proceso o un framework que haga que lo correcto sea el valor predeterminado, lo incorrecto ocurre automáticamente.

Abre DevTools en cualquier página web y ejecuta una auditoría de Lighthouse (DevTools → Lighthouse → Performance). Busca dos entradas específicas en la sección Opportunities: "Properly size images" y "Serve images in next-gen formats". Estas dos auditorías por sí solas revelan la mayor parte del desperdicio de imágenes en un sitio típico. Lighthouse muestra los ahorros estimados en kilobytes y tiempo de carga para cada imagen que señala, haciendo que el problema sea imposible de ignorar.

La Brecha Móvil Hace Esto Urgente

Todo lo anterior es más grave en móviles, y los móviles son de donde proviene la mayoría del tráfico web.

Una imagen hero de 2,400px mostrada en un viewport móvil de 390px está transmitiendo más de 37 veces más píxeles de los que el navegador renderizará. Todos esos bytes adicionales se descargan a través de una conexión móvil, son decodificados por una CPU más débil y luego descartados. La batería, el plan de datos y el tiempo del usuario se gastan en píxeles que nunca fueron visibles.

Google ha utilizado indexación mobile-first desde 2019, lo que significa que la versión móvil de tu página determina tu posicionamiento en los resultados de búsqueda. Los problemas de rendimiento de imágenes que solo aparecen en móviles (puntuaciones fallidas de Largest Contentful Paint, first contentful paint lento, alto cumulative layout shift) afectan directamente dónde aparece tu página en los resultados de búsqueda, no solo qué tan rápido carga.

La implicación práctica es que el dimensionamiento de imágenes debe resolverse por breakpoint, no eligiendo una resolución "media" y esperando lo mejor. Una imagen correctamente dimensionada para un hero de escritorio y una imagen correctamente dimensionada para un hero móvil son archivos diferentes. Servir ambas correctamente es exactamente para lo que existen srcset y el elemento <picture>.

Hacia Dónde Apunta Esta Serie

Las primeras lecciones tratan sobre los fundamentos: entender los formatos (Lección 1), entender las herramientas (Lección 2) y construir un primer compresor funcional (Lección 3). Los problemas de dimensionamiento y dimensionamiento responsivo se abordan directamente en las Lecciones 7 y 8, donde construirás los componentes ResponsiveImage y LazyImage que manejan el dimensionamiento correcto en todos los breakpoints.

Al final de la serie, tendrás:

Un modelo mental para saber qué formato usar y por qué, para cada tipo de imagen
Un pipeline de compresión del lado del cliente que procesa imágenes en el navegador sin costo de servidor
Componentes que sirven imágenes correctamente dimensionadas a cada dispositivo usando srcset, sizes y el elemento <picture>
Una estrategia de carga que prioriza las imágenes sobre el pliegue y difiere todo lo demás
Auditorías de Lighthouse aprobadas para las oportunidades relacionadas con imágenes

El objetivo no es hacer que el manejo de imágenes se sienta complicado. Es hacer que las elecciones correctas sean las automáticas, para que el estado predeterminado de tu aplicación SvelteKit sea "las imágenes se manejan correctamente" en lugar de "las imágenes son lo que sea que el editor de contenido subió el martes pasado."

Puntos Clave

Las imágenes representan más de 1 MB de los 2.9 MB del peso mediano de una página de escritorio en 2025; son el tipo de recurso más pesado en bytes, más pesado que JavaScript.
Las imágenes sobredimensionadas (dimensiones incorrectas para su contenedor) son a menudo un problema mayor que las imágenes sin comprimir. Redimensionar una foto DSLR de 4.3 MB a sus dimensiones de visualización reales reduce el tamaño del archivo en un 89% antes de aplicar cualquier compresión.
La optimización de imágenes abarca seis problemas distintos: dimensiones, dimensionamiento responsivo, elección de formato, compresión, estrategia de carga y entrega. Tratarla como "solo compresión" omite las intervenciones más impactantes.
La brecha móvil hace esto urgente: una imagen hero de 2,400px en una pantalla móvil de 390px transmite 37 veces más píxeles de los que el navegador renderizará, y la indexación mobile-first de Google significa que esto afecta directamente el posicionamiento en los resultados de búsqueda.

Lecturas Adicionales

HTTP Archive 2025 Web Almanac: Page Weight - datos fuente para las estadísticas de peso de página en este artículo
HTTP Archive 2024 Web Almanac: Media - desglose detallado del uso de formatos de imagen, bits por píxel y tendencias de compresión
web.dev: Image Performance - la guía autorizada de Google que cubre srcset, sizes, carga diferida y sugerencias de prioridad
MDN: Responsive Images - la referencia completa para srcset, sizes y el elemento picture

Ver También

Lección 2: La Base de Formatos - la siguiente lección, que cubre cuándo elegir JPEG, PNG, WebP, AVIF o SVG.
Lección 8: Deja de Enviar Imágenes de 4000px a un Teléfono de 400px - la mitad de entrega responsiva del problema de peso de página que esta lección identifica.
Lección 15: La Prueba de Trabajo - Auditorías de Lighthouse - la auditoría al final del recorrido que demuestra que los números de peso de página realmente mejoran.

Lo Más Pesado en Tu Página Probablemente es una Imagen