Audit - Geoffrey013/oc-p8-Take-existing-project-over GitHub Wiki

Un audit du site a été réalisé grâce aux outils de développement de google chrome (onglet Network, Performance et Audit). Afin de bien mettre en évidence les différentes problématiques, le test sera simulé sur un CPU de faible performance.

Résultats : 41/100

• Premier rendu : 3,54s
• application interactive pour l’utilisateur : 10s => bien au-dessus de la fenêtre des 5s recommandées pour le confort utilisateur.

L’utilisation de l’application et notamment lors des évènements, montre une certaine baisse des FPS, surtout via des supports utilisant de faibles CPU. Cet audit met en valeur plusieurs facteurs responsables de ce temps d’attente et donc une expérience utilisateur ralentie.

1) Réduction du nombre de requêtes

Lors du démarrage de l’application, nous apercevons un très grand nombre de requêtes, aussi bien de script, que d’images etc… La réduction de ce nombre est donc à envisager pour réduire ce temps de chargement. Il serait alors intéressant de regrouper les scripts javascript dans une seul fichier bundle.js qui sera minifié et uglifié. Il en est de même pour les fichiers CSS, à rassembler dans un fichier unique minifié et uglifié. De plus il serait préférable de compresser ces différents fichiers pour minimiser leur poids sur le réseau. De plus, un certain nombre de requêtes sont effectuées pour récupérer des images png (top_new_window.png, info.png, top_sync.png…). Des formats d’images mieux adaptées serait une première solution (jpeg 2000 etc..) et offrirait une meilleure compression et donc des téléchargements plus rapides. L’utilisation d’un CDN (content delivery network) pour stocker ces fichiers permettrait un gain de temps lors des requêtes, les serveurs étant optimiser pour. D’autre part, la mise en place d’un « SPRITE » qui regrouperait l’ensemble des images dans un seul fichier permettrait d’effectuer une unique requête et de les exploiter via le background-position.

2) Requêtes dans l’entête du site

Le site possède de nombreux scripts présents dans l’entête. L’attribut « async » sur la plupart permettra leur exécution uniquement lorsqu’ils seront téléchargés (fonctionnement asynchrone) afin de ne pas bloquer le rendu HTML pendant ce temps. Cependant nous apercevons que certains ne possèdent pas cet attribut, notamment les pubs google, les boutons réseaux sociaux, qui entraînent donc une mise en attente du moteur HTML/CSS lors de leur chargement. 

3) Récupération des icônes réseaux sociaux

L’utilisation d’iframe pourrait provoquer des problèmes de compatibilité avec certains navigateurs. Afin d’éviter tout désagrément il serait préférable d’envisager la solution javaScript, simple lien cliquable et script asynchrone bien plus léger, qui sera supportée par l’ensemble des navigateurs populaires.

4) Utilisation de librairie javaScript

L’application utilise des librairies permettant d'interagir avec le DOM comme jQuery ou jQuery UI. On peut d'un part noter que le poids du fichier jQuery UI n'est pas optimisé (non minifié). D'autre part, nous avons également remarqué un pic d’activité assez long du CPU lors de simples événements de type click (todo done), qui pourrait provoquer une baisse des FPS et donc de fluidité pour l’utilisateur. Cet effet est encore plus visible lorsque le support de navigation possède un CPU avec une faible capacité (smartphones). Il serait préférable d’utiliser l'API native de Javascript et non une librairie pour gérer ces types d'événements.