One Size Fits Some : Un guide pour les solutions d'image de conception Web réactives

Alors que les appareils mobiles et les tablettes se rapprochent de la domination mondiale finale, la conception et la technologie Web sont dans une course pour s'adapter au nombre toujours croissant de tailles d'écran. Cependant, concevoir des outils pour relever les défis de ce phénomène pose une toute nouvelle problématique, l'un des derniers mots à la mode étant celui de "web responsive". C'est le défi de faire fonctionner le Web sur la plupart des appareils, sinon tous, sans dégrader l'expérience de l'utilisateur. Au lieu de concevoir du contenu adapté aux ordinateurs de bureau ou aux ordinateurs portables, les informations doivent être disponibles pour les téléphones mobiles, les tablettes ou toute surface connectée au Web. Cependant, cette évolution de la conception Web réactive s'est avérée difficile et parfois douloureuse.

Bien qu'il puisse être presque trivial d'accueillir des informations textuelles, la partie délicate survient lorsque nous prenons en considération des contenus tels que des images réactives, des infographies, des vidéos, etc., qui étaient autrefois conçus uniquement pour les ordinateurs de bureau. Cela soulève non seulement la question de l'affichage correct du contenu, mais également de la façon dont le contenu lui-même est consommé à l'aide de différents appareils. Les utilisateurs de téléphones intelligents sont différents des utilisateurs d'ordinateurs de bureau. Des éléments tels que les plans de données et la vitesse de traitement doivent également être pris en compte. Google a commencé à mettre en évidence les sites adaptés aux mobiles dans ses résultats de recherche, certains spéculant que cela conduira à une augmentation substantielle du pagerank de ces sites. Les solutions antérieures ont résolu ce problème en déployant des sous-domaines (et des redirections) uniquement mobiles, mais cela a augmenté la complexité et est rapidement tombé en désuétude. (Tous les sites n'ont pas la capacité de se permettre cet itinéraire.)

À la recherche d'images Web réactives

À ce stade, les développeurs et les concepteurs doivent s'assurer que la charge de leur site Web est optimisée pour répondre aux utilisateurs qui se trouvent sur des sites mobiles. Plus de 20 % du trafic Web est désormais constitué d'utilisateurs mobiles, et ce nombre ne cesse d'augmenter. Avec des images prenant parmi les plus grandes parts de données de contenu de page, il devient une priorité de réduire cette charge. Plusieurs tentatives ont été faites pour simplifier le redimensionnement d'image de conception réactive, y compris des solutions côté serveur et frontales. Pour discuter de ces solutions d'images réactives, nous devons d'abord comprendre les lacunes actuelles en matière de liaison d'images.

La <img> n'a que l'attribut source lié directement à l'image elle-même. Il n'a aucun moyen de déterminer le bon type d'image nécessaire sans aucun module complémentaire.

Ne pouvons-nous pas simplement inclure toutes les tailles d'image dans le code HTML et utiliser les règles CSS pour display:none pour toutes, sauf la bonne image ? C'est la solution la plus logique dans un monde logique parfait. De cette façon, le navigateur peut ignorer toutes les images non affichées et, en théorie, ne pas les télécharger. Cependant, les navigateurs sont optimisés au-delà de la logique commune. Pour que la page s'affiche assez rapidement, le navigateur pré-extrait le contenu lié avant même que les feuilles de style et les fichiers JavaScript nécessaires ne soient entièrement chargés. Au lieu d'ignorer les grandes images destinées aux ordinateurs de bureau, nous finissons par avoir téléchargé toutes les images et résultant en un chargement de page encore plus important. La technique CSS uniquement ne fonctionne que pour les images destinées à être des images d'arrière-plan, car celles-ci peuvent être définies dans la feuille de style (à l'aide de requêtes multimédias).

Alors, qu'est-ce qu'un site Web à faire?

Solutions back-end de mise à l'échelle réactive des images

