Une conception réactive ne suffit pas, nous avons besoin de performances réactives

Récemment, j'ai rencontré de nombreux sites Web réactifs avec de nombreux problèmes de performances. Sur la plupart d'entre eux, les problèmes sont si évidents qu'ils sont presque inutiles sur autre chose que la dernière génération de smartphones. Considérant le fait que la réactivité en tant que concept vise à atteindre un public plus large, cela semble plutôt contre-productif.

Le plus grand contributeur à ce problème est le paradigme de conception qui prévaut toujours sur le bureau. Penser du point de vue du mobile d'abord semble résoudre le problème, mais cela ne garantit pas à lui seul des performances satisfaisantes. Nous semblons tous beaucoup trop compter sur une dégradation plus ou moins gracieuse. Nous nous appuyons sur des cales et des polyfills pour activer les fonctionnalités manquantes. Nous nous appuyons sur les bibliothèques pour permettre un développement rapide et pour assurer notre soutien lorsque la compatibilité du navigateur est un problème.

"Pourquoi s'inquiéter?" vous pourriez demander. "La plupart de nos visiteurs ont des smartphones très performants exécutant leurs dernières versions de système d'exploitation. Ils peuvent gérer nos sites. Les analyses nous le disent.

Je suis désolé pour l'argument de l'homme de paille, mais je pense qu'il mérite de dire à haute voix que les personnes qui peuvent utiliser votre site seront la majorité de vos utilisateurs. Si vous ne voyez pas Android 2.3 dans vos analyses, cela signifie-t-il qu'aucun utilisateur n'utilise ces appareils ? Ou cela signifie-t-il que votre site n'a rien à offrir à ces utilisateurs ? Considérez que de nombreux appareils de cette génération sont encore sur les étagères, achetés neufs même aujourd'hui. Vous ne devriez pas le rejeter d'emblée comme une technologie d'antan.

Par conséquent, je voudrais parler des cas idéaux et des objectifs réels du développement Web. Et sur les pratiques et les paradigmes qui nous rapprochent de ces objectifs.

Paradigme de conception Brick-First

Une part importante des ventes annuelles de téléphones est toujours constituée de téléphones polyvalents. Une partie encore plus importante de la population n'achète pas de téléphones chaque année, mais possède néanmoins un appareil compatible avec le Web. Ajoutez à ces chiffres les smartphones de dernière génération encore utilisés, ajoutez les Kindles et autres appareils semi-capables du Web (appareils WAP, téléviseurs, grille-pain, t-shirts et briques). Additionnez-les tous et vous pourriez atteindre une somme stupéfiante.

Considérez les cas d'utilisation pour ce public. Ils ne liront pas de longs articles, ne navigueront pas et ne rechercheront pas sur leurs appareils. Mais ils peuvent vivre l'horreur d'essayer de taper une URL sur le clavier numérique et de naviguer dans la page à l'aide des touches directionnelles pour accéder à un numéro de téléphone ou de revérifier une adresse à la volée.

Dans quelle mesure est-il difficile pour nous de mettre en œuvre une disposition sous-mobile d'abord qui ne fournira que ces informations aux appareils en dessous d'un certain seuil de capacités et de performances ?

Amélioration gracieuse

Avec la dégradation gracieuse comme meilleure pratique minimale, nous avons créé un principe fourre-tout qui (dans une certaine mesure) empêche de penser au-delà. Une fois la dégradation gracieuse en place, nous pouvons certainement dire que notre travail est fait, et bien fait. De plus en plus souvent, nous n'avons même pas besoin d'y penser car il est déjà couvert par les différents frameworks et bibliothèques utilisés. Et enfin, les polyfills et les cales éliminent complètement le besoin de dégradation des fonctionnalités dans certains cas.

Au fur et à mesure que cette fonctionnalité devient de plus en plus disponible, la nécessité d'y penser (et encore moins de la dépasser) devient de plus en plus éloignée.

Du point de vue de cet article, il pourrait être décomposé comme ceci:

Dégradation disgracieuse : si une fonctionnalité n'est pas facilement disponible, la mise en œuvre échoue de telle manière qu'elle devient inutilisable ou utilisable d'une manière prohibitive et peu pratique.

Dégradation gracieuse : si une fonctionnalité n'est pas facilement disponible, elle échoue d'une manière qui permet toujours une utilisation acceptable.

