Le besoin de l’heure n’est pas une conception réactive mais des performances réactives

1

La conception réactive a présenté plusieurs problèmes de performances ces derniers temps. L’ironie est que le design réactif se porte plutôt bien sur la dernière gamme de smartphones, mais rien de plus.

Vous pouvez être confus car la plupart des internautes ont des smartphones haut de gamme. Cependant, une grande partie de la population utilise encore des appareils mobiles avec une petite taille d’écran fonctionnant sur une ancienne version d’Android ou d’iOS et peut-être juste un téléphone avec peu de fonctionnalités. En conséquence, la conception réactive ne sert pas un public plus large comme elle est censée le faire.

La croyance de longue date selon laquelle la conception réactive est destinée aux appareils mobiles de toute taille d’écran a beaucoup à voir avec ce problème. Alors que les performances diminuent et que l’insatisfaction augmente, il est nécessaire de regarder au-delà de la conception réactive. L’accent devrait plutôt être mis sur la garantie d’une performance réactive. Ce poste est à peu près le même.

Alors, la grande question est que faire ?

Ignorer le concept de conception axé sur le bureau

Un contributeur important à ce problème persistant est que l’accent est toujours mis sur une approche de conception axée sur le bureau. L’accent est mis sur la conception d’un site Web pour un ordinateur de bureau, puis sur la conception pour d’autres appareils tels que les smartphones et les tablettes. Pour toute fonctionnalité manquante, les développeurs utilisent généreusement les cales et les polyfills. Bien sûr, il existe de vastes bibliothèques pour assurer un développement rapide. Cependant, cela ne résout pas le problème de l’incompatibilité du navigateur. Est-il justifié de s’engager dans un concept de design qui ne donne pas les résultats souhaités ?

Il n’est pas très difficile de mettre en œuvre une approche de conception axée sur le mobile dans laquelle le but sera d’offrir uniquement les informations prévues à l’utilisateur mobile sur son écran au lieu de toutes les choses qui tuent l’appareil. Luke Wroblewski a conceptualisé cette approche de conception pour la première fois en 2011 et depuis lors, de nombreux experts de l’industrie ont loué son approche de conception révolutionnaire.

Plus de données, même si cela ne prend qu’une fraction de seconde, peut avoir un impact remarquable sur le temps de chargement global. Cependant, il est également vrai que les sites Web sont de plus en plus chargés de contenu graphique et que de plus en plus de personnes utilisent leurs appareils mobiles pour y accéder. Lorsqu’un utilisateur tape l’URL d’un site Web sur un mobile avec un écran basse résolution, son objectif est toujours d’accéder au contenu du site Web, mais ce qu’il vit est un cauchemar. Cela est dû à la difficulté de naviguer dans les publicités inutiles sans fin. Supprimez ces éléments de contenu évitables pour permettre à votre utilisateur d’accéder au contenu principal. Cela augmente le trafic sur le site, car en dehors des utilisateurs de smartphones haut de gamme, beaucoup accéderont à votre site Web via des appareils mobiles à faible résolution. La livraison d’une version textuelle est parfaitement logique si le mobile a des capacités limitées, mais encore une fois, vous pouvez dire que l’expérience utilisateur est compromise. Eh bien, c’est le cas, mais c’est toujours mieux que de ne recevoir aucun contenu. Au moins dans un tel cas, les utilisateurs auront accès aux informations de base sur votre site. Y a-t-il un intérêt à concevoir un site Web de manière à réduire sa portée potentielle ?

Vous accepterez sûrement le fait qu’attendre sans fin uniquement pour consulter un site Web n’excite personne. Selon certaines enquêtes d’Akamai et de Gomez.com, environ 50 % des internautes s’attendent à ce qu’un site Web se charge en 2 secondes, voire moins. Il y a plus de chances d’abandon de site si un site Web ne se charge pas dans le navigateur en seulement 3 secondes! De plus, la plupart des sites e-commerce disposent aujourd’hui d’un grand nombre de boutons de partage social comme Facebook, Google Plus, Twitter, LinkedIn, etc. Savez-vous que ces boutons ajoutent plus de 500 Ko à votre site responsive et affectent ses performances? Le bouton J’aime de Facebook demande à lui seul un code compressé de 270 Ko! Il nécessite également plusieurs requêtes HTTP. À la place,