À l'exception des sites/sous-domaines uniquement mobiles, il nous reste à renifler l'agent utilisateur (UA) et à l'utiliser pour renvoyer les images correctement dimensionnées à l'utilisateur. Cependant, tout développeur peut attester du manque de fiabilité de cette solution. De nouvelles chaînes UA apparaissent constamment, ce qui rend difficile la maintenance et la mise à jour d'une liste complète. Et bien sûr, cela ne tient même pas compte du manque de fiabilité des chaînes UA facilement usurpables.

Images adaptatives

Cependant, certaines solutions côté serveur méritent d'être prises en considération. Adaptive Images est une excellente solution pour ceux qui préfèrent un correctif d'image réactif en back-end. Il ne nécessite aucun balisage spécial, mais utilise à la place un petit fichier JavaScript et effectue la majeure partie du travail lourd dans son fichier principal. Il utilise un serveur configuré PHP et nginx. Il ne s'appuie pas non plus sur le reniflement UA, mais vérifie plutôt la largeur de l'écran. Les images adaptatives fonctionnent très bien pour réduire les images, mais elles sont également pratiques lorsque de grandes images nécessitent une direction artistique, c'est-à-dire une réduction d'image par des techniques telles que le recadrage et la rotation - pas simplement la mise à l'échelle.

Touche Sencha

Sencha Touch est une autre solution d'image de conception réactive back-end, bien qu'il soit préférable de s'y référer en tant que solution tierce. Sencha Touch redimensionnera l'image en conséquence en reniflant l'UA. Vous trouverez ci-dessous un exemple de base du fonctionnement du service :

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

Il existe également une option pour spécifier les tailles d'image, au cas où nous ne voudrions pas que Sencha redimensionne l'image automatiquement.

En fin de compte, les solutions côté serveur (et tierces) nécessitent des ressources pour traiter la demande avant de renvoyer l'image correcte. Cela prend un temps précieux et ralentit le trajet requête-réponse. Une meilleure solution pourrait être que l'appareil lui-même détermine les ressources à demander directement et que le serveur réponde en conséquence.

Solutions frontales

Ces derniers temps, de grandes améliorations ont été apportées du côté du navigateur pour traiter les images réactives.

L'élément <picture> a été introduit et approuvé dans la spécification HTML5 par le W3C. Il n'est actuellement pas largement disponible sur tous les navigateurs, mais il ne faudra pas longtemps avant qu'il ne soit disponible en mode natif. Jusque-là, nous nous appuyons sur les polyfills JavaScript pour l'élément. Les polyfills sont également une excellente solution pour les navigateurs hérités dépourvus de l'élément.

Il y a aussi le cas de l'attribut srcset qui est disponible pour plusieurs navigateurs basés sur webKit pour l'élément <img> . Cela peut être utilisé sans JavaScript et constitue une excellente solution si les navigateurs non WebKit doivent être ignorés. Il s'agit d'un palliatif utile pour les cas étranges où d'autres solutions échouent, mais ne doit pas être considéré comme une solution complète.

Remplissage d'image

Picturefill est une bibliothèque polyfill pour l'élément <picture> . C'est l'une des bibliothèques les plus populaires parmi les solutions frontales aux problèmes de dimensionnement et de mise à l'échelle des images réactives. Il existe deux versions; Picturefill v1 imite l'élément <picture> en utilisant span tandis que Picturefill v2 utilise l'élément <picture> parmi les navigateurs qui l'offrent déjà et fournit un polyfill pour les anciens (par exemple, pour IE >= IE9). Il a quelques limitations et solutions de contournement, notamment pour Android 2.3 - qui est d'ailleurs un exemple où l'attribut img srcset vient à la rescousse. Vous trouverez ci-dessous un exemple de balisage pour l'utilisation de Picturefill v2 :

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

Pour améliorer les performances des utilisateurs avec des forfaits de données limités, Picturefill peut être combiné avec le chargement différé. Cependant, la bibliothèque pourrait offrir une prise en charge plus large des navigateurs et traiter les cas étranges plutôt que de s'appuyer sur des correctifs.

