Una imagen puede hacer que una página se entienda más rápido o puede ser el recurso que más tarda en llegar, desplaza el contenido y no aporta nada a quien no la ve. Por eso no la dejo para el final, como si fuera un detalle de decoración que se resuelve al exportar un JPG.
En este portfolio las capturas de los proyectos existen en varios anchos. La de Apuntes ICO, por ejemplo, parte de una imagen de casi 2.000 píxeles de ancho, pero una tarjeta no descarga siempre esa versión. El componente entrega variantes de 640, 768, 960 y 1280 píxeles con srcset y le dice al navegador, mediante sizes, cuánto espacio ocupará realmente. Fue una decisión de frontend, no una mejora cosmética hecha después de medir una puntuación.
No hay un formato ni un tamaño que sirva para todas las imágenes. Lo que sí hay es un orden para decidirlo antes de publicar.
Empiezo por el trabajo que hace la imagen
Antes de abrir una herramienta de compresión, intento responder una pregunta simple. ¿Qué se perdería si esta imagen no cargara?
Una foto de un profesional puede aportar confianza en una página de servicios. Una captura puede enseñar una interfaz que sería lenta de explicar con texto. Una textura de fondo quizá no cambia nada si desaparece. Meter las tres en el mismo grupo lleva a aplicar mal el alt, la prioridad de descarga y el peso que merece cada una.
En las tarjetas de proyectos de esta web, la imagen está dentro de un enlace que se oculta a lectores de pantalla y el título del proyecto aparece justo después como enlace real. La miniatura es una vista previa visual, no el único modo de descubrir el proyecto. Por eso lleva alt="". Repetir “imagen de Apuntes ICO” antes de que se lea el título no añadiría información; añadiría ruido.
Eso no sirve como regla para todas las capturas. En la página individual del proyecto, la imagen grande sí forma parte de la explicación. Ahora mismo el alt se construye como “Captura: [título]”. Es válido como punto de partida, pero no explica qué permite ver la captura. Si la interfaz muestra un buscador por módulos o una pantalla sin conexión, un texto alternativo más concreto aportaría más. Es el tipo de detalle que revisaría al documentar mejor cada caso de estudio.
El peso se decide antes de exportar
Una imagen enorme no se arregla por completo al convertirla a WebP. Si la foto tiene un encuadre innecesario, demasiada resolución para el lugar donde aparecerá o texto pequeño que nadie puede leer en móvil, el problema viene de antes.
Primero miro el hueco que va a ocupar. Una miniatura de dos columnas no necesita la misma fuente que una portada que llena casi todo el ancho de una pantalla grande. En este proyecto, las tarjetas indican al navegador un ancho aproximado con esta regla:
sizes="(min-width: 1200px) 552px,
(min-width: 768px) calc(50vw - 2.75rem),
calc(100vw - 2.5rem)"La cifra no es decorativa. Permite que el navegador elija una variante razonable de srcset en vez de descargar la mayor por si acaso. Si sizes dice que la imagen ocupa toda la pantalla cuando en realidad ocupa media columna, la optimización se queda a medias.
También compruebo qué pasa en móvil. Una captura de escritorio muy ancha puede ser relevante en un caso de estudio y, aun así, resultar ilegible en una tarjeta. A veces hay que cambiar el recorte, no reducir el mismo archivo hasta que sea diminuto. Es una decisión de contenido y diseño antes que una decisión de formato.
WebP y AVIF no sustituyen al criterio
Para las capturas del portfolio uso WebP porque funciona bien para este tipo de imágenes y me permite mantener los archivos estáticos sencillos. No lo trataría como una norma universal.
AVIF puede reducir más el peso en algunos casos, sobre todo en imágenes fotográficas, pero conviene comprobar cómo queda la calidad y qué soporte necesita el público real. SVG es mejor para un logotipo o un icono vectorial que no debería rasterizarse. PNG sigue teniendo sentido cuando hace falta transparencia o una imagen sin pérdidas, aunque no lo usaría automáticamente para una foto. JPEG puede ser una salida práctica cuando necesitas compatibilidad amplia y la cadena de publicación ya está preparada para ello.
Elegir formato no consiste en memorizar una tabla. Consiste en mirar la imagen al tamaño en el que se verá. Una compresión agresiva puede dejar texto borroso dentro de una captura. Una conversión de un icono a WebP puede hacerlo más pesado que el SVG original. Una foto servida en PNG puede pagar bytes que nadie va a percibir.
Cuando necesito atender formatos distintos, usaría <picture> con una alternativa y un img final. Pero no añadiría esa capa a cada imagen solo porque parezca más avanzada. Si el sistema actual ya genera variantes WebP pequeñas y la prueba en dispositivos reales es buena, hay otras mejoras que pueden tener más impacto.
Reservar espacio evita que la página salte
La carga de una imagen no es solo una cuestión de tiempo. Si el navegador no sabe cuánto va a ocupar, puede pintar texto y botones y moverlos cuando la imagen termina de descargar. Es una experiencia incómoda, especialmente cuando alguien estaba a punto de pulsar algo.
Por eso las imágenes del sistema de proyectos llevan width y height basados en sus dimensiones reales. Aunque después CSS las haga fluidas, esos atributos dan al navegador la proporción necesaria para reservar espacio. La guía de web.dev sobre CLS señala las imágenes sin dimensiones como una causa habitual de desplazamientos de diseño y recomienda declarar las dimensiones o reservar el espacio con aspect-ratio.
No copiaría dimensiones a ojo. Si el archivo es 1911 por 1032, esos son los valores que deberían acompañar a sus variantes del mismo recorte. Si en móvil se utiliza otra imagen con una proporción distinta, hay que tratarlo como otro recurso y reservar su espacio también.
loading="lazy" no va en la imagen más importante
La carga diferida es útil para imágenes que están más abajo y que una persona quizá nunca llegue a ver. En las tarjetas del portfolio la uso porque muchas miniaturas aparecen fuera de la primera vista. Ahí retrasar la descarga evita pedirlas todas de golpe.
No haría lo mismo con la imagen principal de una página de proyecto. Esa portada se carga con loading="eager" y fetchpriority="high", porque forma parte de lo primero que se ve. Marcarla como diferida puede retrasar justo el recurso que define cuándo parece cargada la página.
La frontera no es “todo lo que esté arriba” ni “todo lo que tenga buena pinta”. Hay que abrir la página en móvil y escritorio, ver cuál es el elemento visual importante y comprobar en las herramientas del navegador cuándo se solicita. Una imagen que queda oculta tras una cabecera enorme no tiene por qué ser prioritaria solo porque esté escrita antes en el HTML.
El alt explica una función, no una keyword
El texto alternativo suele entrar en conversaciones de SEO demasiado pronto. Antes de pensar en búsquedas, debe servir a una persona que no puede ver la imagen o que ha decidido no cargarla.
Un buen alt cambia según el contexto. Si una infografía contiene un dato que el párrafo no incluye, ese dato necesita aparecer en texto cerca de la imagen o en la propia alternativa. Si una foto acompaña una historia y no añade información necesaria, basta con una descripción breve. Si la imagen es decorativa, alt="" permite que un lector de pantalla la ignore.
La referencia de MDN para el elemento img deja claro que alt es un reemplazo textual cuando la imagen no puede mostrarse. Por eso frases como “imagen de”, nombres de archivo o una lista de keywords no resuelven el problema. Tampoco una descripción interminable de cada píxel.
En un caso de estudio preferiría algo como “Buscador de Apuntes ICO con resultados agrupados por módulo” a “captura de Apuntes ICO”. Explica qué se está demostrando y encaja con el texto que rodea a la imagen. En una tarjeta donde el nombre, el resumen y el enlace ya hacen ese trabajo, volvería al alt="".
SEO necesita contexto, no relleno
Google puede encontrar imágenes por muchas señales, pero no convertiría el alt en un campo de palabras clave. El nombre del archivo, el texto cercano, un figcaption cuando aporta contexto, la página donde aparece la imagen y la calidad del recurso cuentan más como conjunto que una frase forzada.
Para una imagen de proyecto, me interesa que la URL y el contenido expliquen cuál es el proyecto, qué problema resolvía y qué muestra esa pantalla. Eso es más coherente que intentar posicionar una captura aislada con diez términos añadidos a su atributo.
También separaría la imagen que usa una red social al compartir una URL de las imágenes que aparecen en el artículo. La primera necesita el tamaño y el recorte adecuados para una tarjeta social. La segunda debe responder al ritmo de lectura y al ancho del contenido. Reutilizar el mismo archivo para todo puede ser cómodo, pero no siempre es la mejor decisión.
La revisión termina en producción
Antes de dar por buena una imagen, abriría la página publicada con una conexión móvil simulada y revisaría la pestaña Network. Miraría qué archivo ha elegido el navegador, cuánto pesa, si se está descargando una variante mayor de la necesaria y si hay saltos al cargar.
Después probaría la página sin imágenes o con un lector de pantalla. No para hacerme pasar por especialista, sino para comprobar que el contenido conserva su sentido. Si al quitar una imagen desaparece la única explicación de una interfaz, el texto tiene que asumir esa información. Si se anuncia una miniatura decorativa tres veces, hay que quitarle el ruido.
El objetivo no es conseguir una galería perfecta ni reducir todos los archivos al mínimo posible. Es servir cada imagen con un motivo. Esa forma de revisar conecta rendimiento, accesibilidad y SEO con una decisión visible que afecta a cada visita. En mi revisión antes de publicar una web explico otras comprobaciones que hago cuando el proyecto deja de estar solo en local.