Retour sur Paris Web 2017

Jeudi 5 et vendredi 6 octobre nous étions à Paris Web, « l’événement des gens qui font un web de qualité » pour 2 jours de conférences. Voici un résumé de quelques conférences que j’ai pu voir.

La revue de code (bienveillante)

Points clés :

Nous faisons toujours des erreurs même après 10 ans, il faut être indulgent.
Le code appartient à tous, nous sommes tous responsables de sa maintenance.
Ecrire des fonctions les plus simples possibles et qui font le moins d’actions possible rend la lecture et maintenance plus simples.
Une Pull Request ne doit changer qu’une seule chose et avoir une et une seule raison d’exister.
Commenter le code des autres développeurs sur le fond et non la forme (indentations…) car cela n’apporte rien de constructif.
Poser des questions sur le contexte pour comprendre.
Ne pas critiquer mais proposer. Si nous n’avons pas de meilleure solution, s’abstenir de simplement critiquer sans alternative.
Toujours justifier ses commentaires, et autrement que "parce que c'est une bonne pratique" !
Faire des revues fréquentes empêche un coin de l’application de rester mal codé, non maintenable, car il sera vu par les autres développeurs qui se diront que si cela reste ainsi alors ils peuvent eux aussi se permettre un niveau d’exigence plus faible sur leur code, ce qui contaminera toute l’application.

Les slides de la conférence se trouvent ici.

CSS, tu peux pas test !

En résumé : le CSS, c’est pas simple !
Il y a une infinité de sélecteurs CSS possibles par élément HTML.
Il y a une infinité d'éléments HTML possibles par sélecteur CSS.
Il y a des propriétés héritées des nœuds HTML parents.
Il y a une infinité de configurations visiteurs possibles : appareils, OS, navigateurs, extensions, etc. qui peuvent jouer sur le rendu du CSS.
Il y a souvent des gens qui ne savent pas coder en CSS mais qui produisent du CSS sur les projets.

Tester du CSS : très difficile à faire avec des pull-request car très complexe de dire si un code marchera ou pas simplement en lisant le CSS :

Comment tester du code CSS :

Mais ce n'est pas utilisable :

  • Sur tous les navigateurs
  • Sur du contenu dynamique
  • Sur des pages entières

Mais ces tests sont très longs !

  • Utiliser des linters et formateurs CSS et Scss :

Et enfin, aimez vos intégrateurs, car c’est pas facile tous les jours !

Les slides de la conférence se trouvent ici.

Améliorer la Performance : entre réalité et perception

53% des utilisateurs quittent un site après 3 secondes d’attente.

Cela représente autant de chiffre d’affaire perdu pour les sites marchands, les sites hébergeant des publicités, et des visiteurs qui ne reviendront plus si le site est trop lent.
Il est donc crucial d’augmenter la rapidité d’une part, mais aussi de garder le visiteur, même si la rapidité n’est pas optimale.
Il faut différencier le temps d’attente objectif (qui se mesure précisément avec une montre) et le temps d’attente psychologique.

Quelques études ont permis de définir (de façon approximative) la perception des délais :

  • de 0,1 à 0,2s : aucun délai n’est ressenti par la personne, c’est le bon interval pour placer des animations très courtes qui donnent une impression de fluidité dans les transitions.
  • de 0,5 à 1s : il s’agit d’un délai immédiat proche d’une réponse d’humain à humain, un échange rapide où aucun indice ne laisse à penser qu’il y a une attente.
  • de 2 à 5s : c’est le délai optimal pour une tâche, une activité, dont on attend une réponse. Le sentiment qu’une action à eu lieu et que l’attente aura été raisonnable.
  • de 5 à 10s : c’est la durée maximale d’attention d’un utilisateur·rice pour une tâche donnée.

Etape 1 : il faut d’abord réduire au maximum le temps d’attente objectif en jouant sur :

  • Choix du serveur web et sa version
  • Choix du langage
  • Optimisation des bases de données
  • HTTP 2
  • Compression des images
  • Compression du HTML
  • Compression et concaténation du CSS
  • Compression et concaténation du JS
  • Gestion du cache et des dates d’expiration des ressources
  • Polices d’icônes plutôt qu’images
  • Lazy loading
  • local/sessionStorage
  • CDN Géolocalisé
  • CSS Critical path
  • Mobile First…

Etape 2 : diminuer le temps d’attente psychologique

C’est faire croire à l’utilisateur qu’il n’attend pas (ou que ce n’est pas long en fait).
Voici différentes façons d’y arriver.

Indiquer l’attente avec :

  • un spinner
  • une barre de progression
  • un message d’attente
  • un message expliquant pourquoi c’est long

Afficher du faux contenu ayant un gabarit identique au vrai contenu et qui sera remplacé par celui-ci une fois chargé (à la manière de Facebook ou Slack quand l'affichage prend du temps).

Afficher une publicité pour le site ou un site partenaire.

Proposer un jeu en attendant.

Faire des tâches de fond de façon cachée : anticiper le clique probable sur un bouton et lancer le calcul ou la requête qui suivra en tâche de fond. Ainsi quand la personne clique, le résultat est prêt immédiatement.

Indiquer à l’utilisateur que son action a bien fonctionné, que l’opération qu’il a faite a bien réussie, même si ce n’est pas encore le cas (mais selon toute vraisemblance, ce sera un succès). Et dans le cas peu probable où l’opération échoue, l’avertir de l’erreur.

Tout ceci permet à l’utilisateur d’avoir moins l’impression d’attendre et donc de le conserver sur le site web, ce qui est tout l’enjeu.

ATTENTION :
Dans certains cas, un délai trop court peut être néfaste et donner une mauvaise image. Par exemple si nous demandons un audit de sécurité complet de notre site et que nous avons la réponse en moins de 0,5s, cela paraîtra suspect, on pensera que tout n'a pas pu être analysé si vite et nous n'aurons pas une image très professionnelle du service.

Les slides de la conférence se trouvent ici.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.