Imager.js

Imager.js est une bibliothèque créée par l'équipe de BBC News pour réaliser des images réactives avec une approche différente de celle utilisée par Picturefill. Alors que Picturefill tente d'apporter l'élément <picture> aux navigateurs non pris en charge, Imager.js se concentre sur le téléchargement uniquement des images appropriées tout en gardant un œil sur les vitesses du réseau. Il intègre également le chargement paresseux sans s'appuyer sur des bibliothèques tierces. Cela fonctionne en utilisant des éléments d'espace réservé et en les remplaçant par des éléments <img> . L'exemple de code ci-dessous présente 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 rendu 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>

La prise en charge du navigateur est bien meilleure que celle de Picturefill au détriment d'être une solution plus pragmatique qu'une solution avant-gardiste.

Mélange de sources

Source Shuffling aborde le problème de l'image réactive sous un angle légèrement différent de celui du reste des bibliothèques frontales. Cela ressemble à quelque chose qui sort de l'école de pensée "mobile first", dans laquelle il sert la plus petite résolution possible par défaut. Lorsqu'il détecte qu'un appareil a un écran plus grand, il remplace la source d'image par une image plus grande. Cela ressemble plus à un hack et moins à une bibliothèque à part entière. C'est une excellente solution pour les sites principalement mobiles, mais cela signifie que le double téléchargement de ressources pour les ordinateurs de bureau et/ou les tablettes est inévitable.

Certaines autres bibliothèques JavaScript notables sont :

• HiSRC - Un plugin jQuery pour les images réactives. La dépendance à jQuery peut être un problème.
• Mobify.js - Une bibliothèque plus générale pour le contenu réactif, y compris les images, les feuilles de style et même JavaScript. Il "capture" le DOM avant le chargement des ressources. Mobify est une bibliothèque complète et puissante, mais peut être exagérée si l'objectif n'est que des images réactives.

Sommaire

En fin de compte, il appartient au développeur de décider quelle approche d'image de conception Web réactive convient à la base d'utilisateurs. Cela signifie que la collecte de données et les tests donneront une meilleure idée de l'approche à adopter.

Pour conclure, la liste de questions ci-dessous peut être utile à prendre en compte avant de décider de la solution d'image réactive appropriée.

• Les anciens navigateurs sont-ils un problème ? Sinon, envisagez d'utiliser une approche plus moderne (par exemple : Picturefill, attribut srcset )
• Le temps de réponse est-il critique ? Sinon, optez pour une solution tierce ou back-end.
• Les solutions sont-elles censées être internes ? Les solutions tierces seront évidemment exclues.
• Y a-t-il déjà beaucoup d'images sur un site qui essaie de passer aux images réactives ? Y a-t-il des soucis de validation ou de balises sémantiques (ou plutôt de balises non sémantiques) ? Cela nécessitera une solution back-end pour acheminer les demandes d'image vers quelque chose comme Adaptive Images.
• La direction artistique est-elle un problème (en particulier pour les grandes images contenant beaucoup d'informations) ? Une bibliothèque comme Picturefill sera une meilleure solution pour un tel scénario. De plus, toutes les solutions back-end fonctionneront également.
• Y a-t-il une préoccupation concernant le manque de JavaScript ? Toutes les solutions frontales seront hors de question, ce qui laisse les options back-end ou tierces qui reposent sur le reniflage UA.
• Existe-t-il une priorité pour les temps de réponse des mobiles par rapport aux temps de réponse des ordinateurs ? Une bibliothèque comme Source Shuffling peut être plus appropriée.
• Est-il nécessaire de fournir un comportement réactif à chaque aspect du site, pas seulement aux images ? Mobify.js pourrait mieux fonctionner.
• Le monde parfait a-t-il été atteint ? Utilisez l'approche CSS-only display:none !