I. Sur la quête des images Responsive Web▲
Jusqu'ici, les développeurs et designers devaient s'assurer que le chargement de leur site était optimisé pour les utilisateurs sur mobiles. Plus de 20 % du trafic web aujourd'hui concerne les utilisateurs de mobiles, et le nombre croît toujours. Comme les images sont une des parts les plus grandes du contenu d'une page en taille de données, il devient prioritaire de réduire cette charge. Plusieurs tentatives ont été faites pour simplifier le rognage d'images en responsive design, incluant des solutions à la fois côté serveur et côté client. Avant de discuter de ces solutions, nous devons d'abord comprendre quelles sont les limitations du mécanisme actuel de lien des images.
La balise <img> a seulement un seul attribut source reliant directement à l'image elle-même. Il n'y a pas moyen de déterminer le type correct d'image à charger sans composant additionnel.
Ne pouvons-nous pas juste avoir toutes les tailles d'image incluses dans le HTML, et utiliser des règles « CSS display:none » pour toutes les cacher sauf la bonne image ? C'est la solution la plus logique dans un monde parfaitement logique. De cette manière, le navigateur peut ignorer les images non affichées et, en théorie, ne pas les télécharger. Cependant, les navigateurs sont optimisés au-delà du sens commun de la logique. Pour faire en sorte que la page soit affichée plus rapidement, le navigateur précharge tout le contenu lié à celle-ci avant même que les feuilles de style et scripts nécessaires soient totalement chargés. Au lieu d'ignorer les grandes images destinées aux ordinateurs de bureau, on se retrouve à charger toutes les images, ce qui résulte en un chargement encore plus lourd. Cette technique CSS fonctionne uniquement pour les images prévues en tant qu'arrière-plans, car elles peuvent être définies dans les feuilles de style (avec éventuellement des media queries).
Donc, que faut-il faire pour un site web ?
II. Solutions de mise à l'échelle d'images côté serveur ▲
À moins que le site soit destiné exclusivement au mobile ou qu'il possède un sous-domaine dédié mobile, nous sommes contraints d'utiliser la technique du User Agent sniffing pour détecter le type de périphérique et s'en servir pour renvoyer des images à la bonne taille à l'utilisateur. Cependant, tout développeur peut attester du manque de fiabilité de cette approche. De nouveaux User Agents apparaissent sans cesse, ce qui rend très fastidieux le maintien à jour d'une liste exhaustive. Et bien sûr, cela ne tient pas compte de la grande facilité pour les utilisateurs de modifier leur User Agent.
II-A. Adaptive Images▲
Cependant, certaines solutions côté serveur sont dignes d'intérêt. Les Adaptive images sont une très bonne solution pour ceux qui préfèrent un fix côté serveur pour les images responsive. Cela ne nécessite aucun balisage spécial, mais utilise un petit fichier JavaScript et fait le gros du travail en back-end. Il nécessite PHP et un serveur nginx correctement configuré. Aussi, il ne repose pas sur l'User Agent sniffing, mais sur la largeur d'écran. Les Adaptive images fonctionnent très bien pour réduire la taille des images, mais c'est également pratique quand de grandes images ont besoin d'une direction artistique ; par exemple, des techniques de réduction comme le rognage - et non juste une mise à l'échelle.
II-B. Sencha Touch▲
Sencha Touch est une autre solution back-end pour les images responsive, cependant il convient de la designer comme une solution tierce d'un prestataire externe. Sencha Touch retaillera vos images selon le User Agent reçu. Ci-dessous, un exemple basique montrant comment le service fonctionne :
<img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">Il y a aussi une option pour spécifier les tailles de l'image, dans le cas où vous ne voulez pas que Sencha retaille l'image automatiquement.
Finalement, les solutions côté serveur (et de prestataires externes) nécessitent d'allouer des ressources pour traiter les requêtes avant d'envoyer en retour la bonne image. Cela requiert un temps précieux et ralentit l'échange requête/réponse. Une meilleure solution pourrait être de déterminer par l'appareil lui-même quelles ressources requêter directement, et laisser le serveur répondre en conséquence.
III. Solutions côté client▲
Ces derniers temps, il y a eu de gros progrès côté navigateur pour résoudre le cas des images responsive.
L'élément <picture> a été introduit et approuvé par le W3C dans la spécification HTML5. Actuellement, il n'est pas répandu largement sur les différents navigateurs, mais cela ne sera pas long avant qu'il soit disponible nativement. En attendant, nous reposons sur des polyfills JavaScript pour supporter cet élément. Les polyfills sont une excellente solution pour les navigateurs obsolètes ne supportant pas cet élément.
Il y a aussi le cas de l'attribut srcset qui est supporté par plusieurs navigateurs basés sur le moteur Webkit pour l'élément <img>. Il peut être utilisé sans JavaScript et s'avère être une très bonne solution si les navigateurs non Webkit peuvent être ignorés. C'est un palliatif utile dans le cas où les autres solutions échouent, mais cela ne devrait pas être considéré comme une solution globale.
III-A. Picturefill▲
Picturefill est une bibliothèque polyfill pour l'élément <picture>. C'est l'une des bibliothèques les plus populaires parmi les solutions côté client pour le rognage et la mise à l'échelle d'images responsive. Il y a deux versions : Picturefill v1 imite l'élément <picture> en utilisant un élément span tandis que Picturefill v2 utilise l'élément<picture> pour les navigateurs le supportant, et un polyfill pour les autres (IE9 par exemple). Il y a un certain nombre de limitations et solutions de contournement, en particulier pour Android 2.3 - qui est involontairement un bon exemple où l'attribut img srcset vient à la rescousse. Ci-dessous, un exemple de code HTML pour Picturefill v2 :
<picture>
<source srcset="/images/kitty_large.jpg" media="(min-width: 768px)">
<source srcset="/images/kitty_medium.jpg" media="(max-width: 767px)">
<img srcset="/images/kitty_small.jpg" alt="My Kitty Cat">
</picture>Pour améliorer la performance pour les utilisateurs avec des forfaits limités en data, Picturefill peut être combiné avec du chargement à la demande. De plus, cette bibliothèque lazyload peut offrir un support navigateur plus large et s'occuper de cas particuliers plutôt que de compter sur des patchs correctifs.
III-B. Imager.js▲
Imager.js est une bibliothèque créée par les équipes de BBC News pour parvenir à des images responsive en suivant une approche différente de celle utilisée par Picturefill. Là où Picturefill essaie d'apporter l'élément <picture> aux navigateurs non supportés, Imager.js se concentre sur le fait de télécharger uniquement les images appropriées tout en gardant un œil sur la vitesse du réseau. Il intègre également une solution de chargement à la demande sans nécessiter de dépendance externe. Cela fonctionne grâce à des éléments placeholder remplacés à l'exécution par des éléments <img>. Le code ci-dessous décrit ce comportement :
<div>
<div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div>
</div>
<script>
new Imager({availableWidths: [480, 768, 1200]});
</script>Le HTML final ressemblera à ceci :
<div>
<img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace">
</div>
<script>
new Imager({availableWidths: [480, 768, 1200]});
</script>Le support navigateur est bien meilleur que pour Picturefill au prix d'une solution plus pragmatique, moins tournée vers l'avenir.
III-C. Brassage de sources (Source Shuffling)▲
Le brassage de sources approche le problème des images responsive d'un angle légèrement différent que le reste des bibliothèques côté client. Cela rejoint davantage l'école de pensée « Mobile first », par le fait qu'il dessert la plus petite résolution par défaut. Lors de la détection d'un appareil disposant d'un plus grand écran, il échange la source de l'image pour sa version agrandie. Cela ressemble davantage à un hack qu'à une bibliothèque tout équipée. C'est une excellente solution pour des sites principalement destinés au mobile, mais cela implique de télécharger deux ressources au lieu d'une pour les ordinateurs à grand écran et tablettes.
D'autres bibliothèques JavaScript notables sont :
- HiSRC - un plugin jQuery pour les images responsive. La dépendance à jQuery peut être un problème ;
- Mobify.js - une bibliothèque plus générale pour du contenu responsive, incluant des images, des feuilles de style et même des bouts de JavaScript. Il « capture » le DOM avant de charger les ressources. Mobify est une solution puissante, mais peut-être un peu overkill si l'objectif se limite à des images responsive.
IV. Résumé▲
Finalement, c'est au développeur de décider quelle approche choisir pour les images en Responsive Web Design pour ses utilisateurs. Cela signifie que collecter des données et effectuer des tests vous donnera une meilleure idée de la bonne approche à prendre.
Pour résumer, voici la liste des questions à se poser avant de choisir une solution d'image responsive.
- Est-ce que les navigateurs obsolètes sont un problème ? Si ce n'est pas le cas, considérez une approche plus moderne (exemple, Picturefill, srcset).
- Est-ce que le temps de réponse est critique ? Si ce n'est pas le cas, optez pour une solution côté serveur ou un prestataire externe.
- Est-ce que la solution doit être gérée au sein de l'entreprise ? Les solutions tierces seront évidemment éliminées d'office.
- Y a-t-il un tas d'images déjà présentes sur un site qu'il faut essayer d'adapter en responsive ? Y a-t-il des préoccupations quant à la validation ou la sémantique des éléments ? Cela nécessitera alors une solution côté serveur pour router vers les bonnes images, donc quelque chose comme les Adaptive images.
- Est-ce que la direction artistique est un problème (en particulier pour les grandes images avec beaucoup d'informations) ? Une bibliothèque comme Picturefill peut être une meilleure solution dans un tel scénario. Aussi, toute solution côté serveur peut fonctionner aussi bien.
- Est-ce que la désactivation de JavaScript est une préoccupation ? Cela élimine toutes les solutions côté client, il reste alors les solutions côté serveur ou externes reposant sur le User Agent sniffing.
- Le temps de réponse sur mobile est-il plus important que le temps de réponse sur ordinateurs fixes ? Le brassage de sources sera alors plus approprié.
- Y a-t-il un besoin de fournir un comportement responsive pour tous les aspects du site, et pas juste les images ? Mobify.js peut mieux convenir.
- Est-ce qu'on est arrivé à un monde parfait ? Utilisez alors CSS uniquement et display:none !
V. À propos de l'auteur▲
Kado Damball est un développeur JavaScript intéressé par les données et la visualisation de données. C'est aussi un passionné de machine learning et de data mining, un sous-produit de son BA en économies. Il travaille actuellement en tant que développeur freelance. [En savoir plus…]
Nous le remercions d'avoir accepté que son article soit traduit et partagé, et vous invitons à consulter l'article original :
One Size Fits Some: A Guide to Responsive Web Design Image Solutions.
Nous remercions également Claude LELOUP et Jacques THERY pour la relecture orthographique.