02 — Méthodologie : mesurer avant de corriger

La règle est simple : une optimisation non mesurée n'est pas une optimisation, c'est une conviction.

Les six indicateurs

FCP et LCP racontent le chargement. TBT raconte le JavaScript. CLS raconte la mise en page. Les trois problèmes sont indépendants : on peut avoir un site léger et injouable, ou lourd et fluide.

Outil 1 — L'onglet Réseau

C'est le premier réflexe, et souvent le plus rentable.

1. DevTools → Réseau
2. Cochez Désactiver le cache (sinon vous mesurez votre cache, pas le site)
3. Rechargez avec Ctrl+Maj+R
4. Triez par la colonne Taille, décroissant

Ce que vous cherchez :

• Les plus grosses ressources. Sont-elles nécessaires ? À cette taille ?
• Les doublons. Deux lignes pour un même fichier = quelque chose ne va pas.
• Les 404. Chaque 404 coûte un aller-retour complet pour rien.
• Les ressources que vous ne voyez pas à l'écran. Si un fichier est téléchargé mais que vous n'arrivez pas à dire où il s'affiche, creusez.
• La colonne Cascade (waterfall). Les barres en escalier signalent des ressources qui s'attendent les unes les autres : c'est la chaîne critique.

Lire une chaîne critique

Une ressource ne peut être demandée que si le navigateur sait qu'elle existe. Si A doit être téléchargé et lu pour découvrir B, et B pour découvrir C, vous payez trois allers-retours en série au lieu d'un seul en parallèle.

Lighthouse a un audit dédié : « Éviter l'enchaînement de requêtes critiques ». Ouvrez-le, il vous dessine l'arbre.

Outil 2 — Lighthouse

DevTools → Lighthouse → catégorie Performance.

Précautions, sans lesquelles vos chiffres ne veulent rien dire :

• Fenêtre de navigation privée, pour neutraliser les extensions ;
• lancez-le 3 fois et gardez la médiane, les résultats varient — et parfois énormément. Sur ce site, trois lancements consécutifs en profil Ordinateur ont donné des scores de 62, 37 et 36, le TBT passant de 68 ms à 672 ms pour exactement la même page. Un relevé unique vous aurait fait croire à un site deux fois meilleur qu'il n'est. Et sur six lancements en profil Mobile, le TBT s'est logé soit autour de 800 ms, soit autour de 2 900 ms, sans valeur intermédiaire — deux relevés seulement peuvent donc tomber du même côté et vous induire durablement en erreur. Conclusion pratique : le poids et le nombre de requêtes sont fiables au kilo-octet près, les temps beaucoup moins. Le LCP fait exception, très stable ici. Raisonnez en ordres de grandeur sur les autres ;
• testez mobile ET desktop. Les deux profils n'appliquent ni la même taille d'écran ni la même limitation de CPU et de réseau. Un problème visible sur l'un peut être totalement absent de l'autre ;
• n'ouvrez pas le widget ?perf=1 pendant un audit Lighthouse.

Descendez systématiquement jusqu'à la section Diagnostics, sous les opportunités. C'est là que se trouvent les informations les plus utiles.

Outil 3 — Le panneau Performance

C'est l'outil qui distingue un étudiant qui a compris d'un étudiant qui a deviné.