Amélioration peu gracieuse : si la fonctionnalité n'est pas facilement disponible, elle est émulée par un polyfill ou un shim.

Voilà, problème résolu.

Eh bien, à moins que vous ne considériez les performances de ces mêmes appareils bas de gamme.

N'ayant pas la puissance de traitement et les capacités de données de leurs jeunes frères et sœurs, on leur demande de porter une charge beaucoup plus importante. Prendre les polyfills comme solution crée l'illusion que toutes les fonctionnalités modernes sont désormais disponibles sur tous les appareils et peuvent être utilisées sans souci.

Et donc vous implémentez modernizr et polyfill tout au cas où. L'appareil le moins compétent finit par charger la plus grande quantité de données et effectuer la plus grande quantité de traitement. Assurant ainsi la "meilleure" expérience utilisateur final.

L'idée d'une amélioration gracieuse inverserait le concept en commençant par les exigences de fonctionnalités les plus basses et en chargeant les mises à niveau jusqu'à ce que l'équilibre performances-utilisabilité soit optimal en fonction des capacités de l'appareil. Ainsi, le trafic de données et les exigences de traitement seraient déplacés vers les appareils les mieux adaptés pour les gérer.

Bien sûr, pour le moment, le concept est d'une complexité prohibitive : il n'est pas pris en charge par la plupart des frameworks et des bibliothèques, il n'est généralement pas discuté, et les références à de telles pratiques sont rares, éloignées et localisées aux micro-fonctionnalités. Mais à un moment donné, c'était comme ça avec tous les concepts et fonctionnalités.

C'est possible, mais faut-il ?

Une autre bonne pratique en matière de développement Web consiste à vérifier si une fonctionnalité est disponible sur un appareil avant de l'activer.

Cependant, tenez compte du fait que vous pouvez installer la dernière version de Google Chrome sur votre téléphone Android vieux de plusieurs années, et il prétendra qu'il peut exécuter des animations CSS, WebGL, des effets de parallaxe d'arrière-plan et de nombreuses autres fonctionnalités. Mais c'est vraiment, vraiment , impossible. À tel point que le navigateur plantera et que l'ensemble de l'appareil ne répondra plus à un point tel qu'il devra être redémarré pour reprendre le contrôle.

