Peu importe votre niveau d'apprentissage de la conception et du développement pour le Web, l'élément <img> nécessite très peu de présentation.
Lancé dans Netscape ("Mosaic" à l'époque) en 1993 et ajouté à la spécification HTML en 1995, <img> a longtemps joué un rôle simple, mais puissant au sein de la plate-forme Web. Le développeur ajoute un fichier image "source" avec l'attribut src et fournit une alternative textuelle avec l'attribut alt si l'image ne peut pas être affichée ou si des technologies d'assistance demandent une autre méthode. À partir de là, le navigateur n'a qu'une seule tâche à effectuer: récupérer les données des images, puis les afficher le plus rapidement possible.
Pour la majeure partie de l'historique du développement Web, travailler avec des images n'a pas été beaucoup plus compliqué que cela. Malgré la complexité du Web moderne, les principes fondamentaux de l'utilisation des images n'ont pas changé: utilisez un format d'image adapté au Web pour la compatibilité, une compression raisonnable pour économiser la bande passante et des dimensions adaptées à l'espace que l'image occupera dans la mise en page.
L'utilisation de mises en page à largeur fixe, comme nous l'avons fait lorsque nous pensions que nous avions plus d'impact sur l'expérience des utilisateurs sur le Web, a simplifié ce processus. La taille de la source de l'image était particulièrement facile à définir. Pour une image qui occupait un espace de 500 pixels de large et 300 pixels de haut, il s'agissait de spécifier une image source de la même taille.
Images dans une mise en page responsive
Outre la mise en page flexible et l'utilisation de requêtes média CSS, les "images et médias flexibles" sont l'un des trois attributs définissant le Responsive Web Design. Pour rendre une image flexible, les développeurs ont commencé à utiliser CSS pour définir max-width: 100% sur l'image (ou sur toutes les images, sur l'ensemble du site) afin d'indiquer au moteur de rendu du navigateur d'empêcher une image de dépasser son conteneur parent en la réduisant. Visuellement, cela fonctionne parfaitement : la réduction de la taille d'une image matricielle est fluide. Avec une ou deux lignes de code CSS, une image réduite ressemblera toujours à une source d'image censée s'afficher à cette taille.
Lorsque les moteurs de rendu reçoivent plus de données d'image que nécessaire pour l'espace occupé par l'image dans une mise en page, ils peuvent prendre des décisions éclairées sur la façon d'afficher l'image réduite, et ce sans introduire d'artefact visuel ni de floutage.
En règle générale, il n'est pas recommandé d'augmenter la taille d'une image, c'est-à-dire d'afficher <img> à une taille supérieure à la taille intrinsèque de l'image source.
L'image affichée semble floue et présente du grain.
L'utilisation de img { max-width: 100% } signifie que lorsque le conteneur est redimensionné, les images sont réduites en fonction du redimensionnement.
Contrairement à la définition d'un width: 100% plus rigide, cela garantit également que l'image ne sera pas agrandie au-delà de sa taille intrinsèque.
Pendant longtemps, cela a été nécessaire pour les règles de travail avec les images: utilisez un format compréhensible par les navigateurs, utilisez un niveau de compression raisonnable et ne redimensionnez jamais les images à la hausse.
Mais aussi simple et efficace que l'aspect visuel de cette approche, son coût en termes de performances était énorme. Étant donné que <img> n'acceptait qu'une seule source pour les données d'image, cette approche nous a obligés à fournir un composant Image dont la taille intrinsèque est aussi grande que la plus grande taille à laquelle il pouvait être affiché. Une image destinée à occuper un espace dans une mise en page dont la largeur peut être comprise entre 300px et 2000px en fonction de la taille de la fenêtre d'affichage de l'utilisateur nécessitait une source d'image ayant une largeur intrinsèque d'au moins 2000px. Pour un utilisateur qui ne voit la page que via une petite fenêtre d'affichage, tout se présentera comme prévu et l'image s'adaptera parfaitement. Sur la page affichée, une image source volumineuse, mais réduite, n'aurait pas l'air différente d'une image de taille appropriée. Toutefois, ils transféreraient et afficheront toujours une image large de 2000px, ce qui consommerait une énorme quantité de bande passante et de puissance de traitement sans aucun avantage tangible.
La situation s'est bien aggravée avec l'avènement des premiers appareils "Retina", car la densité d'affichage est devenue un problème en plus de la taille de la fenêtre d'affichage. Une source d'image nécessite une largeur intrinsèque bien plus grande pour s'adapter à un affichage haute densité. En bref, un écran avec une densité doublée nécessite deux fois plus de pixels d'image pour afficher l'image aussi nettement que possible.
Les développeurs ont à nouveau pu s'appuyer sur la capacité des moteurs de rendu à réduire visuellement les images. En fournissant au navigateur une image source large 800px dans src, puis en spécifiant qu'elle doit s'afficher sur une largeur de 400px avec CSS, vous obtenez une image avec une densité de pixels doublée:
Une image source unique, découpée pour s'adapter à l'espace le plus grand possible dans votre mise en page et vos écrans haute densité, fonctionne bien sûr pour tous les utilisateurs visuellement. Une grande source d'image haute résolution affichée sur un petit écran à faible densité ressemble à n'importe quelle autre image basse densité, mais est beaucoup plus lente. L'utilisateur assumera tous les coûts de performances de cette immense source d'images de 4 000 pixels de large, sans aucun avantage.
Pendant longtemps, <img> a principalement fait une action : "il a obtenu des données d'images et les a affichées à l'écran". Il a assez bien fait, c'est certain, mais <img> n'était pas en mesure de s'adapter aux changements radicaux dans le contexte de navigation que nous observons. Le Responsive Web Design est devenu une pratique de développement courante, mais les navigateurs ont optimisé les performances de img pendant près de 20 ans. Mais pour tous les utilisateurs, à l'exception des utilisateurs les plus privilégiés, le contenu des images des pages était inefficace dès le départ. Quelle que soit la vitesse à laquelle le navigateur parvenait à demander, analyser et afficher une source d'images, cet élément serait probablement beaucoup plus volumineux que ce dont l'utilisateur avait besoin.