1. DevTools → Performance
2. Réglez CPU : ralentissement ×4 (votre machine est plus rapide qu'un téléphone)
3. Cliquez sur Recharger (icône de rechargement dans le panneau)
4. Laissez tourner au moins 20 secondes, en scrollant pendant ce temps
5. Arrêtez

Ce que vous cherchez :

• Les blocs rouges dans la piste principale : les long tasks, ces tâches de plus de 50 ms pendant lesquelles la page est figée.
• Les petits triangles rouges en haut à droite des blocs : cliquez, la console vous dit souvent Forced reflow is a likely performance bottleneck.
• Le flamegraph : cliquez sur un bloc rouge, remontez la pile d'appels. Le nom de la fonction et son fichier d'origine apparaissent à droite. C'est ainsi qu'on trouve du code coupable sans l'avoir lu.
• La régularité. Des long tasks qui reviennent à intervalles fixes trahissent un setInterval. Des long tasks qui grossissent avec le temps trahissent une charge qui s'accumule.
• L'onglet Bottom-Up (en bas) : il classe les fonctions par temps total passé dedans. Triez, lisez les trois premières lignes, vous avez vos coupables.

Le cas particulier du scroll

Un problème de scroll ne se voit pas au chargement. Enregistrez une session où vous ne faites que scroller, sans recharger. Si chaque cran de molette produit un bloc long, le coupable est un gestionnaire d'événement.

Outil 4 — L'onglet Coverage

Méconnu, très rentable pour le CSS.

DevTools → Ctrl+Maj+P → tapez coverage → Show Coverage → bouton de rechargement.

Vous obtenez, pour chaque fichier CSS et JS, le pourcentage de code réellement utilisé. Une barre rouge à 98 % sur une feuille de style vous dit exactement quoi faire.

Protocole avant/après

Pour que votre comparaison soit honnête :

1. Mêmes conditions : même navigateur, même profil Lighthouse, même ralentissement CPU, cache désactivé, navigation privée.
2. Mesurez avant de commencer, et conservez les captures. On ne remesure pas un « avant » après coup.
3. Mesurez après chaque optimisation, pas seulement à la fin. C'est comme ça qu'on sait ce qui a payé — parfois, une correction ne change rien, et c'est une information.
4. Notez tout dans un tableau au fur et à mesure.

Où mesurer : en local ou en ligne ?

Les deux, mais pas pour la même chose.

La raison tient en un mot : la compression. Aucun serveur local ne compresse les fichiers texte, alors qu'un hébergeur sert du gzip ou du brotli. Sur ce site :

Conséquence directe pour votre audit : mesuré en local, le CSS inutilisé paraît dix fois plus coûteux qu'il ne l'est en production. Si vous bâtissez vos priorités là-dessus, vous passerez du temps sur le mauvais problème. Les images, elles, sont déjà compressées : gzip n'y change rien, et leur poids est le même partout.

C'est aussi un enseignement en soi : une optimisation se juge dans les conditions de production, pas dans les conditions de développement.

Le cas de Live Server

L'extension Live Server de VS Code est pratique pour éditer — le rechargement automatique évite des centaines de Ctrl+R. Mais elle injecte dans chaque page un script de rechargement (~1,2 Ko) et ouvre une WebSocket. Les deux apparaissent dans vos relevés : un <script> de plus dans le DOM, une connexion de plus dans l'onglet Réseau, un poids de document supérieur à celui du fichier réel.

Même famille de problème que le widget ?perf=1 : un outil de mesure qui modifie ce qu'il mesure. Utilisez Live Server pour travailler, pas pour relever.

Pièges de mesure classiques

• Mesurer en file://. Pas de vrai réseau, pas de vrais en-têtes. Servez toujours en HTTP (python3 -m http.server 8000).
• Confondre poids local et poids réel. Voir ci-dessus : sans gzip, les fichiers texte paraissent bien plus lourds qu'ils ne le sont en ligne.
• Mesurer à travers un serveur qui injecte du code. Live Server, et la plupart des outils à rechargement automatique.
• Oublier de vider le cache. Le deuxième chargement est toujours rapide.
• Mesurer une seule fois. La variance est réelle, faites trois essais.
• Mesurer avec des extensions actives. Elles injectent du code.
• Mesurer trop court. Certains problèmes ne se déclenchent pas dans les trois premières secondes.
• Croire que le TBT voit tout. Il ne compte que les tâches de plus de 50 ms. Une page peut être franchement désagréable à utiliser avec un TBT faible, si le travail est réparti en nombreuses tâches plus courtes. Une métrique basse ne prouve pas l'absence de problème : regardez la frise du panneau Performances, pas seulement les chiffres.
• Mesurer sur un seul format d'écran. Voir plus haut : mobile et desktop ne montrent pas les mêmes choses.