Comme mobile et tablette les appareils se rapprochent de la domination finale du monde, 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 un tout nouvel ensemble de problèmes, l'un des derniers mots à la mode à émerger étant 'Web réactif' . C’est le défi de faire fonctionner le Web sur la plupart des appareils, sinon sur tous, sans dégrader l’expérience de l’utilisateur. Au lieu de concevoir un contenu adapté aux ordinateurs de bureau ou portables, les informations doivent être disponibles pour les téléphones mobiles, les tablettes ou toute surface connectée au Web. Cependant, ce site Web adaptatif l'évolution s'est avérée difficile et parfois douloureuse.

Bien qu'il puisse être presque insignifiant d'accueillir des informations textuelles, la partie délicate vient 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 la façon dont le contenu lui-même est consommé à l'aide de différents appareils. Les utilisateurs des téléphones intelligents sont différents des utilisateurs des 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 sites adaptés aux mobiles sur ses résultats de recherche, avec quelques spéculations qu'il conduira à une augmentation substantielle du pagerank vers ces sites. Les solutions antérieures ont résolu ce problème en déployant des sous-domaines (et des redirections) réservés aux mobiles, mais cette complexité a augmenté et est rapidement tombée à la mode. (Tous les sites n'ont pas la possibilité de se permettre cet itinéraire.)

À la recherche d'images Web réactives

l'erreur javascript n'est pas une fonction

À 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 les sites mobiles. Plus de 20% du trafic web est maintenant les utilisateurs mobiles, et le nombre continue d'augmenter. Les images prenant parmi les plus grandes parts de données de contenu de page, il devient prioritaire de réduire cette charge. Plusieurs tentatives ont été faites pour simplifier le redimensionnement d'image de conception réactive, y compris, à la fois des solutions côté serveur et frontales. Pour discuter de ces solutions d'image réactive, nous devons d'abord comprendre l'image actuelle reliant les lacunes.

Le La balise n'a que l'attribut source qui se lie directement à l'image elle-même. Il n'a aucun moyen de déterminer le type d'image correct nécessaire sans aucun add-on.

Ne pouvons-nous pas avoir toutes les tailles d’image incluses dans le HTML et utiliser des règles CSS pour display:none pour tout 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 rendre la page suffisamment rapide, le navigateur prélève le contenu lié avant même que les feuilles de style et les fichiers JavaScript nécessaires ne soient complètement 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 une charge de page encore plus grande. La technique CSS uniquement ne fonctionne que pour les images conçues comme images d'arrière-plan, car elles 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 de mise à l'échelle d'image réactive back-end

À l'exception des sites / sous-domaines réservés aux mobiles, nous nous retrouvons avec l'agent utilisateur (UA) reniflant et l'utilisant pour renvoyer les images correctement dimensionnées à l'utilisateur. Cependant, tout développeur peut attester à quel point cette solution peut être peu fiable. De nouvelles chaînes UA continuent à apparaître tout le temps, ce qui rend difficile la maintenance et la mise à jour d'une liste complète. Et bien sûr, cela ne prend même pas en compte le manque de fiabilité des chaînes UA facilement usurpables en premier lieu.

Images adaptatives

Cependant, certaines solutions côté serveur méritent d'être prises en considération. Images adaptatives est une excellente solution pour ceux qui préfèrent une correction d'image réactive back-end. Il ne nécessite aucun balisage spécial, mais utilise à la place un petit fichier JavaScript et effectue la plupart des travaux lourds dans son fichier back-end. Il utilise un serveur configuré PHP et nginx. Il ne repose pas non plus sur le reniflement UA, mais vérifie à la place la largeur de l'écran. Les images adaptatives fonctionnent très bien pour réduire les images, mais elles sont également utiles lorsque de grandes images ont besoin Direction artistique , c'est-à-dire la réduction d'image par des techniques telles que le recadrage et la rotation - pas seulement la mise à l'échelle.

Sencha Touch

Sencha Touch est une autre solution d'image de conception réactive back-end, bien qu'il soit préférable de la désigner comme une solution tierce. Sencha Touch redimensionnera l'image en conséquence en reniflant l'UA. Voici un exemple de base du fonctionnement du service:

comment apprendre angularjs à partir de zéro

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

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 à son tour le voyage demande-réponse. Une meilleure solution pourrait être que le périphérique lui-même détermine les ressources à demander directement et que le serveur réponde en conséquence.

Solutions frontales

Ces derniers temps, il y a eu de grandes améliorations du côté du navigateur pour traiter les images responsives.

L'élément 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 nativement. Jusque-là, nous nous appuyons sur des 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 du srcset attribut disponible pour plusieurs navigateurs basés sur le WebKit pour le élément. Cela peut être utilisé sans JavaScript et constitue une excellente solution si les navigateurs non WebKit doivent être ignorés. C'est une solution utile pour le cas étrange où d'autres solutions sont insuffisantes, mais ne doit pas être considérée comme une solution globale.

Picturefill

Picturefill est une bibliothèque polyfill pour l'élément. 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 en utilisant span tandis que Picturefill v2 utilise l'élément 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 contournements , notamment pour Android 2.3 - qui est d'ailleurs un exemple de l'endroit où le img srcset l'attribut vient à la rescousse. Vous trouverez ci-dessous un exemple de balisage pour l'utilisation de Picturefill v2:

Pour améliorer les performances des utilisateurs disposant de forfaits de données limités, Picturefill peut être combiné avec le chargement paresseux . Cependant, la bibliothèque pourrait offrir une prise en charge plus large du navigateur 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 nouvelles de la BBC équipe 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 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. Il fonctionne en utilisant des éléments d'espace réservé et en les remplaçant par éléments. L'exemple de code ci-dessous présente ce comportement:

qu'est-ce que l'interface utilisateur dans les jeux

new Imager({ availableWidths: [480, 768, 1200] });

Le HTML rendu ressemblera à ceci:

new Imager({ availableWidths: [480, 768, 1200] });

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 la source

Mélange de la source 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. Il ressemble à quelque chose qui sort de l'école de pensée «mobile first», dans lequel il sert la plus petite résolution possible par défaut. Lorsqu'il détecte qu'un appareil a un écran plus grand, il échange la source d'image pour 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 téléchargement de ressources doubles pour les ordinateurs de bureau et / ou les tablettes est inévitable.

Quelques autres bibliothèques JavaScript notables sont:

• HiSRC - Un plugin jQuery pour des images responsives. 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 puissante bibliothèque complète, mais peut être exagérée si l'objectif est juste des images réactives.

Sommaire

En fin de compte, c'est au développeur de décider lequel site Web adaptatif l'approche de l'image convient à la base d'utilisateurs. Cela signifie que la collecte et les tests de données donneront une meilleure idée de l'approche à adopter.

Pour conclure, la liste de questions ci-dessous peut être utile à considérer avant de décider de la solution d'image responsive appropriée.

• Les anciens navigateurs posent-ils un problème? Sinon, envisagez d'utiliser une approche plus moderne (par exemple: Picturefill, srcset attribut)
• 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 à des images responsives? Y a-t-il des préoccupations concernant la validation ou les balises sémantiques (ou plutôt les 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 avec 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.
• Le manque de JavaScript est-il préoccupant? Aucune des solutions frontales sera hors de question, ce qui laisse les options back-end ou tierces qui reposent sur le reniflage UA.
• Y a-t-il une priorité pour les temps de réponse mobiles par rapport aux temps de réponse des ordinateurs de bureau? Une bibliothèque comme Source Shuffling peut être plus appropriée.
• Est-il nécessaire de fournir un comportement réactif à tous les aspects du site, pas seulement aux images? Mobify.js pourrait mieux fonctionner.
• Le monde parfait a-t-il été atteint? Utiliser uniquement CSS display:none approche!