Le Web est un support visuel. La grande majorité de ce paysage visuel est dû aux fichiers image. Bien que de nombreuses possibilités soient possibles avec CSS et SVG en ligne, la plupart des sites ont encore besoin de fichiers image.
En moyenne, les images représentaient plus de la moitié de la taille de la page l’année dernière et l’année en année, la taille des images augmente; Il y avait un 21% de croissance en taille d'image en 2014 seulement.
Parallèlement, le nombre et la diversité des appareils accédant au Web continuent de croître. Les résolutions varient maintenant entre 72ppi (de moins en moins commun) et plus de 600ppi.
Créer une image pour l'écran d'une qualité suffisante pour n'importe quel périphérique est simple: enregistrez-la à 1000ppi et appelez-la un jour. L'image résultante sera nette même sur les périphériques haute résolution les plus élevés. Mais, même si votre qualité sera élevée, votre taille de fichier en dépendra également. Avec le temps de chargement de la page a facteur clé dans UX Il nous incombe de veiller à ce que les sites soient livrés rapidement à nos utilisateurs. Lorsque les images sont d'une qualité telle qu'il faut une dizaine de secondes pour les télécharger sur des connexions haut débit, sans parler des connexions mobiles, elles sont effectivement inutilisables.
L'objectif des images réactives n'est donc pas de fournir une image de qualité supérieure aux écrans capables de l'afficher (ce que nous pouvons faire facilement), le but étant de fournir une qualité d'image supportée et rien de plus.
Ce guide est conçu pour vous apprendre ce qui fonctionne, où se trouvent les problèmes et les pièges, et comment vous pouvez utiliser des images réactives sur des sites Web, aujourd'hui.
Pourquoi la vitesse est-elle importante? Nul n'est plus sur une connexion 3G? Personne n'utilise le dial-up. Si la population cible de votre client habite Manhattan, pourquoi devriez-vous vous soucier du Lesotho rural? Le fait est que c’est un mythe selon lequel nous sommes tous sur le très haut débit, qui nous est vendu par des sociétés qui profitent du désir d’accélérer les vitesses.
La plupart des gens passent au moins deux heures par jour sur une connexion inférieure. Je me trouve souvent avec la plupart du temps pour parcourir les trajets quotidiens, alors que même une connexion 3G fiable sonne comme un rêve lointain.
En avril Google a annoncé cette convivialité mobile serait utilisée comme facteur de classement pour les recherches effectuées sur des appareils qu’elle considère comme "mobiles". Même avant cela, la vitesse était un facteur dans le classement des pages - à la fois explicitement dans le cadre des calculs de Google et implicitement comme facteur contribuant à votre taux de rebond.
Sur deux sites classés de la même manière, un 1 Ko supplémentaire pourrait vous faire passer de la 3ème place sur Google à la 4ème ou 5ème place. Il pourrait même vous laisser passer du 10 au 11, c'est-à-dire de la page 1 à la page 2, avec tous les impacts associés sur les revenus de votre client.
L'image la plus optimisée est l'absence d'image. Si vous avez cinq images sur votre site et que vous en déposez une, vous avez économisé 20%, peut-être plus important encore, vous vous êtes enregistré une requête http. Si nous supprimions toutes les images de nos sites, nous nous épargnerions 100% et les cinq requêtes http. Alors pourquoi ne pas faire ça?
Nous ne déposons pas d'images de nos sites car elles communiquent plus efficacement que du texte à court terme. Ils créent un lien émotionnel qui attire les utilisateurs dans le contenu.
Nous savons que Les utilisateurs ne lisent pas les pages Web . Très peu de gens lisent le contenu en ligne en profondeur. Les images nous permettent de nous connecter, de communiquer et de renforcer une marque en une fraction du temps que le texte peut gérer.
Les images peuvent être volumineuses et difficiles à télécharger, mais une fois rendues dans le navigateur, elles sont bien plus efficaces que le texte pour établir l'engagement de l'utilisateur et renforcer le message de la marque.
Les images réactives nous aident à garantir que la connexion émotionnelle créée par les images ne soit pas perdue lorsque l'utilisateur impatient appuie sur le bouton Retour.
SVG (Scaleable Vector Graphics) est l'une des technologies pionnières du Web. C'est tellement en avance sur la courbe que la plupart des concepteurs n'ont toujours pas reconnu son véritable potentiel.
SVG - comme son nom l'indique - est basé sur un vecteur. Cela signifie que les graphiques SVG sont construits à partir de points, d’angles et de distances. SVG est également - comme son nom l’indique - évolutif, ce qui signifie qu’il s’affichera aussi bien sur un iMac 5k que sur un smartphone Android, sans perte de qualité et sans modification de la taille du fichier.
Si vous avez une illustration plate, une icône, un logo, à peu près tout ce qui peut être affiché en tant que SVG, SVG est la solution.
La plupart des images sur le Web sont des bitmaps. D'une manière générale, la façon dont fonctionne une bitmap consiste à décrire chaque pixel un par un, sa couleur (en RVB - valeurs rouge, verte et bleue) et, dans certains cas, sa transparence. Si vous avez une image mesurant 100 pixels sur 100, alors vous avez une image de 10 000 pixels; si chaque pixel a 4 valeurs pour le décrire, l'image est associée à 40 000 bits de données. On dirait que beaucoup ne le fait pas? Parfois, c'est moins qu'un graphique vectoriel.
Considérez une image de 1px par 1px; cela nécessiterait 4 bits de données pour enregistrer en tant que bitmap (valeurs rouge, verte, bleue et alpha). Considérons maintenant le même pixel carré enregistré comme vecteur; cela nécessiterait les valeurs x, y, width et height du rectangle, en plus des valeurs RGBA.
Ce sont des exemples rudimentaires, mais ils sont exacts. Souvent, une version vectorielle d'une image - si nous en avons une à notre disposition - dépasse la taille du fichier bitmap équivalent, et bitmap est alors le seul choix judicieux.
Comme la plupart des problèmes de la vie (si votre vie est en ligne), les images réactives peuvent être résolues par JavaScript. En fait, depuis plusieurs années, JavaScript était le seul moyen de résoudre le problème. JavaScript peut tester les capacités d'un agent utilisateur, déterminer quel type de navigateur il est et écrire une balise d'image HTML standard contenant l'image appropriée.
Les concepteurs Web qui s'opposent à l'utilisation de JavaScript le font généralement parce que certaines personnes l'éteignent . Cependant, ce n'est plus vraiment le cas, en particulier sur le Web mobile, mais certains problèmes persistent: l'écriture d'une image avec JavaScript signifie que l'image ne sera pas analysée par les robots des moteurs de recherche. comme run, par exemple.
Le plus gros problème avec l'utilisation de JavaScript est qu'il s'agit d'une utilisation abusive de l'objectif principal de JavaScript. HTML contient des données, CSS gère la présentation, JavaScript gère les fonctionnalités. Lorsque nous nous séparons de ces rôles structurés, nous commençons à rencontrer des problèmes qui nécessitent des efforts pour les résoudre. Les images sont des données et doivent donc être traitées par HTML.
Depuis que RWD a été conçu pour la première fois, les images ont été le principal obstacle. Mais maintenant, nous commençons à trouver des moyens de résoudre les différents problèmes. Des techniques qui ont le courage de se battre et sont suffisamment réussies pour être considérées comme des meilleures pratiques. Les développeurs dédiés ont abandonné leur temps pour faire pression sur le WC3 pour les solutions officielles, et maintenant, pour la première fois, les images réactives sont pratiques.
La clé de la réactivité des images est qu’elles ont été conçues avec une conscience totale des défaillances du Web. On a veillé à ce que les solutions d'images réactives ne rompent pas les navigateurs existants, de sorte que même dans les navigateurs ne prenant pas en charge les images réactives, le code échoue de manière silencieuse et non réactive, les images par défaut seront affichées.
Dans cet article, nous examinerons deux éléments HTML d'image réactifs officiels: srcset et picture.
À l'heure actuelle, Edge, Safari et iOS Safari ne prennent en charge qu'un sous-ensemble de la spécification srcset . Firefox, Chrome, Opera, le navigateur Android et les prochaines versions de Safari et iOS Safari le prennent entièrement en charge. (Nous discuterons des différences ci-dessous.)
Actuellement, l'élément d' image est entièrement pris en charge par Firefox, Chrome, Opera et Android Browser. Edge, Safari et iOS Safari ne le prennent pas en charge et n'ont pas annoncé de calendrier pour sa mise en œuvre.
Même parmi les navigateurs qui prennent en charge le nouveau code, il existe des incohérences car différents fabricants de navigateurs interprètent les spécifications du W3C de différentes manières. Par exemple, lorsque vous spécifiez un changement d'image de taille petite à grande en fonction de la taille de la fenêtre d'affichage, certains navigateurs basculent vers la grande image lorsque la fenêtre est supérieure à la taille préférée de la petite image. favorisé par la grande image est parfaitement adapté.
En résumé, les navigateurs sont divisés en deux camps: ceux qui favorisent les images de meilleure qualité lorsque cela est possible et ceux qui favorisent les téléchargements plus petits, lorsque cela est possible. Les fabricants de navigateurs tentent toujours de résoudre ce problème, et finalement, l'implémentation de quelqu'un se révélera la plus populaire - personnellement, j'espère que ce sera la dernière, car, comme indiqué ci-dessus, la performance est cruciale pour l'expérience utilisateur.
Pour le moment, la meilleure option pour les concepteurs Web est de respecter la spécification et de ne pas essayer de deviner le navigateur. Après tout, l'expérience par défaut du navigateur (qualité supérieure ou téléchargements plus rapides) fait partie de ce que l'utilisateur sélectionne pour un navigateur par défaut. Par conséquent, si l'utilisateur connaît les différentes approches, la préférence du navigateur est probablement la préférence de l'utilisateur .
Tout au long de l'histoire du Web, nous avons utilisé un élément pour indiquer une image, l'élément img . En HTML5, l'élément img a subi un léger changement de rôle, conçu pour permettre des images réactives: l'élément img ne représente plus une image, il est désormais un espace réservé pour une image.
Cette distinction est importante car, alors qu'un élément img contenait auparavant un seul ensemble de données d'image - que ce soit ce bitmap ou ce vecteur - une image peut désormais contenir plusieurs ensembles de données.
L'élément img (pour récapituler pour les non-codeurs) ressemble à ceci:
La version image réactive de l'élément img ressemble à ceci:
À peine aucun changement du tout. En regardant ce code, vous remarquez une chose importante: le code est rétrocompatible. Si un navigateur survient qui ne comprend pas l'attribut srcset , il l'ignorera simplement et restituera l'image conformément à la spécification originale de 1993.
Cela signifie que nous pouvons désormais utiliser des images réactives dans notre balisage, sans avoir besoin de détecter les fonctionnalités.
Dans le nouvel élément responsive img , src est principalement utilisé comme image par défaut et pour les navigateurs qui ne reconnaissent pas srcset, tandis que srcset contient toutes les images au format haute résolution disponibles pour cet espace réservé.
Lors du rendu de l'élément img , le navigateur déterminera lui-même le fichier image le plus approprié.
Maintenant que nous savons que srcset va échouer silencieusement dans les navigateurs qui ne le supportent pas, nous sommes libres d'ajouter une image supplémentaire:
Dans ce cas, tout navigateur supportant srcset affichera image-b.jpg et tout navigateur ne supportant pas srcset affichera image-a.jpg.
Il est important de noter que le navigateur ne télécharge que l'image qu'il décide d'afficher, il ne télécharge pas les deux images, puis en choisit une.
Malheureusement, cela ne nous mène pas très loin, car à moins de démontrer le support de srcset , il n’ya pas d’application pratique pour changer d’image en fonction du support de srcset .
La solution consiste à fournir au navigateur des informations supplémentaires sur l’image qu’il doit choisir. Pour ce faire, nous devons fournir des informations sur l’espace disponible ou la densité de pixels.
Le descripteur x indique à un navigateur la densité des pixels d’une image.
Si, par exemple, vous souhaitiez fournir une image de type rétine avec deux fois le nombre de pixels en tant qu'image standard, vous devez spécifier l'image de la rétine dans srcset, suivie d'un espace, puis du mot clé "2x".
Nous avons notre image:
Pour ajouter une option de rétine pour le navigateur, nous ajoutons le srcset suivant:
Dans ce cas, trois résultats sont possibles:
La prise en charge du navigateur est bonne et s’améliore rapidement. Avec un attribut, nous avons résolu l'énigme des images réactives, oui!
Une dernière chose à noter à propos du descripteur X: le choix de l'image à charger est basé sur la densité de pixels, donc si un utilisateur effectue un zoom de 200% sur son navigateur (divisant par deux la taille des pixels), le 2x l'image va charger. Cela peut avoir un effet néfaste sur l'accessibilité - nous ne voulons certainement pas voir les sites se charger plus lentement pour les malvoyants, simplement parce qu'ils choisissent de zoomer sur leur navigateur.
Le descripteur w est un peu plus avancé que le descripteur x. Le descripteur w fonctionne en indiquant au navigateur combien de pixels réels existent sur l'axe des x (la largeur) d'une option d'image particulière.
Edge, Safari et iOS Safari ne prennent pas en charge le descripteur w au moment de la rédaction. Son utilité est donc quelque peu réduite.
Revenons à notre image originale:
Si cette image a nativement 1600 pixels de large et si nous voulons ajouter une image de la rétine, comme nous l'avons fait avec le descripteur x ci- dessus, nous spécifierons une image dans l'attribut srcset de 3200 pixels de large:
Le descripteur w comporte un élément majeur : bien que l'attribut src soit traité par défaut lors de la spécification d'images à l'aide du descripteur x, il est totalement ignoré par les navigateurs prenant en charge srcset si vous utilisez le descripteur w. En utilisant le descripteur w, nous devons spécifier explicitement la valeur par défaut en ajoutant une seconde option image srcset , avec son propre descripteur w, et en les séparant par une virgule:
Ce qui nous amène parfaitement sur ...
Être capable de spécifier une option d'image haute résolution pour le navigateur directement dans notre code HTML est vraiment cool, mais comme vous l'avez probablement deviné, cela devient encore plus cool lorsque nous spécifions plusieurs images.
Le but des images réactives est de fournir la meilleure qualité d'image utilisable par le périphérique d'accès, mais rien de plus. Donc, fournir simplement une image rétinienne n'est pas suffisant, nous devons fournir des images, par exemple, 1x, 1.5x, 2x, 2.5x et 3x.
Encore une fois, voici notre balisage original:
La voici avec une image de qualité rétine fournie en option pour le navigateur:
La voici, cette fois avec des options supplémentaires dans le srcset, séparées par des virgules:
Parce que les mots-clés signifient différentes choses pour différentes personnes, je trouve opportun de nommer mes images en fonction du descripteur X auquel elles appartiennent, à la fois comme aide-mémoire personnelle et pour que les différentes tailles soient claires pour les autres membres de l'équipe:
Rappelez-vous, nous ne disons pas au navigateur quelle image afficher, nous le laissons connaître les options disponibles et lui permettre de choisir lui-même. Le navigateur ne télécharge qu'une de ces images.
Un piège à images multiples: ne spécifiez jamais deux images dans l'attribut srcset avec un descripteur x et un descripteur w correspondants, par exemple:
L'attribut Size est un ajout particulièrement intéressant à la spécification, car l'attribut Size prend ses valeurs par rapport à la fenêtre d'affichage, et non à l'image.
En utilisant la valeur vw (viewport width), nous spécifions la zone d'image par rapport à la largeur du navigateur - rappelez-vous que l'élément img n'est désormais qu'un espace réservé, nous ne spécifions donc pas la taille réelle de l'image. taille de l'espace réservé qui contiendra l'image.
100vw correspond à 100% de la largeur de la fenêtre d'affichage, 50vw correspond à 50% de la largeur de la fenêtre d'affichage, 25vw correspond à 25% de la largeur de la fenêtre d'affichage, etc.
Si nous voulions définir la largeur de l'image à la moitié de la largeur du navigateur, nous utiliserions:
Ce n'est pas particulièrement utile, jusqu'à ce que nous l'associons à des questions médiatiques ...
L'attribut Size devient beaucoup plus puissant lorsque nous l'associons à des requêtes multimédias. Nous pouvons séparer plusieurs largeurs de fenêtre à l'aide de virgules et indiquer au navigateur qu'il doit utiliser une requête multimédia de style CSS.
Par exemple, imaginons que nous voulons une image représentant 80% de la largeur de notre fenêtre d'affichage sur la majorité des appareils, mais sur les petits appareils (comme les téléphones) d'une largeur de 380px ou moins, nous voulons tirer le meilleur parti de espace disponible en constituant 100% de la largeur, nous écrivions comme ceci:
Suivant cette logique, tout navigateur avec une fenêtre d'affichage de 380px ou moins définira la largeur de l'image à 100% de la fenêtre d'affichage. Tout autre navigateur provoquera le retour de la requête multimédia et le navigateur passera à la valeur suivante de l'attribut Size, qui dans ce cas est 80vw.
En règle générale, je ne suis pas à l'aise avec les requêtes multimédia en HTML. Tout comme les données d'image réactives appartiennent à HTML (et non JavaScript), les requêtes multimédias appartiennent à CSS (et non HTML). Cependant, l'option est là pour vous si vous en avez besoin.
Je ne sais pas pour vous, mais je suis très excité par les possibilités de srcset. C'est une solution simple à un problème difficile et semble fournir tout ce dont nous avons besoin.
Mais, comme les bus, vous attendez 20 ans pour trouver une solution officielle aux images réactives, puis deux à la fois. En plus de l'attribut srcset de l'élément img , nous avons également l'élément picture .
L'élément image est un autre espace réservé, quoique plus traditionnel. Il a été conçu pour imiter les éléments vidéo et audio dans HTML5, donc sa syntaxe sera familière à la plupart. L'élément picture est destiné à être utilisé lorsque vous avez besoin de davantage de contrôle que srcset peut fournir.
Malheureusement, l'élément image a beaucoup moins de prise en charge du navigateur que srcset et il n'échoue pas toujours en silence.
Voici notre élément d'image original:
Voici notre image imbriquée dans un élément d'image:
Nous pouvons également spécifier un srcset pour un élément img dans un élément d' image :
L'élément image ne s'anime que lorsque nous ajoutons l'élément source :
Lors de la sélection du fichier à utiliser, le navigateur commencera par le premier élément source et parcourra les éléments jusqu’à ce qu’il en trouve un dont l’ attribut media a la valeur true, il utilisera alors le srcset de cet élément source .
Par exemple, nous pourrions spécifier différentes images pour les formats portrait et paysage:
Nous pouvons également spécifier plusieurs images en utilisant x-descriptor et w-descriptor:
Comme avec l'utilisation de requêtes multimédias dans l'attribut Size , je doute de la pertinence de contrôler les versions des images en fonction du style, du balisage au lieu d'une feuille de style. Toutefois, l'option permettant d'utiliser l'attribut media est disponible si vous en avez besoin.
L'élément d' image prend tout son sens lorsqu'il est utilisé pour échanger différents types d'images.
Imaginez que nous ayons un fichier PNG standard, mais nous voulons utiliser un fichier Fichier WebP, qui est généralement 26% plus petit - rappelez-vous que les images réactives ont pour but de fournir la meilleure qualité d'image, à la plus petite taille - mais actuellement uniquement pris en charge par Chrome, Opera et le navigateur Android. Nous devrons utiliser l'attribut type pour déterminer si WebP est supporté:
Dans ce cas, le navigateur vérifiera si le format d'image WebP est pris en charge. Si tel est le cas, il déterminera si l'écran a une densité de pixels suffisante pour afficher l'image rétina-image.webp , sinon il affichera l'image image.webp . Si WebP n'est pas pris en charge, le navigateur accèdera directement à l'élément img et utilisera les options srcset et src de la manière que nous connaissons déjà.
L'attribut type signifie que nous pouvons fournir des formats d'image beaucoup plus petits lorsqu'ils sont pris en charge, ce qui réduit la taille du fichier.
IE9 a un problème connu, Cela évite que l'élément image ne tombe en panne. Pour gérer IE9, vous devez inciter IE9 à penser que les éléments source font partie d'un élément vidéo :
C'est une solution moche, mais mieux que pas de solution du tout. Nous ne pouvons qu'espérer que la sortie de Windows 10 accélérera la disparition d'IE9, car si Edge ne prend pas encore en charge l'élément image , il ne le prend pas correctement en charge (en l'ignorant).
Il y a polyfills cela peut vous aider à prendre en charge l’élément image sur Internet Explorer, mais je préfère les éviter. Je me méfie des problèmes de correctifs avec JavaScript, cela affecte les performances et conduit à moins de code maintenable.
Pour cette raison, je recommande d'éviter l'élément d' image pour l'instant. À moins que vous ne gériez un site de commerce électronique à grande échelle, les économies supplémentaires sur le temps de téléchargement que le format WebP offre ne compenseront probablement pas le désagrément lié à l'application de correctifs à votre balisage avec un script.
Une fois que IE9 sera inférieur à 1%, ce qui devrait se produire au cours de l’année prochaine, l’élément image deviendrait viable. Si vous lisez ceci en 2016, vous êtes probablement bon.
Contrairement à SVG, les images bitmap ne sont pas mises à l'échelle. Notre stratégie pour les gérer, que nous utilisions srcset ou l'élément image , consiste à fournir une image différente en fonction des capacités du navigateur. Pour gérer cela, nous devons fournir différentes tailles d’images.
La plupart des applications d'édition d'images ont automatisé le processus d'exportation de plusieurs versions d'une même image. Peu importe l'application que vous utilisez, à condition que vous vous retrouviez avec plusieurs tailles d'image sans avoir à redimensionner et à enregistrer manuellement chacune.
Adobe Photoshop est l'éditeur bitmap de facto. Ce n'est pas un excellent choix pour le travail de conception, mais son flux de travail de traitement d'image est fluide et fiable. La génération de plusieurs résolutions d’image dans Photoshop est relativement simple:
Crédit pour l'image va à Philip Collier .
Pour plus d'informations sur la génération d'images dans Photoshop, vois ici.
Sur la base de ces images, nous pouvons offrir au navigateur cinq options différentes:
L'élément img a parcouru un long chemin en 20 ans. Ou, pour être plus précis, l'élément img était inadéquat pendant 18 ans, puis a été lancé pour la ligne au cours des deux dernières années, au point qu'il est maintenant relativement sophistiqué.
L'important, c'est que nous sommes arrivés à la solution.
Parmi les deux options disponibles, srcset et picture, la première est de loin la plus prise en charge. Si vous construisez 95% des sites, le meilleur support et la plus simple implémentation de l'attribut srcset sont votre meilleure option.
Si vous gérez un grand site de commerce électronique, avec des milliers d'images de produits, le travail supplémentaire pour servir le format WebP peut être utile, d'autant plus que la prise en charge de l'élément d' image augmente au cours des deux prochaines années.
La plus grande faiblesse dans les options actuelles est que les navigateurs ne disposent actuellement d'aucun moyen de sélectionner une image en fonction de leur vitesse de connexion. Nous sommes obligés de croire que des périphériques plus performants sont également sur des connexions supérieures.
En fin de compte, nous pouvons enfin servir les images de la plus haute qualité pratiquement possible, à la plus petite taille. Cela signifie une meilleure expérience, dans un temps plus court, qui ne peut être que quelque chose à embrasser.
Image utilisée, image de montagne et image de l'appareil via Shutterstock.