Université Claude Bernard Lyon 1 - M2 TIW - Intergiciels et Services

TP Web Performance

Objectifs pédagogiques du TP

• Utiliser les outils d'analyse de performance des applications Web
• Mettre en oeuvre un processus d'optimisation pour une application

Outils

• Navigateur Chrome / Chromium et outils de développement Web (Performance / Timeline)
• Web Performance Timing API (côté client)
• Application en ligne : WebPageTest

À faire avant de débuter le TP : désactiver le cache (jusqu'à instruction contraire) et les plugins de blocage de contenus (Adblock, Ghostery...) de votre navigateur.

Rendu du TP

Ce TP est à rendre pour le samedi 4 février 2017 à 23h59 sous forme de :

• Réponses à ce questionnaire Spiral. D'une séance à l'autre, vous pouvez récupérer vos réponses au questionnaire à l'aide du numéro de dossier qui vous est fourni par Spiral quand vous validez le questionnaire ; n'oubliez pas de le noter.
• Rapport (PDF) qui synthétise vos observations et dont le contenu demandé est détaillé dans l'énoncé du TP. Vous structurerez ce rapport en suivant les titres de cet énoncé.
• Projet forge contenant le résultat de vos optimisations (à partir de la question 2)

1. Analyse d'une application Web

Dans un premier temps, vous allez réaliser l'analyse d'une application Web existante : celle de l'Université Claude Bernard Lyon 1.

Analyse avec Chrome Dev Tools

Ouvrez les Dev Tools de Chrome (onglets Network, puis Performance ou Timeline, selon les versions). Lancez le chargement de l'application et identifiez les différents temps indiqués :

• récupération de la page HTML (transaction HTTP)
• récupération de la / des feuille(s) de style nécessaires à la composition du CSSDOM (transaction(s) HTTP)
• fin du premier rendu (de la page blanche au premier contenu)
• fin du rendu de l'app shell (cadre applicatif sans contenu)
• fin du chemin critique de rendu (cf. cours)
• durée totale du chargement

Utilisation des APIs de performance

À l'aide du document Performance Timing Primer et de la spec Navigation Timing Level 1 et Level 2, déterminez (et exécutez dans la console) une formule qui vous permettra d'obtenir automatiquement les temps de récupération de la page HTML et de création du DOM.
Aide : le comptage du temps commence à navigationStart.

À l'aide de la spec Performance Timeline Level 1 et Level 2, créez des scripts (et exécutez-les dans la console) pour obtenir automatiquement temps de chargement des ressources nécessaires à la création du CSSDOM, de l'app shell et du CRP.
Aide : en fonction de vos observations de la question précédente, vous devrez identifier les ressources qui interviennent pour chacun de ces éléments.

Afin de diminuer l'impact des fluctuations du réseau, créez un script qui lance 10 fois les mesures précédentes, les stocke, et établit une moyenne sur les 8 médianes. Faites afficher à ce script les 5 résultats séparés par des virgules (CSV) ou des tabulations.

Pour automatiser les questions suivantes, après chaque série de mesure, vous stockerez les données obtenues dans votre tableur préféré.

Modification du contexte client

Renouvelez maintenant vos mesures en simulant :

1. un réseau 3G moyen (network throttling).
2. un appareil plus ancien : CPU ralenti 2x (CPU throttling)
3. les deux types de ralentissements précédents à la fois

Analyse avec WebPageTest

Allez sur le site WebPageTest.

• Lancez le chargement de la page d'accueil de l'université, sans simuler de perturbations, mais à partir de plusieurs endroits du globe (Amérique, Asie...). Notez les valeurs des temps correspondants.
• Observez l'ordre de chargement des ressources et comparez avec celui de votre navigateur.
• Dans l'onglet "Performance Review", observez ce qui s'est bien passé, et ce qui pourrait être amélioré, pour vous en souvenir à la question suivante...
• Retournez à la page d'accueil de WebPageTest. Dans l'onglet "Visual Comparison", comparez le démarrage des pages d'accueil des universités Lyon 1 et Lyon 2. Si vous deviez donner un conseil aux Webmasters de votre université au sujet de l'optimisation du chemin critique de rendu, quel serait-il ?

2. Optimisation d'une application Web

À l'aide du cours et des observations que vous avez faites à la question précédente, vous allez améliorer une application existante. L'application en question est l'une des premières versions du site du département info. Elle est à peu près fonctionnelle, mais pas encore optimisée. Vous trouverez cette application dans ce projet forge. Quelques informations au sujet de cette application :

• Il s'agit d'une application en PHP, en lien avec d'autres services de l'université (CAS, offre de formation, actualités...)
• Elle vous est fournie avec un Dockerfile, pour vous simplifier la tâche de déploiement. Toutefois, vous pouvez la faire tourner directement sur votre machine, si vous disposez d'un serveur web et d'un interpréteur PHP. Dans ce cas, il ne faut pas renommer le répertoire "COMMUN".
• Il est possible (non testé) que l'appel aux autres services ne fonctionne pas depuis l'extérieur de la fac.

Dans cette partie, vous essayerez - autant que possible - de réaliser toutes les mesures dans les mêmes conditions (machines cliente et serveur). Par conséquent, lisez les instructions jusqu'au bout avant de déployer l'application.

Clonez cette application et initialisez un projet forge dans lequel vous pousserez vos modifications. À la racine du projet forge, ajoutez le fichier JS qui contient votre script de mesure de performances.

Préambule

Chemin critique de rendu

1. Déterminez la tâche principale que l'utilisateur veut pouvoir effectuer en arrivant sur l'application
2. Déterminez la quantité minimale de ressources nécessaires pour effectuer cette tâche
3. Refactorez votre front pour que ces ressources soient chargées et affichées en premier et pour fixer la dimension de l'image sur la page
4. Faites en sorte que les ressources secondaires soient récupérées de façon asynchrone, une fois que la page a été rendue

Optimisation par ressource

Vous allez maintenant optimiser les ressources en fonction de leurs types. En fonction des contenus et de la structure de votre application, essayez certaines des optimisations suivantes, et consignez les résultats dans votre rapport :

Feuilles de style

• le cas échéant, supprimez les directives @import de la feuille de style
• éventuellement, répartissez les directives de style entre une feuille externe (commune à votre application) et une feuille incluse dans la page HTML (pour les styles spécifiques à l'interface de chat)
• "minifiez" le CSS en utilisant un outil en ligne

Scripts et fichiers statiques

• commencez par optimiser votre code en appliquant quelques bonnes pratiques "simples" comme celles listées ici
• analysez le cycle de vie de vos différents éléments JS (fonctions, objets...) et les tâches auxquelles ils correspondent
• si certaines parties doivent être générées dynamiquement (et ne peuvent pas être stockées sous forme de fichiers statiques), séparez-les de ces fichiers, et considérez-les comme des donnes asynchrones (voir plus bas)
• groupez les éléments statiques similaires, en fonction des premières tâches pour lesquelles ils sont nécessaires, et "minifiez" chaque groupe
• dans la page HTML, mettez en place des mécanismes de chargement adaptés (async ou defer), et bien entendu, placez-les dans la page afin qu'ils se déclenchent aux bons moments

Données asynchrones générées dynamiquement

• comme précédemment, analysez le cycle de vie de vos données et à quels moments elles sont nécessaires au fonctionnement de l'application
• pour celles qui font partie de la tâche critique, forcez-en le chargement (en une seule transaction HTTP) dès le début de la lecture de la page
• groupez les autres en fonction des premières tâches pour lesquelles elles sont nécessaires, et faites en sorte que l'envoi de chaque groupe soit de taille aussi réduite que possible
• côté serveur, optimisez les processus de génération de ces données, par exemple en utilisant des variables intermédiaires pour pré-calculer ou mémoriser des valeurs, ou en diminuant la complexité de vos algorithmes
• faites en sorte que les scripts d'intégration de ces données au DOM ne perturbent pas le rafraîchissement de la page (voir ici)

Images

Enregistrez votre/vos image(s) :

• sous différents formats adaptés aux navigateurs (et mettez en place les mécanismes côté serveur permettant de servir l'image adaptée au client)
• sous différentes résolutions adaptées à la fenêtre du navigateur (et mettez en place les mécanismes côté client permettant de requêter l'image de taille correspondante)

Remarque : il ne vous est pas demandé de modifier le type de sérialisation (XML / JSON) des données transférées de façon asynchrone.

Optimisations des transactions réseau

À partir de cette question, ré-activez le cache navigateur.

• Pour tous les outils externes (jQuery, Bootstrap...), utilisez le chargement par CDN plutôt que de répliquer les bibliothèques côté serveur
• Vérifiez (et au besoin reconfigurez votre serveur) pour que tous les types de données qu'il envoie au client soient compressés
• Mettez en place les mécanismes nécessaires pour une gestion efficace du cache côté client

Optimisation du serveur

Actuellement, vous passez par un Apache / nginx muni d'un interprêteur PHP pour accéder aux contenus côté serveur. Ce n'est pourtant pas nécessaire de mettre en oeuvre toutes leurs mécaniques pour servir les fichiers statiques. Revenez aux fondamentaux et inspirez-vous du premier TP de MIF13 pour mettre un serveur nginx/Apache en front, qui sera capable de :

• servir rapidement les fichiers statiques
• mettre en place un cache pour les ressources dynamiques côté serveur
• rediriger les autres requêtes sur votre interprêteur PHP

Récapitulatif des instructions de rendu

Au final, votre rendu comportera les éléments ci-dessous.

Rapport

Projet forge

Questionnaire Spiral