Ce problème a récemment commencé à affecter les applications Android de manière importante (du point de vue de l'utilisateur). L'une des dégradations les plus notables dans ce sens a affecté la mise à niveau de l'application Google Talk/Hangouts qui a transformé leur service de l'application de chat la plus légère disponible en une application presque inutilisable en raison de problèmes de performances sur les appareils plus anciens. (Juste pour souligner une fois de plus ce point : "plus ancien" ici signifie que vous pouvez toujours l'acheter dans le commerce, tout neuf dans presque tous les magasins). Le même problème a affecté l'application YouTube et l'application Twitter (selon mon expérience) et apparemment beaucoup d'autres.

Alors, prenez un moment à un moment donné de votre phase de planification pour évaluer la valeur d'une fonctionnalité de base haute performance par rapport à un maquillage de pointe. Ou au moins, laissez la dernière génération de votre application/service/contenu disponible sous une forme ou une autre pour les utilisateurs hérités. En parlant de quoi…

Laissez les utilisateurs se retirer de Bleeding Edge

Vous êtes-vous déjà retrouvé à essayer d'utiliser Gmail à partir d'un ancien appareil ou avec une mauvaise connexion ? Ce lien "charger le code HTML de base" est certainement utile.

Pourquoi votre vitrine en ligne de pointe, réactive, animée et tactile n'a-t-elle pas cette fonctionnalité ?

Pensez-y : vous avez demandé qu'il soit réactif afin de pouvoir toucher davantage de clients potentiels. Vous l'avez fait à la pointe de la technologie pour laisser la meilleure première impression. Et par conséquent, moins de clients potentiels peuvent accéder même aux informations de base sur vous et vos services. Si l'amélioration gracieuse est un concept trop coûteux pour vous, pourquoi ne pas au moins offrir à vos visiteurs la possibilité d'accéder à une version texte uniquement de votre contenu si la version "WOW" est trop pour leurs appareils.

Avez-vous vraiment besoin de toute la bibliothèque ?

Enfin, la dernière pratique exemplaire que j'aimerais voir poussée un peu au-delà de la norme est « utilisez-la ou perdez-la ». Garder une trace des bibliothèques et des modules qui sont réellement utilisés et les inclure uniquement est parfois fastidieux, mais garder tout votre ensemble d'outils sur chaque page est tout simplement bâclé.

Récemment, j'ai commencé à suivre la quantité de fonctionnalités que j'utilise réellement une fois que j'ai inclus une bibliothèque. Et l'outil que j'utilise le plus souvent est jQuery. Souvent, je constate que je n'ai utilisé qu'une ou deux fonctionnalités (telles que $.extend ou $.ready), ou pire encore, que je l'ai utilisé uniquement pour obtenir des éléments par classe ou ID. Parfois je le laisse comme ça, d'autres fois je repasse par le code pour supprimer ou découpler la dépendance.

Ne serait-il pas intéressant si vous pouviez automatiquement analyser quoi et quelle quantité d'une bibliothèque a fini par être utilisée et perdre du poids en fonction des résultats ?

De nombreuses bibliothèques et applications offrent la possibilité de personnaliser le chargement avant de commencer à l'utiliser. Mais je continue d'avoir le sentiment qu'il ne devrait pas être trop hors de notre portée de standardiser une architecture de construction automatisée « à utiliser ou à perdre » dans nos bibliothèques.

J'ai une allergie à l'approche « tout inclure ». Mais l'utiliser en conjonction avec une telle fonctionnalité pourrait transformer l'approche en quelque chose de similaire à une carte de prototypage : un outil de développement trop flexible qui est réduit non seulement dans la syntaxe, mais dans la fonctionnalité elle-même.

Ce qui serait nécessaire est une version de développement uniquement de la bibliothèque qui, via un test unitaire des fonctionnalités dépendantes, permettrait de tracer les fonctionnalités utilisées et de générer la dépendance minimale ou au moins l'échelle d'utilisation (comme demander si j'ai inclus jQuery pour 8 % de sa fonctionnalité soit 80%). La sortie de dépendance pourrait ensuite être utilisée pour sélectionner, agréger et minimiser la sortie pour la production.

Mais que puis-je faire à ce sujet ?

Tout d'abord, engagez le problème . Pensez-y, discutez-en avec vos pairs et essayez de repérer le problème dans des scénarios réels.

Essaye le. Déterrez ce téléphone de dernière génération que vous avez caché quelque part dans un tiroir. Essayez de l'utiliser sur vos propres sites Web et vérifiez si le contenu est même utilisable à distance. Allez rendre visite à des parents en retard dans le pays et essayez d'être un évangéliste technologique pour eux. Voyez si leur retard dans l'adoption de la technologie est réellement facilité par des problèmes d'accessibilité.

Si vous êtes un acheteur qui commande un site Web, assurez-vous de demander (au moins) un support de bas niveau sur ce problème. N'oubliez pas : l'objectif n'est pas de créer un portage complet de toutes vos fonctionnalités vers des appareils de bas niveau. Tout ce qui est demandé, c'est que ces utilisateurs obtiennent vos informations de contact au lieu que leur appareil plante.

Mettez de côté des ressources réelles pour cela : la solution la plus simple au problème ne devrait pas prendre plus d'un jour ou deux et une réflexion prospective. Gardez à l'esprit les raisons les plus élémentaires pour créer le site Web en premier lieu (sans parler de la création d'un site réactif).

Si vous êtes un développeur de packages travaillant sur une bibliothèque, un framework, un bundle ou tout autre logiciel intégrable : vous êtes celui qui peut faire le plus de différence ici. Si vous pouvez faciliter ou intégrer ces concepts dans votre plate-forme, vous affecterez l'ensemble du paysage du développement Web. Si vous l'intégrez dans la conception de votre emballage, faites-le moi savoir et j'évangéliserai pour vous.

Et enfin, **si vous êtes un développeur ou un designer**, ne vous arrêtez pas aux meilleures pratiques. Essayez toujours de regarder un peu au-delà de cet horizon. Le travail acharné repose sur vous pour promouvoir ces concepts que personne n'a encore demandés, qui ne sont ni pris en charge ni documentés au profit de vos clients et utilisateurs.

En fin de compte, si vous voulez entendre quelqu'un parler de cela pendant des heures et vous retrouver près de Zagreb, faites-le moi savoir. On pourrait aller prendre une tasse de café.