Les performances d’un site Web ont un impact direct sur les performances d’une entreprise et un site Web lent ne fait jamais rien de bon pour une entreprise. Croyez-le ou non, la plupart des utilisateurs mobiles ne sont pas intéressés à faire des recherches ou à lire de longs articles. La plupart d’entre eux utilisent leurs appareils mobiles pour accéder facilement à Facebook, WhatsApp, Twitter et pour se livrer au plaisir des achats en ligne. De plus, le mobile n’est plus une tendance, c’est l’avenir.

Selon les statistiques de l’année dernière de Comscore, le nombre d’utilisateurs d’Internet uniquement mobiles aux États-Unis a fortement augmenté tandis que les utilisateurs d’ordinateurs de bureau uniquement sont réduits à 10,6 %.

Besoin d’en dire plus pour convaincre ?

Assurer une dégradation gracieuse

Au cours des dernières années, vous avez peut-être rencontré le nouveau mot à la mode dans le monde du design réactif, et c’est la "dégradation gracieuse". Oui, la dégradation gracieuse implique que même si une fonctionnalité ne fonctionne pas avec succès, elle doit échouer d’une manière qui facilite une utilisabilité acceptable. Cela signifie créer une conception de site Web pour un ordinateur de bureau, puis passer progressivement aux tablettes, aux smartphones et aux téléphones polyvalents. La performance d’un design réactif dans lequel le site Web se dégrade gracieusement est forcément élevée car l’expérience utilisateur est ici toujours de premier ordre. Le site Web restera fonctionnel malgré toutes les lacunes, et un visiteur sera sûrement impressionné par la qualité globale.

Maintenant, vous pouvez avoir cette question dans votre esprit, qu’est-ce qui est si fascinant dans la dégradation gracieuse. La réponse est simple. En effet, cela rend votre contenu, visible et lisible quel que soit le navigateur, ce qui est une prouesse remarquable! Heureusement, si vous utilisez CSS3, la dégradation gracieuse devient une tâche facile car la plupart des propriétés de CSS3 se dégradent automatiquement, c’est-à-dire que les coins arrondis deviennent carrés, le texte est enveloppé au lieu de s’exécuter sur une seule ligne, les dégradés deviennent des couleurs plates, et bien plus encore.

Prenons un exemple de dégradation gracieuse. Supposons que vous avez conçu un site Web réactif avec des fonctionnalités JavaScript et que ces fonctionnalités ne sont pas prises en charge par votre navigateur ou peuvent être désactivées du côté de votre client. Alors, que pouvez-vous faire pour obtenir le contenu ? Eh bien, dans un tel cas, la dégradation gracieuse permet à votre navigateur d’afficher le contenu dans la balise "noscript".

Vous pouvez mieux comprendre cela avec le codage ci-dessous :

<noscript>
<h1>Dear John, you have encountered a problem!</h1>
<p>Your browser lacks support for JavaScript or is temporarily disabled.
Visit our <a href="/support/browsers/">browser support</a> for help.</p>
</noscript>

Il y a un autre exemple de dégradation gracieuse que je voudrais partager, et c’est l’utilisation de HTML5 par YouTube pour lire des vidéos. Supposons que votre navigateur ne supporte pas HTML5, la vidéo s’affichera en utilisant Flash, et si même Flash n’est pas installé, vous recevrez un message pour l’installer sur votre appareil mobile. Dans les deux cas, vous pourrez regarder la vidéo. Cependant, un inconvénient de cette dégradation élégante est que, bien que les performances soient bonnes, vous devez faire des compromis avec certains éléments de conception si vous utilisez des navigateurs obsolètes. Je suppose que déterminer à l’avance les éléments visuels essentiels de votre site Web peut faire l’affaire.

Inutile de conserver les bibliothèques inutilisées

Une bonne pratique peut être de ne pas conserver les bibliothèques qui ne sont pas utilisées. Oui, il est vrai que garder une trace des bibliothèques utilisées et de celles qui ne sont pas utilisées prend beaucoup de temps, mais cela en vaut vraiment la peine. Parfois, vous avez peut-être remarqué que vous n’utilisiez qu’une seule fonctionnalité après l’inclusion d’une bibliothèque. Cela peut être parfois deux ou trois même. L’outil que j’utilise le plus souvent pour créer un design réactif est jQuery. En fait, il existe de nombreuses bibliothèques jQuery aidant les développeurs à créer des sites Web réactifs. Une inclusion de plusieurs bibliothèques comme les bibliothèques JavaScript simplement parce que vous avez aimé certains widgets va augmenter considérablement le temps de chargement de votre page. Cependant, ce sera une bonne pratique d’analyser quelles bibliothèques sont utilisées et dans quelle mesure.

Vérifier la disponibilité des fonctionnalités

