Le chemin de rendu critique est la séquence de tâches que le navigateur exécute pour d’abord rendre une page à l’écran, c’est-à-dire pour télécharger, traiter et convertir le code HTML, CSS et JavaScript en pixels réels, et les afficher à l’écran.
L’optimisation du chemin de rendu critique est le processus qui consiste à minimiser le temps passé par le navigateur pour exécuter chaque étape de la séquence en donnant la priorité à l’affichage du contenu lié à l’action de l’utilisateur actuel.
Une grande partie de ce processus concerne la partie de la page qui est visible sans faire défiler la fenêtre du navigateur. Cette section est aussi connue sous le nom de « Au dessus du pli » (Above the Fold ou ATF). Pour une meilleure ergonomie, l’ATF doit être rendu le plus rapidement possible, ce qui peut se faire en réduisant au minimum le nombre d’allers-retours sur le réseau. Les ressources nécessaires pour rendre l’ATF sont considérées comme critiques, et l’optimisation au dessus du pli signifie minimiser l’impact des ressources critiques sur le temps nécessaire au premier rendu de la page.
Dans cet article, nous allons suivre la séquence d’optimisation du chemin de rendu critique.
- Tout d’abord, je vais vous donner un aperçu général des tâches que le navigateur effectue pour rendre le contenu d’une page.
- Ensuite, je disséquerai les actions les plus pertinentes que nous pouvons mener pour optimiser le chemin de rendu critique.
- Enfin, je vais énumérer quelques extensions WordPress d’optimisation utiles (et populaires).
La séquence de chemin de rendu critique
Voici la séquence des étapes effectuées par le navigateur pour rendre une page :
- Tout d’abord, le navigateur télécharge et analyse le balisage HTML et construit le DOM.
- Ensuite, il télécharge et traite le balisage CSS puis construit le modèle objet CSS.
- Il combine les nœuds DOM et CSSOM nécessaires pour rendre la page dans l’arbre de rendu, qui est une arborescence de tous les nœuds visibles.
- Il calcule les dimensions et la position de chaque objet dans la page.
- Enfin, il affiche les pixels sur l’écran
Le DOM
Comme l’explique également le guide d’optimisation du chemin de rendu critique de Google, le navigateur construit le Document Object Model en quatre étapes :
- Tout d’abord, le navigateur lit les octets de ligne et les traduit en caractères individuels.
- Ensuite, il convertit les chaînes de caractères entre parenthèses en jetons.
- Ces jetons sont convertis en objets nodaux
- Les objets nodaux sont liés dans une structure de données arborescente qui contient le contenu HTML, les propriétés et toutes les relations entre les nœuds. Cette structure est le Document Object Model.
Ce qu’il est important de noter ici, c’est que le navigateur construit le DOM de façon incrémentale. Cela nous donne la possibilité d’accélérer le rendu de la page en créant des structures DOM efficaces.
Le CSSOM
Lorsque l’analyseur rencontre une balise de link qui fait référence à une feuille de style CSS externe, il bloque l’analyse et envoie une demande pour cette ressource. Une fois le fichier CSS reçu, le navigateur commence à construire une arborescence de données des nœuds CSS.
- Le navigateur lit les octets de ligne du fichier .css et les traduit en caractères individuels.
- Il convertit les chaînes de caractères entre crochets en jetons.
- Ces jetons sont convertis en objets nodaux
- Les objets nodaux sont liés dans une structure de données arborescente qui contient les propriétés CSS de chaque nœud et les relations entre les nœuds. Cette structure est le modèle objet CSS (CSSOM).
Contrairement à la construction DOM, la construction CSSOM n’est pas incrémentale. Le navigateur ne peut pas utiliser une partie d’une feuille de style, car les styles peuvent être raffinés et redéclarés dans la même feuille de style. Pour cette raison, le navigateur bloque le processus de rendu jusqu’à ce qu’il reçoive et analyse toutes les CSS. Cela signifie que le CSS bloque le rendu.
L’arbre de rendu
Le navigateur combine DOM et CSSOM dans l’arbre de rendu, qui est l’arborescence finale contenant tous les nœuds et propriétés utilisés pour rendre la page à l’écran.
L’arborescence de rendu ne contient que les nœuds nécessaires au rendu d’une page. Par conséquent, les nœuds invisibles sont omis.
Le navigateur utilise l’arbre de rendu pour calculer les dimensions et la position des nœuds, et finalement comme entrée pour le processus d’affichage.
Mise en page et affichage
Au stade de la mise en page, le navigateur calcule les dimensions et la position de chaque nœud de l’arbre de rendu. Dans cette étape, le navigateur traverse l’arbre de rendu à partir de sa racine et produit un modèle de boîte. Ces informations sont finalement utilisées pour convertir chaque nœud de l’arbre de rendu en pixels réels à l’écran.
Optimisation du chemin de rendu critique
Le temps nécessaire pour exécuter l’ensemble du processus peut varier. Cela dépend de nombreux facteurs tels que la taille du document, le nombre de requêtes, les styles appliqués, le périphérique utilisateur, etc.
L’une des recommandations les plus pertinentes de Google est de prioriser le contenu visible afin de rendre le plus rapidement possible l’au dessus du pli, et fournit deux règles principales à suivre :
- Structurer le HTML pour charger d’abord le contenu critique, au-dessus du pli.
- Réduire la quantité de données utilisées par les ressources HTML, CSS et JS
Comme l’explique également le guide PageSpeed de Google, si la quantité de données requises pour rendre l’ATF dépasse la fenêtre de congestion initiale (14.6kb), il faudra des allers-retours réseau supplémentaires entre le serveur et le navigateur. Sur les réseaux mobiles, avec des latences élevées, cela retarderait considérablement le chargement des pages (en savoir plus sur la latence).
Le navigateur construit le DOM de façon incrémentale, ce qui nous donne l’opportunité de réduire le temps nécessaire au rendu de l’ATF en structurant le HTML de manière à charger d’abord le dessus de la page et à reporter le reste.
Mais l’optimisation ne s’arrête pas à la construction d’une structure DOM efficace. Il s’agit plutôt d’un processus d’amélioration et de mesure qui implique l’ensemble de la séquence du chemin de rendu critique.
Plongeons en profondeur.
Minimiser les dimensions des ressources
Nous pouvons réduire la quantité de données que le navigateur va télécharger en minifiant, comprimant et mettant en cache les ressources HTML, CSS et JavaScript :
- La minimisation est le processus qui consiste à supprimer les caractères inutiles comme les commentaires et les espaces blancs du code source. Ces caractères sont extrêmement utiles en développement, mais ils sont inutiles pour le navigateur afin de rendre la page.
- La compression est la capacité des serveurs Web et des clients à réduire la taille des fichiers transmis afin d’améliorer la vitesse et l’utilisation de la bande passante.
- Mise en cache : chaque navigateur est livré avec une implémentation d’un cache HTTP. Ce que nous devons faire, c’est nous assurer que chaque réponse de serveur fournit les en-têtes HTTP corrects pour indiquer au navigateur quand et combien de temps il doit mettre en cache les ressources demandées.
Optimiser le CSS
Nous savons maintenant que le navigateur doit attendre de récupérer et traiter le code CSS avant de pouvoir rendre la page (le CSS bloque le rendu). Mais toutes les ressources CSS ne sont pas bloquantes.
Le CSS peut être adapté à des conditions particulières, et nous pouvons l’optimiser en utilisant des types de médias et des requêtes médias. Si vous visualisez une page à l’écran, le navigateur enverra une demande pour le type de média affiché, mais il ne bloquera pas le rendu de la page pour cette ressource.
Prenez la balise suivante link :
<link rel="stylesheet" href="style.css" />La feuille de style référencée de cette balise s’applique dans n’importe quelle condition, indépendamment du type de support actuel, de la résolution de l’écran, de l’orientation du périphérique, etc. Cela signifie que la ressource CSS bloque toujours le rendu.
Heureusement, nous pouvons envoyer une demande pour une ressource CSS dans des conditions spécifiques. Nous pourrions déplacer les styles d’affichage dans un fichier séparé et utiliser l’attribut media pour indiquer au navigateur que la feuille de style spécifiée ne doit être chargée que lors de l’affichage de la page, et qu’elle n’a pas besoin de bloquer le rendu à l’écran :
<link rel="stylesheet" href="print.css" media="print" />Le navigateur télécharge toujours la feuille de style print.css, mais il ne bloque pas le rendu. De plus, le navigateur doit télécharger moins de données pour le fichier CSS principal, ce qui nous aiderait à accélérer le téléchargement. Nous pouvons spécifier n’importe quelle requête média sur l’attribut link, donc nous pouvons diviser le CSS en plusieurs fichiers et les charger conditionnellement :
<link rel="stylesheet" href="style.css" media="screen" />
<link rel="stylesheet" href="portrait.css" media="orientation:portrait" />
<link rel="stylesheet" href="widescreen.css" media="(min-width: 42rem)" />Assurez-vous que vos styles sont réellement nécessaire pour rendre la page. Si ce n’est pas le cas, vous pouvez ajouter une valeur appropriée à l’attribut de balise media et débloquer le rendu.
Les types de médias et les requêtes peuvent nous aider à accélérer le rendu des pages, mais nous pouvons faire beaucoup plus.
- Minifier le CSS : les espaces blancs et les commentaires nous aident seulement à lire les déclarations CSS. En supprimant les commentaires et les espaces de la feuille de style, nous pouvons réduire considérablement le nombre d’octets d’un fichier CSS.
- Combiner plusieurs fichiers CSS : cela réduirait le nombre de requêtes HTTP. Cette action est particulièrement importante dans les connexions mobiles, où les performances sont affectées par une latence élevée (en savoir plus sur la latence).
- CSS critique en ligne : certains styles sont critiques en ce sens qu’ils sont nécessaires pour rendre le haut de la page. Vous devez toujours tenir compte des styles critiques en ligne directement dans le balisage HTML pour éviter les requêtes HTTP supplémentaires. Mais évitez d’aligner de gros fichiers CSS, car cela pourrait nécessiter des allers-retours supplémentaires pour rendre le rendu ci-dessus, ce qui entraînerait un avertissement PageSpeed.
Vous pouvez donner un coup de pouce rapide et facile à votre site en minifiant votre code depuis votre tableau de bord MyKinsta. Il vous suffit d’utiliser la fonction de minification du code qui vous est fournie pour activer la modification automatique de CSS et de Javascript en un clic.
Accélération des processus de mise en page et d’affichage
Le temps passé par le navigateur pour mettre en page le document dépend du nombre d’éléments DOM à mettre en page et de la complexité de ces mises en page.
- Si vous avez beaucoup d’éléments DOM, le navigateur peut prendre beaucoup de temps pour calculer la position et les dimensions de tous ces éléments : évitez la mise en page quand c’est possible.
- Préférez le nouveau modèle Flexbox, car il est plus rapide que l’ancien Flexbox et les modèles flottants.
- Éviter la mise en page synchrone forcée avec JavaScript
Le calcul de la taille et de la position des éléments prend du temps et réduit les performances. Rendre le DOM aussi simple que possible, et éviter l’utilisation de JavaScript pour anticiper le processus de mise en page aiderait le navigateur à accélérer le rendu des pages (en savoir plus sur l’optimisation de mise en page).
Le processus d’affichage est strictement lié à la mise en page, qui est probablement l’étape la plus longue de la séquence du chemin de rendu critique, car chaque fois que vous modifiez la mise en page d’un élément ou toute propriété non géométrique, le navigateur déclenche un événement d’affichage. Rendre les choses aussi simples que possible à cette étape pourrait aider le navigateur à accélérer le processus d’affichage. Par exemple, une propriété de box-shadow, qui nécessite un certain type de calculs, prendrait plus de temps à afficher qu’une couleur de bordure solide.
L’optimisation du processus d’afichage n’est peut-être pas si simple, et vous devriez utiliser les outils de développement de votre navigateur pour mesurer le temps qu’il faut au navigateur pour déclencher chaque événement d’affichage. Vous pouvez en savoir plus à ce sujet dans le guide Google Rendering Performance guide.
Faire le déblocage JavaScript
Lorsque le navigateur rencontre une balise de script, il doit arrêter d’analyser le code HTML. Les scripts en ligne sont exécutés à l’endroit exact où ils se trouvent dans le document et bloquent la construction du DOM jusqu’à ce que le moteur JS termine son exécution. En d’autres termes, le JavaScript en ligne peut retarder considérablement le rendu initial de la page. Mais le JavaScript permet également de manipuler les propriétés CSS, de sorte que le navigateur doit interrompre l’exécution du script jusqu’à ce qu’il ait fini de télécharger et de construire le CSSOM, ainsi. Cela signifie que le JavaScript bloque l’analyseur.
Dans le cas de fichiers JS externes, l’analyseur doit également attendre que la ressource ait été récupérée à partir du cache ou du serveur distant, ce qui pourrait ralentir considérablement le temps nécessaire au premier rendu de la page.
Cela dit, que pouvons-nous faire pour minimiser le temps passé par le navigateur pour charger et exécuter JavaScript ?
- Charger du JavaScript asynchrone : l’attribut booléen
asyncde la balisescriptdemande au navigateur d’exécuter le script de manière asynchrone, si possible, sans bloquer la construction DOM. Le navigateur envoie la requête HTTP pour le script et continue d’analyser le DOM. De plus, le script ne bloque pas la construction CSSOM, ce qui signifie qu’il ne bloque pas le chemin de rendu critique (voir la documentation de MDN pour plus d’informations sur les attributs des balises script). - Différer le JavaScript : l’attribut booléen
deferde la balisescriptindique au navigateur d’exécuter le script après que le document a été analysé, mais avant de lancer l’événementDOMContentLoaded. Cet attribut ne doit pas être utilisé si l’attribut src est absent, c’est-à-dire les scripts en ligne (pour en savoir plus sur Mozilla Hacks) - Reporter le JavaScript en ligne : beaucoup de scripts ne manipulent pas le DOM ou le CSSOM, il n’y a donc aucune bonne raison pour eux de bloquer l’analyse. Malheureusement, nous ne pouvons pas utiliser les attributs
asyncetdeferpour les scripts en ligne, donc la seule façon de les charger une fois le document chargé est de les déplacer vers le bas. L’avantage est que les scripts en ligne ne nécessitent pas de requêtes HTTP supplémentaires. Cependant, l’enchaînement de scripts utilisés dans plusieurs pages se traduirait par un code redondant.
Envelopper les règles d’optimisation
C’est beaucoup de choses, n’est-ce pas ? Reprenons notre souffle et dressons une liste des actions d’optimisation décrites jusqu’à présent.
- Minifier, compresser et mettre en cache les ressources HTML, CSS et JavaScript.
- Minimiser l’utilisation des ressources de blocage de rendu (en particulier CSS)
- Utiliser les requêtes des médias sur les balises
link - Fractionner les feuilles de style et les feuilles de style CSS critiques en ligne
- Combiner plusieurs fichiers CSS
- Utiliser les requêtes des médias sur les balises
- Minimiser l’utilisation des ressources de blocage de l’analyseur (JavaScript)
- Utiliser l’attribut
defersur les balises de script - Utiliser l’attribut
asyncsur les balises de script - JavaScript en ligne et déplacer les balises de
scriptvers le bas du document
- Utiliser l’attribut
Maintenant que nous connaissons les concepts de base de l’optimisation du chemin de rendu critique, nous pouvons jeter un coup d’œil à quelques extensions d’optimisation populaires de WordPress.
Optimisation du chemin de rendu critique dans WordPress
Les utilisateurs de WordPress peuvent profiter d’un certain nombre d’extensions qui couvrent presque tous les aspects du processus d’optimisation. Vous pouvez installer une extension complète ou plusieurs extensions à la fois, chacune offrant des fonctions d’optimisation spécifiques.
Si votre site est hébergé par Kinsta, vous n’aurez pas besoin d’une extension de mise en cache car aucune extension WordPress de mise en cache n’est nécessaire chez Kinsta.
W3 Total Cache
Cette extension unique couvre presque toutes les étapes du processus d’optimisation du chemin de rendu critique. Au premier coup d’œil, la configuration de l’extension peut être écrasante, mais une fois que vous vous serez familiarisé avec la séquence du chemin de rendu critique, vous pourrez profiter d’un puissant ensemble d’outils de performance.
Voici une liste de quelques fonctionnalités de l’extension :
- Mise en cache HTML (articles et pages), CSS et JavaScript en mémoire, sur disque ou sur CDN
- Mise en cache des flux, des résultats de recherche, des objets de base de données, des objets et fragments WordPress
- Minification HTML (articles et pages)
- Minification JavaScript et CSS
- Optimisation JavaScript avec
asyncetdefer - Mise en cache du navigateur à l’aide du contrôle de cache, des en-têtes d’expiration futurs et des balises d’entité
- Compression HTTP (gzip)
- Résultats Google PageSpeed sur le tableau de bord WordPress
Ce ne sont là que quelques-unes des nombreuses caractéristiques de W3TC. Vous pouvez en savoir plus sur toutes les fonctionnalités, paramètres et options du plugin dans ce guide détaillé.
WP Super Cache
WP Super Cache est une autre extension populaire pour les performances du site.
Elle est livrée avec un bon nombre de fonctionnalités d’optimisation, mais est moins complète que le précédent W3 Total Cache et peut sembler plus abordable pour les utilisateurs débutants et intermédiaires.
Fondamentalement, elle fournit des fonctions de mise en cache et de compression HTTP, mais manque de minification des ressources et d’optimisation JavaScript avec des attributs async et defer. Cependant, plus d’un million d’installations actives prouvent que l’extension vaut la peine d’être essayée.
Autoptimize
Avec plus de 1 000 000 installations actives, Autoptimize est l’une des extensions gratuites les plus populaires pour la minification.
Elle est livrée avec une page d’options divisée en plusieurs sections où l’administrateur du site peut configurer séparément la minification HTML, CSS et JavaScript.
Vous pouvez également agréger des scripts ou des feuilles de style indépendants et définir des exceptions pour des ressources spécifiques. De plus, Autoptimize permet de mettre en cache les ressources minifiées sur disque ou sur CDN et d’enregistrer les ressources optimisées sous forme de fichiers statiques. Pour trouver les meilleurs paramètres pour votre site WordPress, vous pouvez suivre notre guide détaillé d’Autoptimize.
Autres extensions d’optimisation que vous pouvez essayer :
Swift Performance
Swift Performance est une autre extension que vous voudrez peut-être consulter. Il s’agit d’une extension payante qui peut vous aider à augmenter vos scores de performance, et a été développée spécifiquement pour vous aider à essayer d’atteindre ces scores de 100/100 Google PageSpeed Insights.
Quelques-unes de ses principales caractéristiques incluent :
- Non seulement vous pouvez minifier et combiner des fichiers CSS et javascript, mais vous pouvez aussi créer des CSS critiques à la volée pour vos pages.
- Mise en cache intelligente, ainsi que des requêtes AJAX et dynamiques.
- Compression d’image sans perte intégrée.
- Support de CDN.
Vous trouverez une vue plus approfondie dans les extensions d’optimisation WordPress dans Comment éliminer le JavaScript bloquant le rendu et le CSS.
Conclusions
L’optimisation du chemin de rendu critique est un processus d’amélioration et de mesure qui exige une compréhension claire de chaque tâche effectuée par le navigateur pour convertir le code en pixels et ainsi rendre une page à l’écran. Pour en savoir plus sur le chemin de rendu critique, consultez le guide d’optimisation de Google.
Ici, sur Kinsta Blog, nous essayons de couvrir tous les aspects de l’optimisation des performances. Voici une liste de lectures complémentaires :
- Latence du réseau – Comparaison de l’impact sur votre site WordPress
- CDN WordPress – Pourquoi vous devriez en utiliser un
- Comment optimiser les images pour le Web et la performance
- Comment réduire la TTFB pour améliorer les temps de chargement des pages WordPress
- Une plongée en profondeur dans l’outil de test de vitesse GTmetrix
- 14 outils gratuits de test de vitesse de site pour les utilisateurs de WordPress
- 8 extensions de performance WordPress moins connues (mais utiles)
- Comment avoir une note de 100/100 dans Google PageSpeed Insights avec WordPress
Combien de temps vous faut-il pour optimiser le chemin de rendu critique de vos sites ? Et quels sont les aspects du processus d’optimisation que vous maîtrisez le mieux ? Faites-le nous savoir dans les commentaires ci-dessous.
Carlo is a passionate lover of webdesign and front-end development. He has been playing with WordPress for more than 20 years, also in collaboration with Italian and European universities and educational institutions. He has written hundreds of articles and guides about WordPress, published both on Italian and international websites, as well as on printed magazines. You can find him on LinkedIn.
Laisser un commentaire