01 — Consignes

Contexte

Un client vous confie un site vitrine existant. Il se plaint : « c'est lent, et sur mon portable ça rame après quelques secondes ». Votre mission n'est pas de le refaire, mais de le rendre rapide sans rien changer à ce qu'il voit.

Pour commencer : récupérer le site

Le site à optimiser est ici :

https://github.com/nico3807/R314-optimisation-site

Ne le clonez pas directement. Vous n'auriez pas le droit d'y pousser vos modifications, et vous ne pourriez pas le publier pour vos mesures. Passez par un fork, c'est-à-dire votre copie personnelle du dépôt :

1. Créez votre fork. Sur la page ci-dessus, bouton Fork en haut à droite, puis Create fork. Vous obtenez https://github.com/VOTRE-COMPTE/R314-optimisation-site.

2. Clonez votre fork — pas l'original :

git clone https://github.com/VOTRE-COMPTE/R314-optimisation-site.git
cd R314-optimisation-site

3. Publiez-le. Dans votre fork sur GitHub : Settings → Pages → Source : Deploy from a branch → main / (root) → Save. Une ou deux minutes plus tard, votre site est en ligne à l'adresse https://VOTRE-COMPTE.github.io/R314-optimisation-site/. Vous en aurez besoin pour les relevés PageSpeed Insights, qui n'analysent que des URL publiques.

4. Servez-le en local pour travailler. Ouvrir les fichiers en file:// fausse toutes les mesures réseau :

python3 -m http.server 8000
# puis http://localhost:8000

Travaillez ensuite normalement : modifiez, git commit, git push. Chaque poussée met votre site publié à jour, ce qui vous permet de remesurer.

Ce que vous devez produire

1. Un audit initial

Avant de modifier une seule ligne, vous devez savoir d'où vous partez. Sinon vous ne pourrez prouver aucun gain à la fin.

L'audit combine deux sources, et les deux sont obligatoires :

• les outils de développement du navigateur (« DevTools », intégrés à Chrome et à Edge), qui montrent le détail de ce qui se passe sur votre machine ;
• PageSpeed Insights, qui mesure le site déployé depuis les serveurs de Google, dans des conditions identiques pour tout le monde.

Les deux ne disent pas la même chose, et c'est précisément l'intérêt de les croiser.

Ce qui suit emploie les noms français des DevTools ; en anglais, Réseau = Network, Performances = Performance.

Ouvrir les outils

Retenez surtout le menu de commandes : DevTools ouverts, faites Ctrl+Maj+P et tapez le nom de ce que vous cherchez (Network, Performance, Lighthouse, Coverage). C'est plus rapide que de chercher l'onglet, et ça marche même quand un panneau est caché derrière le menu ».

Travaillez en navigation privée. Vos extensions injectent du code dans les pages et faussent tout.

a. L'onglet Réseau — qu'est-ce qui est téléchargé ?

Il liste chaque fichier demandé par la page : son poids, sa durée, son ordre d'arrivée. C'est l'outil qui répond à « pourquoi la page est-elle lourde ? ».

1. Onglet Réseau.
2. Cochez Désactiver le cache (Disable cache). Sans ça, vous mesurez votre cache et pas le site.
3. Rechargez avec Ctrl+Maj+R.
4. Cliquez sur l'en-tête de colonne Taille pour trier par poids décroissant.
5. Lisez la barre de statut, tout en bas : elle affiche le nombre de requêtes et le poids total transféré.

À rendre : une capture montrant le tableau trié et cette barre de total.

b. Lighthouse — une note et des pistes

Lighthouse charge la page dans des conditions simulées (réseau et processeur ralentis), puis produit un score sur 100 et une liste de problèmes classés par gain estimé. C'est votre point d'entrée : il ne trouve pas tout, mais ce qu'il trouve est fiable.

1. Menu de commandes → Lighthouse.
2. Catégorie Performance uniquement.
3. Mode Navigation, puis Analyser.

Lancez-le deux fois : une fois en profil Mobile, une fois en Desktop. Les deux ne ralentissent pas la machine de la même façon et ne simulent pas le même écran. Vous n'obtiendrez pas les mêmes résultats, et l'écart lui-même est une information — ce n'est pas un bug, c'est une piste.

Ne vous arrêtez pas au score : descendez jusqu'à Diagnostics, sous les opportunités. C'est la partie la plus utile du rapport.

À rendre : une capture par profil, en précisant lequel est lequel.

c. Le panneau Performances — qu'est-ce qui bloque ?

Le Réseau dit ce qui est téléchargé ; Performances dit ce que le navigateur fait de son processeur. C'est le seul outil qui montre le code en train de s'exécuter, et donc le seul qui permette de désigner une fonction coupable.