Vous pouvez vérifier si votre appareil prend en charge une certaine fonctionnalité ou non avant de l’activer. Par exemple, il arrive que bien que vous ayez installé la dernière version de Google Chrome sur votre téléphone Android obsolète, il n’affiche toujours pas votre site Web. Parfois, lors d’une tentative de chargement d’un tel site Web, le navigateur est tellement planté qu’il rend l’ensemble de l’appareil mobile insensible. Vous devez redémarrer l’appareil, et c’est la dernière chose que vous avez souhaitée, n’est-ce pas ? De nombreux utilisateurs de certaines applications Web souffrent déjà de ce problème.

L’indisponibilité des fonctionnalités sur les appareils et pourtant la conception de sites Web ou d’applications a entraîné des problèmes notables, comme le plantage instantané des applications Google Hangout sur les appareils Android dans le monde entier, quel que soit le type de navigateur. Ceci en dépit du fait que l’application était une application légère. Vous pouvez affirmer que les utilisateurs utilisaient une ancienne version des smartphones Android, mais il est également vrai que ces appareils sont toujours disponibles sur étagère en tant que tout nouveau dans l’un des magasins mobiles. De nombreux utilisateurs mobiles sont également confrontés au même problème de performances avec les applications YouTube et Twitter. Même une mise à jour du service Android System Webview de Google via Google Play fige de nombreux smartphones pour devenir une sorte de cauchemar des utilisateurs.

Optimiser les images

Inclure de grandes images visuellement attrayantes est toujours tentant pour les concepteurs. Le problème survient lorsqu’ils ne compriment pas ces images avant de les télécharger dans le CMS. Cela est particulièrement vrai avec plusieurs sites Web de commerce électronique sur le Web. Selon les recherches récentes de Radware, les pages grossissent et environ 45% des 100 meilleurs sites de vente au détail ne se livrent pas à la compression d’image. Cela rend ces sites plus volumineux et, par conséquent, le temps de chargement est augmenté, mais en tant que concepteur, vous pouvez éviter le problème.

Créez des images de plus petite taille en utilisant un outil d’optimisation d’image approprié. En fait, de tels outils ne manquent pas sur le Web. Certains des plus notables que vous pouvez utiliser sont Dynamic Drive, Smush it et Riot. Si vous êtes un pro de Photoshop, vous pouvez également optimiser vous-même la taille de l’image. Utilisez une technique de compression intelligente et supprimez-la de toutes les métadonnées redondantes. La conversion de graphiques en PNG, d’images riches en couleurs en JPEG et d’images animées en GIF fait également l’affaire.

Préparé pour les cas extrêmes

Lorsque vous commencez à concevoir, vous devez avoir remarqué que vous êtes tenté de concevoir des pages plus faciles. Au moins, cela vous permet de montrer quelque chose à vos parties prenantes. Cela peut sembler agréable à première vue, mais si vous concentrez vos efforts sur les scénarios les plus difficiles, au début, vous obtiendrez un bon résultat.

Par exemple, une page Web contenant des articles, des blogs et des communiqués de presse. Il doit aussi avoir un titre. Maintenant, que se passera-t-il si l’espace de titre que vous avez pensé afficher "Conseils de conception de sites Web réactifs" doit afficher un titre "10 conseils et techniques essentiels pour une conception de site Web réactif réussie" ? Maintenant, c’est un cas extrême.

Un effort comme celui ci-dessus pour optimiser les performances de votre site Web réactif semble invisible. Cependant, ces efforts donnent de bons résultats avec des utilisateurs heureux et satisfaits. Vous pouvez vous aider de divers outils tels que les outils Pingdom qui peuvent vous permettre de surveiller sans effort le temps de chargement de votre site Web réactif. Ne sautez pas l’aspect vital des tests pour vous assurer que votre site Web réactif fonctionne comme prévu. Testez-le sur autant d’appareils réels que possible.

Vous pouvez également utiliser des ressources telles que Screenfly qui vous permettent de tester votre site Web sur plusieurs résolutions d’écran. Vous pouvez affirmer que toutes ces stratégies nécessitent beaucoup de temps, mais encore une fois, il faut suer fort pour en récolter les bénéfices. De nos jours, créer un site web responsive avec une performance responsive est essentiel, d’autant plus que Google note les sites en fonction de leurs performances. Si vous êtes un concepteur ou un développeur, ne vous limitez pas à l’une des meilleures pratiques ci-dessus. Vous devriez rechercher plus de solutions et vous efforcer de fournir un site Web présentant des performances réactives.

Source d’enregistrement: instantshift.com

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More