Las imágenes suelen representar una parte importante de los bytes descargados por una página web. También pueden influir directamente en la velocidad percibida, el Largest Contentful Paint (LCP), la estabilidad visual y el consumo de datos.
Sin embargo, «optimizar una imagen» no significa simplemente bajar un control de calidad hasta que el archivo pese menos. Una estrategia sólida combina varias decisiones: qué dimensiones necesita realmente la imagen, qué formato conviene, cuánto se puede comprimir, qué variantes responsive deben existir y cuándo debe cargarse cada recurso.
La optimización eficaz es un proceso. El objetivo es entregar la cantidad de información visual necesaria para el contexto real, con la menor transferencia y el menor coste de procesamiento razonables.
No existe un botón mágico de «optimizar»
Una imagen puede estar mal optimizada por razones muy distintas.
Dimensiones excesivas
Una fotografía de 4000 píxeles puede terminar mostrándose a 600 píxeles de ancho.
Aunque esté bien comprimida, el navegador sigue descargando y decodificando muchos píxeles que no necesita.
Formato inadecuado
Una captura con grandes zonas planas puede funcionar mejor en PNG o WebP que en JPEG. Una fotografía puede beneficiarse de JPEG, WebP o AVIF según el contexto.
El formato no debe elegirse únicamente por costumbre.
Compresión insuficiente
Una exportación con calidad extremadamente alta puede conservar diferencias que el usuario no percibe en el tamaño de visualización final.
Ausencia de variantes responsive
Enviar el mismo archivo a un teléfono estrecho y a un monitor de alta densidad desperdicia datos o compromete la nitidez.
Prioridad de carga incorrecta
Una imagen hero que constituye el LCP no debería esperar detrás de recursos secundarios. Una galería situada muy por debajo del primer viewport no necesita descargarse inmediatamente.
Layout inestable
Si el navegador desconoce las dimensiones de una imagen antes de recibirla, el contenido puede desplazarse durante la carga.
Por tanto, el rendimiento no depende únicamente del peso del archivo.
El pipeline global
Un flujo fiable puede resumirse así:
comprender el papel de la imagen;
inspeccionar el original;
determinar las dimensiones de visualización;
elegir el formato;
generar variantes;
comprimir;
definir la entrega responsive;
establecer la prioridad de carga;
declarar dimensiones;
medir el resultado en la página.
Cada etapa resuelve un problema diferente.
Paso 1 — Comprender el papel de la imagen
Antes de transformar un archivo, identifica su función.
Puede ser:
una hero crítica;
una fotografía de contenido;
una miniatura;
una captura de pantalla;
un logo;
un icono;
una ilustración;
una imagen decorativa.
Una hero visible inmediatamente no se optimiza exactamente igual que una miniatura situada al final de una página.
Paso 2 — Comprender el archivo de origen
Comprueba:
dimensiones en píxeles;
relación de aspecto;
formato;
transparencia;
calidad visual;
presencia de texto fino;
metadatos;
tamaño del archivo.
No empieces desde una copia ya degradada si dispones de un master mejor.
Paso 3 — Determinar las dimensiones realmente necesarias
Esta suele ser una de las decisiones con mayor impacto.
Si una imagen nunca se muestra por encima de 720 píxeles CSS, un original público de 4000 píxeles puede ser innecesario.
En pantallas de alta densidad puede ser útil disponer de una variante mayor que el tamaño CSS, pero eso no significa enviar sistemáticamente la resolución máxima.
No redimensiones desde una versión ya reducida
Genera las variantes desde el original o desde un master de suficiente resolución.
Ampliar una imagen pequeña no recupera detalle.
Conserva la relación de aspecto
Salvo que quieras recortar deliberadamente, conserva las proporciones para evitar deformaciones.
No utilices prioridad alta para muchas imágenes a la vez.
Preload de imágenes
El preload puede ser útil en casos concretos, pero no debería convertirse en una solución automática.
Precargar un recurso que el navegador no necesitaba puede competir con CSS, fuentes y otros recursos críticos.
Antes de añadir un preload, comprueba que existe realmente un problema de descubrimiento.
No hagas lazy loading del LCP
Es uno de los errores más comunes.
El lazy loading indica que el navegador puede retrasar una imagen. Si esa imagen es precisamente el contenido principal visible, estás retrasando el recurso que quieres mostrar cuanto antes.
decoding="async"
El atributo decoding proporciona una indicación sobre cómo gestionar la decodificación.
Puede ser útil, pero no compensa una imagen sobredimensionada.
Trátalo como un ajuste secundario, no como la base de la optimización.
El coste de decodificación
El tamaño transferido no es el único coste.
Una imagen comprimida de pocos cientos de kilobytes puede expandirse en memoria a varios megabytes una vez decodificada.
El número de píxeles sigue importando incluso cuando el archivo parece pequeño en Network.
Ejemplo de memoria raster
Una imagen RGBA de 4000 × 3000 contiene 12 millones de píxeles.
Aproximadamente cuatro bytes por píxel representan cerca de 48 MB de datos raster sin comprimir.
Esto ilustra por qué reducir dimensiones puede mejorar más cosas que la transferencia.
Optimización de fotografías
Para fotografías:
elimina dimensiones innecesarias;
prueba JPEG, WebP y AVIF según tu pipeline;
ajusta la calidad visualmente;
genera variantes responsive;
revisa el LCP si la foto es prominente.
No persigas el archivo mínimo si aparecen artefactos visibles.
Optimización de capturas de pantalla
Las capturas contienen texto y bordes finos.
Una compresión con pérdida demasiado agresiva puede crear halos y hacer que la interfaz parezca borrosa.
Prueba formatos y niveles diferentes a los utilizados para fotografías.
Optimización de logos
Si el logo es vectorial, SVG suele ser una opción natural.
Si necesitas raster, evita dimensiones enormes y conserva transparencia cuando sea necesaria.
Un logo pequeño no debería pesar cientos de kilobytes.
Optimización de iconos
Para iconos simples, considera SVG o sistemas de iconos adecuados.
No utilices una fotografía raster enorme para representar un pictograma de 24 píxeles.
Imágenes decorativas
Pregúntate si la imagen necesita existir.
Eliminar un recurso puramente decorativo puede ser la optimización más eficaz posible.
Si se mantiene, no debería competir innecesariamente con el contenido crítico.
Background images CSS
Las imágenes de fondo pueden ser apropiadas para decoración, pero requieren atención si contienen contenido importante.
Una imagen de contenido suele pertenecer a HTML, donde puede tener texto alternativo y participar más claramente en la semántica.
Además, el descubrimiento de una imagen CSS depende de la hoja de estilos y de la regla que la utiliza.
Imágenes en carruseles
No descargues automáticamente todas las imágenes de un carrusel si el usuario solo ve la primera.
La estrategia depende del componente, pero las diapositivas lejanas pueden cargarse más tarde.
Mantén, sin embargo, la primera imagen disponible rápidamente si forma parte del contenido principal.
Galerías
Las galerías son candidatas naturales para:
miniaturas correctamente dimensionadas;
lazy loading;
variantes responsive;
carga de la imagen grande únicamente cuando el usuario la necesita.
Evita utilizar el archivo de la lightbox como miniatura.
Miniaturas
Una miniatura de 200 píxeles no necesita un archivo de 2000 píxeles.
Generar una variante dedicada reduce transferencia y decodificación.
Imágenes de productos
La imagen principal puede necesitar alta calidad y prioridad.
Las vistas secundarias pueden cargarse más tarde.
Para zoom, separa la necesidad de una imagen grande de la necesidad de cargarla inmediatamente.
Imágenes de artículos
En un artículo, la columna de contenido suele limitar la anchura máxima.
Aprovecha ese límite para no enviar archivos gigantes en escritorio.
Hero a pantalla completa
Una hero full width necesita una escala de candidatos más amplia que una imagen limitada a 700 píxeles.
También es más probable que afecte al LCP.
Mídela especialmente bien.
Formato y compatibilidad
La compatibilidad de los formatos modernos evoluciona.
Define qué navegadores soporta tu proyecto y evita mantener fallbacks que ya no aportan valor, pero no elimines compatibilidad necesaria sin medir tu audiencia.
<picture> para formatos alternativos
Puedes utilizar <picture> para ofrecer varias familias de formato:
Si también necesitas varias anchuras, cada <source> puede disponer de su propio srcset.
No multipliques formatos sin medir
Generar AVIF, WebP y JPEG en seis anchuras puede producir 18 archivos por imagen.
La automatización lo hace posible, pero no significa que sea necesario.
Evalúa el beneficio real frente a la complejidad de almacenamiento, build y caché.
Calidad perceptual
La calidad técnica no se reduce a un número de calidad del codificador.
Una pequeña pérdida de textura en un fondo puede ser invisible, mientras que la misma compresión aplicada a texto o líneas finas puede resultar evidente.
Evalúa el contenido real.
Comparar al tamaño de uso
No juzgues únicamente ampliando la imagen al 400 %.
La pregunta importante es cómo se percibe en el tamaño al que el usuario la verá.
También revisa pantallas de alta densidad cuando sean relevantes.
Evita recomprimir repetidamente
Cada ciclo con pérdida puede acumular degradación.
Conserva un master y genera los derivados desde él.
No utilices como nueva fuente una copia JPEG ya comprimida si puedes evitarlo.
Metadatos
Los archivos originales pueden contener EXIF, GPS, XMP u otros datos.
Una copia pública puede necesitar una política de metadatos diferente.
Eliminar metadatos puede ahorrar algunos bytes, pero su razón principal puede ser la privacidad.
Redimensionar y comprimir suelen tener un impacto mucho mayor sobre el rendimiento.
No confundas ambos objetivos.
CDN de imágenes
Una CDN de imágenes puede generar transformaciones bajo demanda:
anchura;
altura;
formato;
calidad;
recorte.
Esto facilita la entrega responsive, pero introduce una dependencia de infraestructura y una estrategia de caché que también deben gestionarse.
Generación durante el build
Los sitios estáticos pueden generar variantes al compilar.
Ventajas:
archivos previsibles;
sin transformación en tiempo de petición;
control del resultado.
Inconvenientes:
builds más largos;
más archivos;
almacenamiento adicional.
Transformación bajo demanda
La generación dinámica evita producir de antemano todas las combinaciones.
Sin embargo, necesitas controlar:
caché;
límites de transformación;
costes;
seguridad de parámetros;
comportamiento ante fallos.
Nombres y caché
Los archivos con hash de contenido permiten políticas de caché muy largas porque un cambio produce una nueva URL.
Si utilizas nombres estables sin versionado, debes definir cómo invalidar la caché cuando cambie el contenido.
Caché del navegador
Una buena caché evita volver a transferir imágenes que no han cambiado.
La optimización de un archivo individual y la estrategia HTTP se complementan.
CDN y proximidad
Servir imágenes desde una red distribuida puede reducir la latencia para usuarios alejados del origen.
Pero una CDN no arregla un archivo de 4 MB que debería pesar 100 KB.
Optimiza primero el recurso.
HTTP/2 y HTTP/3 no eliminan el coste de los bytes
Los protocolos modernos mejoran el transporte, pero los datos siguen necesitando descargarse y procesarse.
No utilices mejoras de protocolo como excusa para enviar imágenes innecesariamente grandes.
Core Web Vitals
Las imágenes pueden afectar principalmente a:
LCP, si una imagen grande es el contenido principal;
CLS, si no se reserva su espacio;
indirectamente INP, si el procesamiento y la carga compiten con otros trabajos.
La optimización debe observarse dentro del comportamiento completo de la página.
CLS y dimensiones
Declarar width y height permite establecer una relación de aspecto antes de la descarga.
Esto evita que el contenido inferior salte cuando llega la imagen.
No necesitas fijar el tamaño visual: CSS puede seguir controlándolo.
LCP y descubrimiento
Una imagen crítica incluida directamente en el HTML suele poder descubrirse antes que una imagen insertada tarde mediante JavaScript o escondida en CSS.
Si el LCP empieza a descargarse tarde, investiga primero el camino de descubrimiento.
LCP y TTFB
No todo problema de LCP es culpa de la imagen.
Un servidor lento, HTML tardío o CSS bloqueante pueden retrasar el momento en que el navegador encuentra el recurso.
Analiza las fases de la métrica antes de aplicar cambios aleatorios.
Presupuesto de rendimiento
Un proyecto puede establecer límites, por ejemplo:
peso máximo para una hero;
anchura máxima de masters públicos;
formatos autorizados;
número de variantes;
tamaño máximo de miniaturas.
Los presupuestos convierten la optimización en una regla del sistema en lugar de una tarea manual ocasional.
Automatizar controles
Un pipeline puede fallar si:
una imagen supera ciertas dimensiones;
un archivo público pesa demasiado;
faltan variantes esperadas;
una hero no tiene dimensiones;
aparece un formato prohibido.
Los límites deben adaptarse al proyecto, no copiarse de forma universal.
Auditorías automáticas
Herramientas de auditoría pueden señalar imágenes sobredimensionadas o problemas de carga.
Utilízalas como indicadores, no como sustituto de la inspección.
Una recomendación automática puede no comprender la función editorial de una imagen.
DevTools Network
El panel Network permite comprobar:
URL;
formato;
peso transferido;
tamaño del recurso;
prioridad;
momento de inicio;
caché.
Filtra por imágenes y compara diferentes viewports.
currentSrc
Para imágenes responsive, img.currentSrc muestra el candidato que el navegador ha seleccionado.
Es una herramienta esencial para verificar srcset y sizes.
Performance panel
Una traza de rendimiento ayuda a entender cuándo se solicita y decodifica una imagen en relación con el resto de la página.
Es especialmente útil para investigar LCP.
Lighthouse
Lighthouse puede ofrecer pistas sobre imágenes y Core Web Vitals.
Sus resultados de laboratorio son útiles para reproducibilidad, pero deben complementarse con datos reales cuando estén disponibles.
Datos de campo
Los datos reales reflejan dispositivos, redes y comportamientos que un único test de laboratorio no puede cubrir.
Si tienes suficiente tráfico, observa la evolución de las métricas después de los cambios.
No optimices únicamente para una puntuación
Una página puede obtener una puntuación mejor a costa de imágenes visiblemente degradadas.
El objetivo es una experiencia rápida y adecuada al contenido.
Encontrar el equilibrio
Una buena optimización busca el punto en el que reducir más el archivo produce una degradación perceptible que ya no compensa el ahorro.
Ese punto depende de:
tipo de imagen;
tamaño de visualización;
densidad;
importancia editorial;
condiciones de red.
Caso práctico: fotografía de 6000 × 4000
Supongamos una fotografía original de 6000 × 4000 que se muestra como máximo a 1200 píxeles CSS.
Un flujo razonable puede:
conservar el original como master;
generar 480, 800, 1200, 1600 y quizá 2400 px según DPR;
comparar WebP, AVIF y/o JPEG;
elegir una calidad visual aceptable;
escribir srcset y sizes;
comprobar qué variante se descarga en varios dispositivos.
Enviar 6000 píxeles a todo el mundo no aporta automáticamente más calidad visible.
Caso práctico: captura de interfaz
Una captura de 1600 × 900 que se muestra a 800 × 450 puede reducirse.
Como contiene texto, revisa especialmente los artefactos.
En algunos casos, una compresión sin pérdida o una calidad más alta será preferible a una fotografía equivalente.
Caso práctico: icono
Un icono simple debería evaluarse como vector.
Si SVG es apropiado, puedes evitar generar múltiples resoluciones raster.
Caso práctico: avatar
Un avatar de 64 píxeles puede utilizar recursos 1x y 2x.
No necesita una fotografía de varios megapíxeles en cada tarjeta.
Caso práctico: galería
Genera miniaturas para la vista general.
Carga la imagen grande cuando el usuario abre la vista ampliada.
Las miniaturas pueden utilizar lazy loading si están fuera del viewport.
Caso práctico: portada de artículo
Si la portada es el LCP:
no la cargues de forma diferida;
asegúrate de que el HTML la descubre pronto;
declara dimensiones;
ofrece una variante apropiada para móvil;
comprueba el peso transferido.
Cuándo usar lazy loading
Utilízalo cuando retrasar la imagen no perjudique el contenido inicial.
Buenos candidatos:
imágenes muy por debajo del primer viewport;
galerías largas;
contenido secundario.
Mal candidato:
la principal imagen visible al abrir la página.
Distancia al viewport
El comportamiento exacto del lazy loading nativo depende del navegador.
No asumas que la descarga empieza únicamente cuando el elemento toca el viewport.
El navegador puede anticiparla.
Lazy loading y SEO
Las implementaciones modernas basadas en HTML nativo suelen ser más robustas que soluciones antiguas que ocultaban completamente las URLs en atributos personalizados.
Aun así, asegúrate de que el contenido importante se representa mediante marcado accesible y rastreable.
alt no es una optimización de rendimiento
El texto alternativo es una necesidad semántica y de accesibilidad.
No lo elimines para ahorrar bytes.
Para imágenes puramente decorativas, utiliza el tratamiento semántico adecuado en lugar de inventar descripciones.
Optimización y accesibilidad
Una imagen demasiado degradada puede hacer ilegible un gráfico o texto.
La optimización no debe impedir que el usuario acceda a la información.
Para contenido textual importante, considera si HTML real sería más apropiado que una imagen.
Texto dentro de imágenes
El texto rasterizado escala peor, es menos accesible y puede sufrir artefactos de compresión.
Siempre que sea posible, utiliza texto HTML.
Gráficos y diagramas
Si un gráfico puede expresarse como SVG accesible o HTML, puede ser más flexible.
Si se publica como raster, asegúrate de que las etiquetas sigan siendo legibles en móvil.
Modo oscuro
Una imagen con fondo blanco incrustado puede resultar visualmente incómoda en una interfaz oscura.
No es estrictamente un problema de peso, pero forma parte de la adecuación del recurso al contexto.
Dirección artística
A veces el mejor recurso móvil no es una versión más pequeña, sino un recorte diferente.
<picture> permite adaptar la composición.
No confundas dirección artística con simple cambio de resolución.
Evitar el exceso de variantes
Más variantes no siempre significan mejor rendimiento.
Cada archivo añade:
almacenamiento;
trabajo de build;
entradas de caché;
complejidad.
Añade una variante cuando cubra un intervalo útil.
Cómo elegir las anchuras
Observa los tamaños reales de tus componentes.
Si las imágenes se muestran normalmente a 320, 640 y 960 píxeles, genera candidatos alrededor de esos rangos y considera DPR.
No empieces desde una lista genérica de breakpoints CSS.
Diferencias de peso entre candidatos
Mide los archivos generados.
Si dos anchuras consecutivas tienen casi el mismo peso, una de ellas puede ser innecesaria.
Si existe un salto enorme, una variante intermedia puede ser útil.
Calidad por formato
No copies el mismo número de calidad entre JPEG, WebP y AVIF esperando resultados equivalentes.
Los codificadores utilizan escalas y modelos diferentes.
Calibra cada formato.
Presets
Los presets son útiles para automatizar, pero deben basarse en pruebas representativas.
Puedes tener perfiles diferentes para:
fotografía;
captura;
miniatura;
hero;
ilustración.
Imágenes ya optimizadas
Reprocesar un archivo que ya está bien optimizado puede ahorrar muy poco y degradarlo.
Mide antes de transformar.
Originales enormes de cámaras
No publiques directamente el original de cámara salvo que exista una razón específica.
Además del peso, puede contener metadatos sensibles.
Orientación
Al procesar fotografías, verifica que la orientación EXIF se normaliza correctamente antes de eliminar metadatos.
Una limpieza mal diseñada puede producir imágenes giradas.
Transparencia
No conviertas a JPEG una imagen que necesita transparencia sin decidir qué fondo debe sustituirla.
WebP, AVIF, PNG y SVG pueden cubrir diferentes necesidades de transparencia.
Animación
Los GIF animados pueden ser muy pesados.
Según el contenido, vídeo o formatos de imagen modernos pueden ofrecer alternativas más eficientes.
La elección depende de compatibilidad, accesibilidad y comportamiento deseado.
Video frente a GIF
Para animaciones largas o fotográficas, un formato de vídeo suele comprimir mucho mejor que GIF.
No reemplaces automáticamente cada GIF sin considerar controles, reproducción y semántica.
Sprites
Las antiguas técnicas de sprites reducían el número de peticiones en HTTP/1.
Con protocolos modernos y SVG, su ventaja es mucho menos universal.
No mantengas una arquitectura compleja únicamente por una optimización histórica.
Base64 e imágenes inline
Incrustar imágenes pequeñas en CSS o HTML elimina una petición, pero aumenta el documento y puede perjudicar la caché independiente.
Úsalo solo cuando exista una razón medida.
Data URLs para imágenes grandes
Generalmente son una mala idea.
Aumentan el tamaño textual y dificultan la caché separada.
Precarga indiscriminada
Precargar muchas imágenes puede empeorar el rendimiento al competir por ancho de banda.
Reserva el preload para recursos realmente críticos y difíciles de descubrir.
Service workers
Un service worker puede ayudar a cachear imágenes en aplicaciones que lo necesitan.
Pero añade complejidad y no reduce el peso inicial del archivo.
Optimización en el CMS
Un CMS puede generar automáticamente derivados cuando se sube una imagen.
Esto reduce errores editoriales si las reglas están bien definidas.
Mantén acceso al master cuando sea necesario.
Contenido generado por usuarios
No confíes en que los usuarios subirán archivos adecuados.
Valida dimensiones, formato, peso y metadatos.
Genera derivados controlados para la publicación.
Límites de subida
Los límites protegen infraestructura, pero no sustituyen la transformación.
Una foto de 8 MB puede ser válida como master de entrada y completamente inapropiada como recurso público.
Calidad de entrada
Si el original está borroso o fuertemente comprimido, ningún pipeline puede reconstruir perfectamente el detalle perdido.
La optimización no es restauración.
IA y ampliación
Las técnicas de superresolución pueden inventar detalle plausible, pero no recuperan necesariamente la información original.
No las confundas con un simple redimensionado para web.
SEO de imágenes
Un archivo optimizado puede mejorar la experiencia y el rendimiento, pero el SEO de imágenes también depende de:
contexto;
texto alternativo;
nombres y URLs razonables;
contenido de la página;
accesibilidad para rastreadores.
No sacrifiques semántica por unos bytes.
Nombres de archivo
Un nombre descriptivo puede facilitar la gestión y aportar contexto.
No es necesario introducir una lista artificial de palabras clave.
Mantén nombres estables y comprensibles.
Sitemap de imágenes
En determinados sitios, la información de imágenes en sitemaps puede ayudar al descubrimiento.
No es una necesidad universal para cada proyecto.
Open Graph y redes sociales
Las imágenes sociales tienen requisitos distintos de una hero de página.
Genera un recurso dedicado con dimensiones y composición apropiadas en lugar de reutilizar ciegamente una miniatura.
Imágenes para correo electrónico
Los clientes de correo tienen restricciones y comportamientos distintos de los navegadores web modernos.
No asumas que el pipeline de una web puede reutilizarse sin adaptación.
Pantallas Retina y marketing
«Retina» no significa que debas duplicar todas las dimensiones sin pensar.
Utiliza densidad y tamaño de visualización reales.
Para fotografías, una densidad algo inferior a la teórica puede seguir siendo visualmente excelente con un ahorro considerable.
Ahorro marginal
No inviertas horas en ahorrar 2 KB de una imagen secundaria mientras la hero sigue descargando 1,5 MB.
Prioriza por impacto.
Principio 80/20
Los mayores beneficios suelen proceder de:
eliminar imágenes innecesarias;
redimensionar originales enormes;
elegir formatos adecuados;
comprimir;
corregir la carga del LCP;
implementar variantes responsive.
Los microajustes vienen después.
Medir antes y después
Registra al menos:
peso total de imágenes;
peso de la imagen LCP;
candidato descargado;
momento de solicitud;
LCP;
CLS.
Así podrás saber si la optimización ha funcionado realmente.
Probar conexiones lentas
Una diferencia que parece pequeña en fibra puede ser importante en una conexión móvil limitada.
Utiliza throttling como herramienta de diagnóstico, sin confundir una simulación con datos reales.
Probar CPU limitada
La decodificación y el procesamiento pueden ser más visibles en dispositivos modestos.
No optimices únicamente en un ordenador de desarrollo potente.
Caché fría y caliente
Prueba ambos escenarios.
Una caché caliente puede ocultar un problema de peso que afecta a la primera visita.
Error frecuente: optimizar únicamente el peso
Un archivo ligero pero demasiado pequeño puede verse borroso.
Un archivo ligero cargado demasiado tarde puede seguir produciendo un LCP malo.
Un archivo ligero sin dimensiones puede provocar CLS.
El peso es solo una variable.
Error frecuente: calidad fija para todo
Las fotografías, capturas y gráficos responden de manera diferente a la compresión.
Utiliza perfiles adaptados.
Error frecuente: 100vw en todas partes
Si la imagen está limitada por un contenedor, sizes="100vw" puede provocar la descarga de candidatos excesivos.
Error frecuente: lazy loading universal
Aplicarlo a todas las imágenes, incluida la hero, puede retrasar el contenido principal.
Error frecuente: archivos originales como thumbnails
Genera miniaturas reales.
No dependas del CSS para reducir visualmente una imagen enorme.
Error frecuente: dimensiones ausentes
Reserva el espacio mediante dimensiones o una relación de aspecto conocida.
Error frecuente: demasiados formatos
No mantengas tres formatos y diez anchuras si la ganancia adicional es mínima.
Error frecuente: no verificar el resultado
Un pipeline automatizado puede contener errores.
Inspecciona muestras y añade pruebas.
Error frecuente: olvidar el original
Si sobrescribes el único master con una versión comprimida para web, pierdes flexibilidad para futuras variantes.
La herramienta no sustituye la decisión sobre el layout. Debes conocer las dimensiones reales que necesita el componente.
Lo que debes recordar
Optimizar imágenes para la web significa entregar el recurso adecuado, en el tamaño adecuado, en el formato adecuado y en el momento adecuado.
Empieza por las dimensiones, porque enviar píxeles que nunca se mostrarán suele ser un desperdicio fundamental. Después elige formato y compresión. Añade variantes responsive cuando el tamaño de visualización cambia. Reserva espacio para evitar CLS y trata la imagen LCP como un recurso crítico.
Finalmente, mide. Una imagen no está optimizada porque una herramienta diga «70 % de calidad» o porque utilice un formato moderno. Está optimizada cuando ofrece la calidad necesaria con un coste razonable en la página real.
Preguntas frecuentes
¿Cuál es el mejor formato de imagen para la web?
No existe uno universal. Depende del contenido, transparencia, compatibilidad y pipeline. WebP y AVIF son muy eficientes en muchos casos; JPEG, PNG y SVG siguen teniendo usos legítimos.
¿Qué calidad debo utilizar?
No existe un porcentaje universal. Compara visualmente varias exportaciones al tamaño de uso y mide su peso.
¿Debo convertir todas las imágenes a AVIF?
No. Evalúa el beneficio real, el coste de codificación, la compatibilidad y la complejidad del pipeline.
¿Lazy loading mejora todas las imágenes?
No. Es útil principalmente para recursos fuera de pantalla. Puede perjudicar a una imagen LCP.
¿Por qué declarar width y height si uso CSS responsive?
Porque ayudan al navegador a reservar la relación de aspecto antes de que llegue el archivo, mientras CSS sigue controlando el tamaño visual.
¿Cuántas variantes responsive necesito?
Las suficientes para cubrir tamaños de visualización útiles sin crear una explosión de archivos. No existe un número fijo.
¿Una CDN de imágenes optimiza automáticamente todo?
Puede automatizar transformaciones y entrega, pero necesitas definir dimensiones, formatos, calidad, caché y política de metadatos.
¿Eliminar metadatos mejora mucho el rendimiento?
Normalmente el ahorro es secundario frente a redimensionado y compresión. Puede ser mucho más importante por privacidad.
¿Cómo sé si una imagen está sobredimensionada?
Compara sus dimensiones intrínsecas con el tamaño renderizado y el DPR, y revisa qué candidato descarga realmente el navegador.
¿Qué debo optimizar primero?
Prioriza las imágenes grandes y visibles, especialmente el LCP. Después aborda galerías, miniaturas y recursos secundarios según su impacto.
Entiende srcset, sizes, los descriptores de anchura y densidad, picture, la dirección artística y cómo el navegador elige la imagen responsive adecuada.
Comprende rastreo, indexación, canonical, metadatos, datos estructurados, rendimiento y enlazado interno sin confundir optimización con posicionamiento.
