L’optimisation du chemin de rendu critique est le processus qui consiste \u00e0 minimiser le temps pass\u00e9 par le navigateur pour ex\u00e9cuter chaque \u00e9tape de la s\u00e9quence en donnant la priorit\u00e9 \u00e0 l’affichage du contenu li\u00e9 \u00e0 l’action de l’utilisateur actuel.<\/p><\/blockquote>\n
Une grande partie de ce processus concerne la partie de la page qui est visible sans faire d\u00e9filer la fen\u00eatre du navigateur. Cette section est aussi connue sous le nom de \u00ab\u00a0Au dessus du pli<\/strong>\u00a0\u00bb (Above the Fold ou ATF). Pour une meilleure ergonomie, l’ATF doit \u00eatre rendu le plus rapidement possible, ce qui peut se faire en r\u00e9duisant au minimum le nombre d’allers-retours sur le r\u00e9seau. Les ressources n\u00e9cessaires pour rendre l’ATF sont consid\u00e9r\u00e9es comme critiques, et l’optimisation au dessus du pli signifie minimiser l’impact des ressources critiques sur le temps n\u00e9cessaire au premier rendu de la page.<\/p>\n Dans cet article, nous allons suivre la s\u00e9quence d’optimisation du chemin de rendu critique.<\/p>\n Voici la s\u00e9quence des \u00e9tapes effectu\u00e9es par le navigateur pour rendre une page :<\/p>\n Comme l’explique \u00e9galement le guide d’optimisation du chemin de rendu critique de<\/a> Google, le navigateur construit le Document Object Model en quatre \u00e9tapes :<\/p>\n Ce qu’il est important de noter ici, c’est que le navigateur construit le DOM de fa\u00e7on incr\u00e9mentale. Cela nous donne la possibilit\u00e9 d’acc\u00e9l\u00e9rer le rendu de la page en cr\u00e9ant des structures DOM efficaces.<\/p>\n Lorsque l’analyseur rencontre une balise de Contrairement \u00e0 la construction DOM, la construction CSSOM n’est pas incr\u00e9mentale. Le navigateur ne peut pas utiliser une partie d’une feuille de style, car les styles peuvent \u00eatre raffin\u00e9s et red\u00e9clar\u00e9s dans la m\u00eame feuille de style. Pour cette raison, le navigateur bloque le processus de rendu jusqu’\u00e0 ce qu’il re\u00e7oive et analyse toutes les CSS. Cela signifie que le CSS bloque le rendu<\/strong>.<\/p>\n Le navigateur combine DOM et CSSOM dans l’arbre de rendu, qui est l’arborescence finale contenant tous les n\u0153uds et propri\u00e9t\u00e9s utilis\u00e9s pour rendre la page \u00e0 l’\u00e9cran.<\/p>\n L’arborescence de rendu ne contient que les n\u0153uds n\u00e9cessaires au rendu d’une page. Par cons\u00e9quent, les n\u0153uds invisibles sont omis.<\/p><\/blockquote>\n Le navigateur utilise l’arbre de rendu pour calculer les dimensions et la position des n\u0153uds, et finalement comme entr\u00e9e pour le processus d\u2019affichage.<\/p>\n Au stade de la mise en page, le navigateur calcule les dimensions et la position de chaque n\u0153ud de l’arbre de rendu. Dans cette \u00e9tape, le navigateur traverse l’arbre de rendu \u00e0 partir de sa racine et produit un mod\u00e8le de bo\u00eete. Ces informations sont finalement utilis\u00e9es pour convertir chaque n\u0153ud de l’arbre de rendu en pixels r\u00e9els \u00e0 l’\u00e9cran.<\/p>\n Le temps n\u00e9cessaire pour ex\u00e9cuter l’ensemble du processus peut varier. Cela d\u00e9pend de nombreux facteurs tels que la taille du document, le nombre de requ\u00eates, les styles appliqu\u00e9s, le p\u00e9riph\u00e9rique utilisateur, etc. Comme l’explique \u00e9galement le guide PageSpeed de Google<\/a>, si la quantit\u00e9 de donn\u00e9es requises pour rendre l’ATF d\u00e9passe la fen\u00eatre de congestion initiale (14.6kb), il faudra des allers-retours r\u00e9seau suppl\u00e9mentaires entre le serveur et le navigateur. Sur les r\u00e9seaux mobiles, avec des latences \u00e9lev\u00e9es, cela retarderait consid\u00e9rablement le chargement des pages (en savoir plus sur la latence<\/a>). Mais l’optimisation ne s’arr\u00eate pas \u00e0 la construction d’une structure DOM efficace. Il s’agit plut\u00f4t d’un processus d’am\u00e9lioration et de mesure qui implique l’ensemble de la s\u00e9quence du chemin de rendu critique.<\/p>\n Plongeons en profondeur.<\/p>\n Nous pouvons r\u00e9duire la quantit\u00e9 de donn\u00e9es que le navigateur va t\u00e9l\u00e9charger en minifiant, comprimant et mettant en cache les ressources HTML, CSS et JavaScript :<\/p>\n Nous savons maintenant que le navigateur doit attendre de r\u00e9cup\u00e9rer et traiter le code CSS avant de pouvoir rendre la page (le CSS bloque le rendu<\/a>). Mais toutes les ressources CSS ne sont pas bloquantes.<\/strong><\/p>\n Le CSS peut \u00eatre adapt\u00e9 \u00e0 des conditions particuli\u00e8res, et nous pouvons l’optimiser en utilisant des types de m\u00e9dias et des requ\u00eates m\u00e9dias. Si vous visualisez une page \u00e0 l’\u00e9cran, le navigateur enverra une demande pour le type de m\u00e9dia affich\u00e9, mais il ne bloquera pas le rendu de la page pour cette ressource. La feuille de style r\u00e9f\u00e9renc\u00e9e de cette balise s’applique dans n’importe quelle condition, ind\u00e9pendamment du type de support actuel, de la r\u00e9solution de l’\u00e9cran, de l’orientation du p\u00e9riph\u00e9rique, etc. Cela signifie que la ressource CSS bloque toujours le rendu.<\/p>\n Heureusement, nous pouvons envoyer une demande pour une ressource CSS dans des conditions sp\u00e9cifiques. Nous pourrions d\u00e9placer les styles d’affichage dans un fichier s\u00e9par\u00e9 et utiliser l’attribut Le navigateur t\u00e9l\u00e9charge toujours la feuille de style print.css<\/i>, mais il ne bloque pas le rendu. De plus, le navigateur doit t\u00e9l\u00e9charger moins de donn\u00e9es pour le fichier CSS principal, ce qui nous aiderait \u00e0 acc\u00e9l\u00e9rer le t\u00e9l\u00e9chargement. Nous pouvons sp\u00e9cifier n’importe quelle requ\u00eate m\u00e9dia sur l’attribut Assurez-vous que vos styles sont r\u00e9ellement n\u00e9cessaire pour rendre la page. Si ce n’est pas le cas, vous pouvez ajouter une valeur appropri\u00e9e \u00e0 l’attribut de balise media et d\u00e9bloquer le rendu.<\/p>\n Les types de m\u00e9dias et les requ\u00eates peuvent nous aider \u00e0 acc\u00e9l\u00e9rer le rendu des pages, mais nous pouvons faire beaucoup plus.<\/p>\n Vous pouvez donner un coup de pouce rapide et facile \u00e0 votre site en minifiant votre code depuis votre tableau de bord MyKinsta<\/a>. Il vous suffit d’utiliser la fonction de minification du code<\/a> qui vous est fournie pour activer la modification automatique de CSS et de Javascript en un clic.<\/p>\n Le temps pass\u00e9 par le navigateur pour mettre en page le document d\u00e9pend du nombre d’\u00e9l\u00e9ments DOM \u00e0 mettre en page et de la complexit\u00e9 de ces mises en page.<\/p>\n Le calcul de la taille et de la position des \u00e9l\u00e9ments prend du temps et r\u00e9duit les performances. Rendre le DOM aussi simple que possible, et \u00e9viter l’utilisation de JavaScript pour anticiper le processus de mise en page aiderait le navigateur \u00e0 acc\u00e9l\u00e9rer le rendu des pages (en savoir plus sur l’optimisation de mise en page<\/a>).<\/p>\n Le processus d\u2019affichage est strictement li\u00e9 \u00e0 la mise en page, qui est probablement l’\u00e9tape la plus longue de la s\u00e9quence du chemin de rendu critique, car chaque fois que vous modifiez la mise en page d’un \u00e9l\u00e9ment ou toute propri\u00e9t\u00e9 non g\u00e9om\u00e9trique, le navigateur d\u00e9clenche un \u00e9v\u00e9nement d\u2019affichage. Rendre les choses aussi simples que possible \u00e0 cette \u00e9tape pourrait aider le navigateur \u00e0 acc\u00e9l\u00e9rer le processus d\u2019affichage. Par exemple, une propri\u00e9t\u00e9 de L’optimisation du processus d\u2019afichage n’est peut-\u00eatre pas si simple, et vous devriez utiliser les outils de d\u00e9veloppement de votre navigateur pour mesurer le temps qu’il faut au navigateur pour d\u00e9clencher chaque \u00e9v\u00e9nement d\u2019affichage. Vous pouvez en savoir plus \u00e0 ce sujet dans le guide Google Rendering Performance guide<\/a>.<\/p>\n Lorsque le navigateur rencontre une balise de script, il doit arr\u00eater d’analyser le code HTML. Les scripts en ligne sont ex\u00e9cut\u00e9s \u00e0 l’endroit exact o\u00f9 ils se trouvent dans le document et bloquent la construction du DOM jusqu’\u00e0 ce que le moteur JS termine son ex\u00e9cution. En d’autres termes, le JavaScript en ligne peut retarder consid\u00e9rablement le rendu initial de la page. Mais le JavaScript permet \u00e9galement de manipuler les propri\u00e9t\u00e9s CSS, de sorte que le navigateur doit interrompre l’ex\u00e9cution du script jusqu’\u00e0 ce qu’il ait fini de t\u00e9l\u00e9charger et de construire le CSSOM, ainsi. Cela signifie que le JavaScript bloque l’analyseur<\/strong>.<\/p>\n Dans le cas de fichiers JS externes, l’analyseur doit \u00e9galement attendre que la ressource ait \u00e9t\u00e9 r\u00e9cup\u00e9r\u00e9e \u00e0 partir du cache ou du serveur distant, ce qui pourrait ralentir consid\u00e9rablement le temps n\u00e9cessaire au premier rendu de la page.<\/p>\n Cela dit, que pouvons-nous faire pour minimiser le temps pass\u00e9 par le navigateur pour charger et ex\u00e9cuter JavaScript ?<\/p>\n C’est beaucoup de choses, n’est-ce pas ? Reprenons notre souffle et dressons une liste des actions d’optimisation d\u00e9crites jusqu’\u00e0 pr\u00e9sent.<\/p>\n Maintenant que nous connaissons les concepts de base de l’optimisation du chemin de rendu critique, nous pouvons jeter un coup d\u2019\u0153il \u00e0 quelques extensions d’optimisation populaires de WordPress.<\/p>\n Les utilisateurs de WordPress peuvent profiter d’un certain nombre d\u2019extensions qui couvrent presque tous les aspects du processus d’optimisation. Vous pouvez installer une extension compl\u00e8te ou plusieurs extensions \u00e0 la fois, chacune offrant des fonctions d’optimisation sp\u00e9cifiques.<\/p>\n Si votre site est h\u00e9berg\u00e9 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\u00e9cessaire chez Kinsta<\/a>.<\/p><\/blockquote>\n Cette extension unique couvre presque toutes les \u00e9tapes du processus d’optimisation du chemin de rendu critique. Au premier coup d’\u0153il, la configuration de l\u2019extension peut \u00eatre \u00e9crasante, mais une fois que vous vous serez familiaris\u00e9 avec la s\u00e9quence du chemin de rendu critique, vous pourrez profiter d’un puissant ensemble d’outils de performance.<\/p>\n Voici une liste de quelques fonctionnalit\u00e9s de l\u2019extension :<\/p>\n Ce ne sont l\u00e0 que quelques-unes des nombreuses caract\u00e9ristiques de W3TC. Vous pouvez en savoir plus sur toutes les fonctionnalit\u00e9s, param\u00e8tres et options<\/a> du plugin dans ce guide d\u00e9taill\u00e9.<\/p>\n WP Super Cache<\/a> est une autre extension populaire pour les performances du site.<\/p>\n Elle est livr\u00e9e avec un bon nombre de fonctionnalit\u00e9s d’optimisation, mais est moins compl\u00e8te que le pr\u00e9c\u00e9dent W3 Total Cache et peut sembler plus abordable pour les utilisateurs d\u00e9butants et interm\u00e9diaires.<\/p>\n 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 Avec plus de 1 000 000 installations actives, Autoptimize<\/a> est l’une des extensions gratuites les plus populaires pour la minification.<\/p>\n Elle est livr\u00e9e avec une page d’options divis\u00e9e en plusieurs sections o\u00f9 l’administrateur du site peut configurer s\u00e9par\u00e9ment la minification HTML, CSS et JavaScript.<\/p>\n Vous pouvez \u00e9galement agr\u00e9ger des scripts ou des feuilles de style ind\u00e9pendants et d\u00e9finir des exceptions pour des ressources sp\u00e9cifiques. De plus, Autoptimize permet de mettre en cache les ressources minifi\u00e9es sur disque ou sur CDN et d’enregistrer les ressources optimis\u00e9es sous forme de fichiers statiques. Pour trouver les meilleurs param\u00e8tres pour votre site WordPress, vous pouvez suivre <\/span>notre guide d\u00e9taill\u00e9 d’Autoptimize<\/a>.<\/span><\/p>\n Autres extensions d’optimisation que vous pouvez essayer :<\/p>\n Swift Performance<\/a> est une autre extension que vous voudrez peut-\u00eatre consulter. Il s’agit d’une extension payante qui peut vous aider \u00e0 augmenter vos scores de performance, et a \u00e9t\u00e9 d\u00e9velopp\u00e9e sp\u00e9cifiquement pour vous aider \u00e0 essayer d’atteindre ces scores de 100\/100 Google PageSpeed Insights<\/a>.<\/p>\n Quelques-unes de ses principales caract\u00e9ristiques incluent :<\/p>\n Vous trouverez une vue plus approfondie dans les extensions d’optimisation WordPress dans Comment \u00e9liminer le JavaScript bloquant le rendu et le CSS<\/a>.<\/p>\n L’optimisation du chemin de rendu critique est un processus d’am\u00e9lioration et de mesure qui exige une compr\u00e9hension claire de chaque t\u00e2che effectu\u00e9e par le navigateur pour convertir le code en pixels et ainsi rendre une page \u00e0 l’\u00e9cran. Pour en savoir plus sur le chemin de rendu critique, consultez le guide d’optimisation de Google<\/a>.<\/p>\n Ici, sur Kinsta Blog, nous essayons de couvrir tous les aspects de l’optimisation des performances. Voici une liste de lectures compl\u00e9mentaires :<\/p>\n 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\u00eetrisez le mieux ? Faites-le nous savoir dans les commentaires ci-dessous.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Le chemin de rendu critique est la s\u00e9quence de t\u00e2ches que le navigateur ex\u00e9cute pour d\u2019abord rendre une page \u00e0 l’\u00e9cran, c’est-\u00e0-dire pour t\u00e9l\u00e9charger, traiter et …<\/p>\n","protected":false},"author":36,"featured_media":30049,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[46,33],"topic":[1028,1034],"class_list":["post-30027","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-webperf","tag-wordpress","topic-developpement-wordpress","topic-performance-wordpress"],"yoast_head":"\n\n
La s\u00e9quence de chemin de rendu critique<\/h2>\n
\n
Le DOM<\/h3>\n
\n
![\"Structure](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/structure-dom.png\")
Le CSSOM<\/h3>\n
link<\/code> qui fait r\u00e9f\u00e9rence \u00e0 une feuille de style CSS externe, il bloque l’analyse et envoie une demande pour cette ressource. Une fois le fichier CSS re\u00e7u, le navigateur commence \u00e0 construire une arborescence de donn\u00e9es des n\u0153uds CSS.<\/p>\n\n
![\"Structure](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/structure-cssom.png\")
L’arbre de rendu<\/h3>\n
![\"Structure](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/structure-arbre-rendu.png\")
Mise en page et affichage<\/h3>\n
Optimisation du chemin de rendu critique<\/h2>\n
\nL’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\u00e8gles principales \u00e0 suivre :<\/p>\n\n
\nLe navigateur construit le DOM de fa\u00e7on incr\u00e9mentale, ce qui nous donne l’opportunit\u00e9 de r\u00e9duire le temps n\u00e9cessaire au rendu de l’ATF en structurant le HTML de mani\u00e8re \u00e0 charger d’abord le dessus de la page et \u00e0 reporter le reste.<\/p>\n![\"Le](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/contenu-dessus-fonction-appareil-utilisateur.png\")
Minimiser les dimensions des ressources<\/h2>\n
\n
Optimiser le CSS<\/h2>\n
\nPrenez la balise suivante link<\/code>\u00a0:<\/p>\n<link rel=\"stylesheet\" href=\"style.css\" \/><\/code><\/pre>\nmedia<\/code> pour indiquer au navigateur que la feuille de style sp\u00e9cifi\u00e9e ne doit \u00eatre charg\u00e9e que lors de l’affichage de la page, et qu’elle n’a pas besoin de bloquer le rendu \u00e0 l’\u00e9cran :<\/p>\n<link rel=\"stylesheet\" href=\"print.css\" media=\"print\" \/><\/code><\/pre>\nlink<\/code>, donc nous pouvons diviser le CSS en plusieurs fichiers et les charger conditionnellement :<\/p>\n<link rel=\"stylesheet\" href=\"style.css\" media=\"screen\" \/>\n<link rel=\"stylesheet\" href=\"portrait.css\" media=\"orientation:portrait\" \/>\n<link rel=\"stylesheet\" href=\"widescreen.css\" media=\"(min-width: 42rem)\" \/><\/code><\/pre>\n\n
Acc\u00e9l\u00e9ration des processus de mise en page et d\u2019affichage<\/h2>\n
\n
box-shadow<\/code>, qui n\u00e9cessite un certain type de calculs, prendrait plus de temps \u00e0 afficher qu’une couleur de bordure solide.<\/p>\n![\"Les](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/devtools-chrome-permettent-identifier-parties-page-1024x491.png\")
Faire le d\u00e9blocage JavaScript<\/h2>\n
\n
async<\/code> de la balise script<\/code> demande au navigateur d’ex\u00e9cuter le script de mani\u00e8re asynchrone, si possible, sans bloquer la construction DOM. Le navigateur envoie la requ\u00eate 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<\/a> pour plus d’informations sur les attributs des balises script<\/strong>).<\/li>\ndefer<\/code> de la balise script<\/code> indique au navigateur d’ex\u00e9cuter le script apr\u00e8s que le document a \u00e9t\u00e9 analys\u00e9, mais avant de lancer l’\u00e9v\u00e9nement DOMContentLoaded<\/code>. Cet attribut ne doit pas \u00eatre utilis\u00e9 si l’attribut src est absent, c’est-\u00e0-dire les scripts en ligne (pour en savoir plus sur Mozilla Hacks<\/a>)<\/li>\nasync<\/code> et defer<\/code> pour les scripts en ligne, donc la seule fa\u00e7on de les charger une fois le document charg\u00e9 est de les d\u00e9placer vers le bas. L’avantage est que les scripts en ligne ne n\u00e9cessitent pas de requ\u00eates HTTP suppl\u00e9mentaires. Cependant, l’encha\u00eenement de scripts utilis\u00e9s dans plusieurs pages se traduirait par un code redondant.<\/li>\n<\/ul>\nEnvelopper les r\u00e8gles d’optimisation<\/h2>\n
\n
\n
link<\/code><\/li>\n\n
defer<\/code> sur les balises de script<\/li>\nasync<\/code> sur les balises de script<\/li>\nscript<\/code> vers le bas du document<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nOptimisation du chemin de rendu critique dans WordPress<\/h2>\n
W3 Total Cache<\/h3>\n
![\"Extension](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/extension-wordpress-w3-total-cache.jpg\")
<\/a>\n
async<\/code> et defer<\/code><\/li>\n![\"R\u00e9glages](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/regales-w3-total-cache-minification-javascript.png\")
WP Super Cache<\/h3>\n
![\"Extension](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/extension-wordpress-wp-super-cache.png\")
<\/a>![\"Testeur](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/testeur-wordpress-super-cache.png\")
async<\/code> et defer<\/code>. Cependant, plus d’un million d’installations actives prouvent que l\u2019extension vaut la peine d’\u00eatre essay\u00e9e.<\/p>\n![\"Option](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/option-gzip-wp-super-cache.png\")
Autoptimize<\/h3>\n
![\"Extension](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/extension-wordpress-autoptimize.jpg\")
<\/a>![\"Option](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/option-optimisation-html-autoptimize.png\")
\n
Swift Performance<\/h3>\n
![\"Extension](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2017\/11\/extension-wordpress-swift-performance.png\")
<\/a>\n
Conclusions<\/h2>\n
\n