Independientemente de qué tan avanzado estés aprendiendo a diseñar y desarrollar para la Web, el elemento <img> necesita muy poca introducción.
Lanzada en Netscape ("Mosaic", en ese momento) en 1993 y agregada a la especificación HTML en 1995, <img> ha desempeñado durante mucho tiempo una función simple, pero poderosa dentro de la plataforma web. El desarrollador agrega un archivo de imagen de "fuente" con el atributo src y proporciona una alternativa de texto con el atributo alt en caso de que la imagen no se pueda renderizar o de que las tecnologías de asistencia soliciten una alternativa. A partir de ahí, el navegador solo tendrá un trabajo: obtener los datos de la imagen y renderizarlos lo más rápido posible.
Para la mayor parte del historial del desarrollo web, trabajar con imágenes no fue mucho más complicado que eso. Y, a pesar de la complejidad de la Web moderna, los aspectos básicos de trabajar con imágenes no cambiaron: usa un formato de imagen compatible con la Web para la compatibilidad, una compresión sensible para conservar el ancho de banda y dimensiones que se adapten al espacio que ocupará la imagen en el diseño de la página.
El uso de diseños de ancho fijo, como lo hicimos cuando pensábamos que teníamos más influencia sobre la forma en que los usuarios experimentaban la Web, hizo de este proceso un proceso sin complicaciones. Fue particularmente fácil establecer el tamaño de la fuente de la imagen. Para una imagen que ocupó un espacio de 500 píxeles de ancho y 300 píxeles de alto, fue el caso de especificar una imagen de origen de ese mismo tamaño.
Imágenes en un diseño responsivo
Junto con el diseño flexible y el uso de las consultas de medios CSS, "imágenes y medios flexibles" son una de las tres facetas que definen el diseño web responsivo. Con el fin de hacer que una imagen sea flexible, los desarrolladores comenzaron a usar CSS para establecer max-width: 100% en la imagen (o todas las imágenes, en todo el sitio) para indicarle al motor de renderización del navegador que evite que una imagen desborde su contenedor superior reduciendo su escala. Desde el punto de vista visual, esto funciona perfectamente: reducir la escala de una imagen de trama es visualmente perfecta. Con una o dos líneas de CSS, una imagen reducida siempre se verá como si hubiese especificado una fuente de imagen que se debía mostrar en ese tamaño.
Cuando los motores de renderización reciben más datos de imagen de los necesarios para el espacio que ocupa la imagen en un diseño, pueden tomar decisiones fundamentadas sobre cómo renderizar la imagen reducida y sin agregar alteraciones visuales ni difuminación.
Por lo general, no es recomendable mejorar la escala de una imagen, es decir, renderizar el objeto <img> a un tamaño mayor que el tamaño intrínseco de la imagen de origen.
La imagen que se muestre se vería borrosa y se vería granulada.
El uso de img { max-width: 100% } implica que, a medida que un contenedor flexible cambie de tamaño, se reducirá la escala de las imágenes según corresponda.
A diferencia de configurar un width: 100% más rígido, esto también garantiza que la imagen no se amplíe más allá de su tamaño intrínseco.
Durante mucho tiempo, eso fue todo por las reglas de trabajo con imágenes: usar un formato que entiendan los navegadores, emplear un nivel de compresión razonable y nunca escalar las imágenes hacia arriba.
Pero tan simple y eficaz como este enfoque fue visualmente, generó un gran costo de rendimiento. Como <img> solo admitía una única fuente para los datos de imagen, este enfoque requería que proporcionáramos un recurso de imagen con un tamaño intrínseco tan grande como el más grande en el que podría mostrarse. Una imagen destinada a ocupar un espacio en un diseño que podría tener un ancho entre 300px y 2000px, según el tamaño del viewport del usuario, requería una fuente de imagen con un ancho intrínseco de al menos 2000px. Para un usuario que solo ve la página a través de un viewport pequeño, todo se vería como se esperaba; la imagen se adaptaría bien. En la página renderizada, una imagen de origen masiva pero reducida no se vería diferente de una imagen de tamaño adecuado. Sin embargo, seguirán transfiriendo y renderizando una imagen ancha de 2000px, con una gran cantidad de ancho de banda y potencia de procesamiento sin beneficios tangibles.
La situación empeoraba con la llegada de los primeros dispositivos "Retina", ya que la densidad de la pantalla se convirtió en una preocupación además del tamaño del viewport. Una fuente de imagen necesita un ancho intrínseco mucho mayor para adaptarse a una pantalla de alta densidad. En términos simples, una pantalla con el doble de densidad requiere el doble de píxeles de imagen para renderizar la imagen de la manera más precisa posible.
Aquí, los desarrolladores volvieron a confiar en la capacidad de los motores de renderización para reducir visualmente la escala de las imágenes. Si proporcionas al navegador una imagen de origen ancha de 800px en src y, luego, especificas que debe mostrarse con un ancho de 400px con CSS, el resultado es una imagen que se renderiza con el doble de densidad de píxeles:
Una sola imagen de origen, cortada para adaptarse al espacio más grande posible en tu diseño y pantallas de alta densidad, funciona para todos los usuarios de manera visual, por supuesto. Una fuente de imagen enorme de alta resolución que se renderiza en una pantalla pequeña y de baja densidad se verá como cualquier otra imagen pequeña de baja densidad, pero se parecerá mucho más lenta. El usuario se quedará con todos los costos de rendimiento de esa fuente de imagen masiva de 4000 px de ancho, sin beneficio alguno.
Durante mucho tiempo, <img> hizo una sola acción: "obtuvo datos de imagen y los colocó en la pantalla". Lo hizo bastante bien, por cierto, pero <img> no estaba a la altura de la tarea de adaptarse a los cambios radicales en el contexto de navegación que estábamos experimentando. Si bien el diseño web responsivo se convirtió en una práctica de desarrollo popular, los navegadores optimizaron el rendimiento de img durante casi veinte años. Sin embargo, para todos los usuarios excepto los más privilegiados, el contenido de imágenes de las páginas fue ineficiente desde el principio. Sin importar cuán rápido el navegador haya logrado solicitar, analizar y renderizar una fuente de imagen, ese recurso probablemente será mucho más grande de lo que necesita el usuario.