Repérer le chemin critique
Les feuilles de style et les scripts synchrones peuvent bloquer le rendu lorsque le navigateur en a besoin avant de construire ou d’afficher la page. La bonne réponse dépend de la nécessité de la ressource pour l’affichage initial. Retirer une requête d’un rapport sans préserver les styles ou comportements requis ne fait que déplacer le problème.
Comment l’inspecter
Enregistrez une trace de chargement de la page et repérez les ressources qui précèdent le premier rendu, celles réellement utilisées au-dessus de la ligne de flottaison, et le point où le temps de réponse du serveur ou le travail du thread principal domine le délai. Testez avec un cache vide et une connexion représentative. Les données de laboratoire établissent le diagnostic du chemin ; les données terrain montrent si les visiteurs le vivent réellement.
Comment la mettre en œuvre ou l’améliorer
N’intégrez en ligne ou ne priorisez que le petit CSS critique nécessaire à l’affichage initial, différez le code non critique lorsque cela est sans danger, et réduisez le code inutilisé à la source. Après chaque modification, vérifiez la complétude visuelle, le comportement au clavier, l’absence d’erreur lors des interactions et l’absence de nouveau décalage de mise en page.
Limites et erreurs courantes
L’erreur courante consiste à différer tous les scripts ou toutes les feuilles de style. Les ressources critiques le sont parce que la page initiale en a besoin ; il vaut mieux rendre cette dépendance plus petite et plus intentionnelle.
Le tri commence par une cascade de requêtes et une trace, et non par une règle générale du type « différer le JavaScript ». Identifiez le premier état visuel utile, listez le CSS, les polices et les scripts nécessaires pour le créer, puis séparez ce petit ensemble des ressources demandées plus tard. Une feuille de style qui définit la navigation initiale peut être critique ; une bibliothèque de carrousel située sous la ligne de flottaison ne l’est pas. Inspectez la priorité des requêtes, le temps de réponse, les octets inutilisés et les tâches du thread principal. Pour la mise en œuvre, réduisez ou scindez le style inutilisé à la source, ne précargez qu’une ressource dont la première vue a réellement besoin, et ne différez un fichier qu’après avoir vérifié que la page reste mise en forme et interactive sans lui. Testez de nouveau avec un cache vide, une connexion limitée et la navigation au clavier. Si un remplacement de police modifie les retours à la ligne, consignez cet effet de mise en page en plus de l’effet sur le délai de chargement. Le résultat à vérifier est une première vue complète et utilisable, et non simplement un nombre d’alertes plus faible.
Exemple concret. Une page de liste de produits charge une feuille de style globale, une petite feuille de style pour l’en-tête, une police web, un composant de tri et une galerie située sous la ligne de flottaison. Dans la cascade, vérifiez que les deux premières feuilles de style sont bien utilisées avant le premier affichage ; elles peuvent être candidates à un lot critique réduit. Le script de la galerie ne doit pas retarder l’en-tête ni la grille de produits s’il n’est pas visible. N’intégrez pas toute la feuille de style globale : cela duplique les octets et complique la mise en cache. Extrayez plutôt seulement les règles nécessaires à la première vue, chargez normalement la feuille de style principale, et testez la transition à son arrivée. Relancez la cascade après le déploiement et contrôlez l’apparition d’un texte non stylé (FOUT), l’absence de contours de focus et les décalages de mise en page. Un changement n’est accepté que si la page s’affiche correctement et que les interactions ultérieures restent fonctionnelles.