1. Onglet Performances.
2. Réglez CPU sur ralentissement ×4 (votre machine est bien plus rapide qu'un téléphone : sans ça, vous ne verrez rien).
3. Cliquez sur ⟳ (Démarrer le profilage et recharger la page), pas sur ●.
4. Laissez tourner au moins 20 secondes, en faisant défiler la page pendant ce temps.
5. Arrêtez.

Vous obtenez une frise. Les blocs rouges sont les moments où la page était figée. Cliquez sur l'un d'eux : le panneau du bas vous donne la fonction responsable et son fichier.

⚠️ Les 20 secondes ne sont pas arbitraires, et le scroll non plus. Tout ne se déclenche pas au chargement : certains comportements n'existent qu'en réaction à ce que fait l'utilisateur, d'autres n'apparaissent qu'après un certain temps de présence sur la page. Un enregistrement de 3 secondes sans interaction vous montrera une page saine, et vous passerez à côté d'une partie du sujet.

À rendre : une capture de la frise montrant les blocs rouges, et une capture de l'onglet Bottom-Up trié par temps.

d. PageSpeed Insights — le même audit, mais pas sur votre machine

👉 Analyser le site de référence — le lien est pré-rempli, il n'y a qu'à lancer.

Lighthouse dans les DevTools tourne sur votre ordinateur : un portable récent et une machine de salle TP ne donneront pas le même score pour le même site. PageSpeed Insights exécute le même moteur sur les serveurs de Google, avec un matériel et un débit simulés toujours identiques. Deux conséquences :

• vos relevés sont comparables avec ceux de vos camarades, et avec vos propres relevés d'il y a trois jours ;
• il lui faut une URL publique. localhost ne fonctionne pas. C'est donc l'outil du site déployé, jamais de votre copie locale.

Le lien ci-dessus ouvre directement l'analyse du site de référence. Pour analyser votre version, une fois vos corrections déployées, remplacez simplement l'adresse dans le champ en haut de la page PageSpeed Insights, ou utilisez l'adresse de votre propre publication :

https://pagespeed.web.dev/analysis?url=VOTRE_URL

Dans les deux cas, comptez une vingtaine de secondes d'analyse.

⚠️ Pour vos mesures « après », analysez bien votre site et non celui de référence. C'est l'erreur classique : on relance le lien pré-rempli, on retrouve les mêmes mauvais chiffres, et on croit que les corrections n'ont servi à rien.

Visite guidée du rapport

⚠️ Google réorganise cette interface régulièrement et les intitulés changent. Repérez les notions décrites ci-dessous plutôt que les mots exacts : elles, ne changent pas.

1. Les onglets Mobile et Ordinateur, tout en haut. Deux simulations distinctes : le profil mobile applique un processeur et un réseau nettement plus lents. Les deux sont à relever. Un écart important entre les deux onglets n'est pas une anomalie de l'outil, c'est un renseignement sur votre site.

2. Les données de terrain (« utilisateurs réels », rapport CrUX). Mesures collectées sur de vrais visiteurs de Chrome, sur une fenêtre glissante de 28 jours, exprimées au 75ᵉ centile — c'est-à-dire l'expérience des 25 % les moins bien servis, pas la moyenne.

Sur notre site, cette section sera absente, et c'est normal : il faut un trafic réel suffisant pour que Google dispose de données. Ne cherchez pas à la faire apparaître. Notez simplement dans votre rapport que l'audit repose donc entièrement sur les données de laboratoire — c'est une limite méthodologique réelle, et la signaler vous fait gagner des points.

3. Les données de laboratoire (Lighthouse). C'est le cœur du rapport, et la seule partie exploitable ici. Un test unique, dans des conditions simulées et reproductibles.

4. Le score de performance, l'anneau coloré de 0 à 100. Rouge en dessous de 50, orange de 50 à 89, vert à partir de 90. Ce n'est pas une mesure mais une moyenne pondérée de cinq métriques :

Retenez-en une chose : TBT, LCP et CLS font 80 % du score. Une page légère mais bloquée par du JavaScript sera mal notée, et c'est justifié.

(Ces pondérations sont celles des versions récentes de Lighthouse ; Google les a déjà fait évoluer et le fera encore. Vérifiez-les si l'écart avec votre score vous surprend.)

5. Les cinq métriques, affichées juste sous le score. Chacune avec sa valeur et sa pastille de couleur. C'est ici qu'il faut regarder, pas le score. Deux sites notés 45 peuvent avoir des problèmes totalement différents : l'un lourd, l'autre bloqué. Le score dit qu'il y a un problème, les métriques disent lequel.

6. La capture de la page, ou la pellicule de chargement. L'aspect de la page au fil du chargement. Très parlant pour comprendre le LCP et le CLS : vous voyez le moment où le contenu apparaît, et vous voyez les éléments sauter.

7. La liste des problèmes détectés — « Insights » puis « Diagnostics ». La partie la plus utile. Les Insights regroupent les pistes d'amélioration (chargement des images, requêtes bloquantes, affichage des polices, arbre des dépendances réseau…) ; les Diagnostics signalent des constats plus bruts, comme un poids réseau excessif. Chaque entrée est dépliable et indique souvent une économie estimée en secondes ou en kilo-octets.

Deux réflexes :

• Dépliez systématiquement. Le détail donne la liste exacte des fichiers en cause — c'est là que se trouve l'information, pas dans le titre.
• Traitez ces économies comme des estimations, pas comme des résultats. Elles sont calculées par un modèle. Votre rapport doit présenter des gains mesurés après correction, pas les prévisions de l'outil.

8. Les audits réussis, repliés en bas de liste. Dépliez-les au moins une fois : ils vous disent ce qui va déjà bien, ce qui évite de « corriger » quelque chose de correct.

9. Les autres catégories (Accessibilité, Bonnes pratiques, SEO). Hors périmètre de ce TP, qui porte sur la performance. Rien ne vous interdit de les regarder, et d'en glisser un mot en conclusion.

Précautions

• Le score varie d'un lancement à l'autre. Lancez l'analyse trois fois et gardez la valeur médiane. Un écart de quelques points entre deux essais ne signifie rien.
• Ne courez pas après le 100. L'objectif est de corriger des défauts réels et de le prouver, pas d'optimiser un chiffre.
• Relancez après chaque correction déployée. PSI mesure ce qui est en ligne : tant que vous n'avez pas publié, il analyse toujours l'ancienne version.

À rendre : une capture par profil (mobile et ordinateur), montrant le score et les cinq métriques, avant et après vos corrections.

Où mesurer

Les relevés de référence se font sur le site en ligne, pas sur votre copie locale : un serveur local ne compresse pas les fichiers, ce qui fausse tous les poids. La méthodologie détaille ce point, il est important.

C'est aussi la raison pour laquelle PageSpeed Insights (section d ci-dessus) fait partie des relevés obligatoires : il ne sait analyser qu'une URL publique, donc il mesure forcément le site dans ses conditions réelles.

Pour aller plus loin

• Documentation des DevTools : https://developer.chrome.com/docs/devtools/
• Liste des raccourcis : https://developer.chrome.com/docs/devtools/shortcuts

Le document méthodologie reprend chaque outil en détail, avec l'onglet Coverage, le protocole avant/après et les pièges de mesure.

2. Une liste de problèmes identifiés

Pour chaque problème trouvé, indiquez :

L'exemple ci-dessous est fictif : il illustre le niveau de détail attendu, il ne décrit pas un problème de ce site.

Une affirmation sans mesure ne vaut rien. « J'ai enlevé ça, c'est sûrement mieux » n'est pas un audit.

3. Le site corrigé

Un dépôt sera ouvert sur Moodle pour y déposer votre site corrigé, sous forme d'archive .zip.

L'archive contient le site complet et fonctionnel : il doit suffire de la décompresser et d'ouvrir le dossier dans un serveur local pour retrouver le site tel que vous l'avez rendu. Nommez-la nom-prenom.zip.

N'y mettez pas les fichiers de travail : pas de node_modules, pas de .DS_Store, pas de dossier .git, pas d'images sources non utilisées. Un rendu propre fait partie du travail.

Indiquez dans votre rapport les deux adresses de votre fork : celle du dépôt et celle du site publié (voir « Pour commencer » plus haut). La première permet de lire votre historique de commits, la seconde de vérifier vos mesures.

Travaillez donc sur votre fork avec des commits explicites : un commit = une optimisation. L'archive déposée sur Moodle est le rendu, l'historique du fork montre la démarche.

4. Un rapport avant/après

3 à 5 pages, avec un tableau comparatif chiffré sur les six indicateurs du README, et pour chaque optimisation majeure : le problème, la correction, le gain mesuré.

Contraintes

1. Iso-rendu. Le site doit être visuellement et fonctionnellement identique. Comparez avec des captures avant/après.
2. Pas d'outil de build. Le site est hébergé sur GitHub Pages en statique. Pas de Webpack, pas de Vite, pas de npm. Tout doit rester servable tel quel. Vous pouvez en revanche utiliser des outils hors ligne pour préparer vos fichiers (compresser des images, minifier du CSS à la main ou via un service en ligne).
3. Pas de CDN externe supplémentaire. L'idée est de réduire les dépendances, pas d'en ajouter.
4. Hébergement statique. Vous n'avez pas la main sur les en-têtes HTTP (Cache-Control, compression, HTTP/2 push). Si une optimisation en dépendrait, mentionnez-la dans le rapport en expliquant ce que vous feriez avec un vrai serveur — c'est valorisé, même si vous ne pouvez pas l'appliquer ici.

Déroulé conseillé

L'ordre compte. Commencez par le poids des ressources : c'est là que se trouve le gain le plus spectaculaire pour le moins d'effort, et ça nettoie les mesures pour la suite.

Avertissement

Ce site contient plusieurs pièges de difficulté croissante. Certains sautent aux yeux, d'autres demandent de savoir lire un profil d'exécution, et au moins un ne se manifeste que dans certaines conditions (taille d'écran, durée de la visite). Si vos mesures vous semblent contradictoires d'un essai à l'autre, ce n'est probablement pas une erreur de votre part : c'est un indice.