Optimisation des performances du site Web et du chemin de rendu critique

Les performances de rendu de votre page Web répondent-elles aux normes actuelles ? Le rendu est le processus de traduction de la réponse d'un serveur dans l'image que le navigateur "peint" lorsqu'un utilisateur visite un site Web. Une mauvaise performance de rendu peut se traduire par un taux de rebond relativement élevé.

Il existe différentes réponses de serveur qui déterminent si une page est rendue ou non. Dans cet article, nous allons nous concentrer sur le rendu initial de la page Web, qui commence par l'analyse HTML (à condition que le navigateur ait reçu avec succès HTML comme réponse du serveur). Nous explorerons les éléments qui peuvent entraîner des temps de rendu élevés et comment les résoudre.

Chemin de rendu critique

Le chemin de rendu critique (CRP) est le processus suivi par votre navigateur pour convertir le code en pixels affichables sur votre écran. Il comporte plusieurs étapes, dont certaines pourraient être réalisées en parallèle pour gagner du temps, mais certaines parties doivent être réalisées en conséquence. Le voici visualisé :

Tout d'abord, une fois que le navigateur reçoit la réponse, il commence à l'analyser. Lorsqu'il rencontre une dépendance, il essaie de la télécharger.

S'il s'agit d'un fichier de feuille de style, le navigateur devra l'analyser complètement avant de rendre la page, et c'est pourquoi on dit que CSS bloque le rendu .

S'il s'agit d'un script, le navigateur doit : arrêter l'analyse, télécharger le script et l'exécuter. Ce n'est qu'après cela qu'il peut continuer l'analyse, car les programmes JavaScript peuvent modifier le contenu d'une page Web (HTML, en particulier). Et c'est pourquoi JS est appelé parser blocking .

Une fois que toute l'analyse est terminée, le navigateur a construit le modèle d'objet de document (DOM) et le modèle d'objet de feuilles de style en cascade (CSSOM). Leur combinaison donne l'arbre de rendu. Les parties non affichées de la page n'entrent pas dans l'arborescence de rendu, car elles ne contiennent que les données nécessaires pour dessiner la page.

L'avant-dernière étape consiste à traduire l'arborescence de rendu en mise en page. Cette étape est également appelée Reflow. C'est là que chaque position de chaque nœud de l'arbre de rendu, ainsi que sa taille, est calculée.

Enfin, la dernière étape est Paint. Il s'agit littéralement de colorer les pixels en fonction des données que le navigateur a calculées lors des étapes précédentes.

Conclusions liées à l'optimisation

Comme vous pouvez le deviner, le processus d'optimisation des performances du site Web implique des modifications du site Web qui réduisent :

• La quantité de données à transférer
• Le nombre de ressources que le navigateur doit télécharger (en particulier celles qui bloquent)
• La durée du CRP

Plus loin, nous plongerons dans les détails de la façon dont cela se fait, mais d'abord, il y a une règle importante à observer.

Comment mesurer les performances

Une règle d'optimisation importante est : mesurez d'abord, optimisez si nécessaire . La plupart des outils de développement des navigateurs ont un onglet appelé Performance , et c'est là que les mesures se produisent. Lors de l'optimisation pour le rendu initial (le premier) le plus rapide, la chose la plus importante à regarder est l'heure des événements suivants :

• Première peinture
• Première peinture contente
• Première peinture significative

Ici, "Peindre" signifie un rendu réussi d'une page, la dernière étape du chemin de rendu critique. Quelques rendus peuvent se produire les uns après les autres car les navigateurs essaient d'afficher quelque chose dès que possible et de se mettre à jour plus tard.

Outre le temps de rendu, il y a d'autres éléments à prendre en compte, notamment le nombre de ressources de blocage utilisées et le temps nécessaire pour les télécharger. Ces informations se trouvent dans l'onglet Performances une fois les mesures effectuées.

Stratégies d'optimisation des performances

Compte tenu de ce que nous avons appris ci-dessus, il existe trois principales stratégies d'optimisation des performances d'un site Web :

1. Minimiser la quantité de données à transférer sur le fil,
2. Réduire le nombre total de ressources à transférer sur le fil, et
3. Raccourcissement du chemin de rendu critique

1. Minimiser la quantité de données à transférer

Tout d'abord, supprimez toutes les parties inutilisées, telles que les fonctions inaccessibles en JavaScript, les styles avec des sélecteurs qui ne correspondent jamais à aucun élément et les balises HTML qui sont masquées à jamais avec CSS. Deuxièmement, supprimez tous les doublons.

Ensuite, je recommande de mettre en place un processus automatique de minification. Par exemple, il doit supprimer tous les commentaires de ce que votre serveur principal sert (mais pas le code source) et chaque caractère qui ne porte aucune information supplémentaire (comme les caractères d'espacement dans JS).

Une fois cela fait, ce qui nous reste peut être sous forme de texte. Cela signifie que nous pouvons appliquer en toute sécurité un algorithme de compression tel que GZIP (que la plupart des navigateurs comprennent).

Enfin, il y a la mise en cache. Cela n'aidera pas la première fois qu'un navigateur affichera la page, mais cela vous fera économiser beaucoup lors des visites suivantes. Il est cependant crucial de garder deux choses à l'esprit :

• Si vous utilisez un CDN, assurez-vous que la mise en cache est prise en charge et correctement définie ici.
• Au lieu d'attendre la date d'expiration des ressources, vous voudrez peut-être avoir un moyen de la mettre à jour plus tôt de votre côté. Intégrez les "empreintes digitales" des fichiers dans leurs URL pour pouvoir invalider le cache local.

Bien sûr, les politiques de mise en cache doivent être définies par ressource. Certains pourraient rarement changer ou ne jamais changer du tout. D'autres changent plus vite. Certains contiennent des informations sensibles, d'autres pourraient être considérés comme publics. Utilisez la directive « privé » pour empêcher les CDN de mettre en cache des données privées.

L'optimisation des images Web peut également être effectuée, bien que les demandes d'images ne bloquent ni l'analyse ni le rendu.

2. Réduire le nombre total de ressources critiques

"Critique" fait référence uniquement aux ressources nécessaires pour que la page Web s'affiche correctement. Par conséquent, nous pouvons ignorer tous les styles qui ne sont pas directement impliqués dans le processus. Et tous les scripts aussi.

Feuilles de style

Afin d'indiquer au navigateur que des fichiers CSS particuliers ne sont pas nécessaires, nous devons définir des attributs de media sur tous les liens référençant des feuilles de style. Avec cette approche, le navigateur ne traitera que les ressources qui correspondent au media actuel (type d'appareil, taille d'écran) selon les besoins, tout en abaissant la priorité de toutes les autres feuilles de style (elles seront traitées de toute façon, mais pas dans le cadre du rendu critique chemin). Par exemple, si vous ajoutez l'attribut media="print" à la balise de style qui fait référence aux styles d'impression de la page, ces styles n'interféreront pas avec votre chemin de rendu critique lorsque le média n'est pas print (c'est-à-dire lors de l'affichage du page dans un navigateur).

Pour améliorer encore le processus, vous pouvez également aligner certains styles. Cela nous évite au moins un aller-retour vers le serveur qui aurait autrement été nécessaire pour obtenir la feuille de style.

Scénarios

Comme mentionné ci-dessus, les scripts bloquent l'analyseur car ils peuvent modifier DOM et CSSOM. Par conséquent, les scripts qui ne les modifient pas ne doivent pas être bloqués, ce qui nous fait gagner du temps.

Pour implémenter cela, toutes les balises de script doivent être marquées avec des attributs, soit async ou defer .

Les scripts marqués avec async ne bloquent pas la construction DOM ou CSSOM, car ils peuvent être exécutés avant la construction de CSSOM. Gardez à l'esprit, cependant, que les scripts en ligne bloqueront de toute façon CSSOM, sauf si vous les placez au-dessus de CSS.

En revanche, les scripts marqués avec defer seront évalués à la fin du chargement de la page. Par conséquent, ils ne doivent pas affecter le document (sinon, cela déclenchera un nouveau rendu).

En d'autres termes, avec defer , le script n'est exécuté qu'après le déclenchement de l'événement de chargement de page, tandis que async permet au script de s'exécuter en arrière-plan pendant l'analyse du document.

3. Raccourcir la longueur du chemin de rendu critique

Enfin, la longueur du CRP doit être raccourcie au minimum possible. En partie, les approches décrites ci-dessus le feront.

Les requêtes multimédias en tant qu'attributs pour les balises de style réduiront le nombre total de ressources à télécharger. Les attributs de balise de script defer et async empêcheront les scripts correspondants de bloquer l'analyse.

Les ressources de minification, de compression et d'archivage avec GZIP réduiront la taille des données transférées (réduisant ainsi le temps de transfert des données également).

L'intégration de certains styles et scripts peut réduire le nombre d'allers-retours entre le navigateur et le serveur.

Ce dont nous n'avons pas encore discuté, c'est la possibilité de réorganiser le code parmi les fichiers. Selon la dernière idée des meilleures performances, la première chose qu'un site Web devrait faire le plus rapidement est d'afficher le contenu ATF. ATF signifie au-dessus du pli. C'est la zone visible immédiatement, sans défilement. Par conséquent, il est préférable de réorganiser tout ce qui concerne le rendu de manière à ce que les styles et les scripts requis soient chargés en premier, tout le reste s'arrêtant - ni l'analyse ni le rendu. Et rappelez-vous toujours de mesurer avant et après avoir effectué le changement.

Conclusion : l'optimisation englobe l'ensemble de votre pile

En résumé, l'optimisation des performances du site Web intègre tous les aspects de la réponse de votre site, tels que la mise en cache, la mise en place d'un CDN, la refactorisation, l'optimisation des ressources et autres, mais tout cela peut être fait progressivement. En tant que développeur Web, vous devez utiliser cet article comme référence et n'oubliez pas de mesurer les performances avant et après vos expériences.

Les développeurs de navigateurs font de leur mieux pour optimiser les performances du site Web pour chaque page que vous visitez, c'est pourquoi les navigateurs implémentent généralement ce que l'on appelle le "pré-chargeur". Cette partie des programmes analyse avant une ressource que vous avez demandée en HTML afin de faire plusieurs requêtes à la fois et de les exécuter en parallèle. C'est pourquoi il est préférable de garder les balises de style proches les unes des autres en HTML (par ligne), ainsi que les balises de script.

De plus, essayez de regrouper les mises à jour HTML afin d'éviter plusieurs événements de mise en page, qui sont déclenchés non seulement par un changement de DOM ou de CSSOM, mais également par un changement d'orientation de l'appareil et un redimensionnement de la fenêtre.

Ressources utiles et lectures complémentaires :

• Informations sur la vitesse de la page
• Liste de vérification de la mise en cache
• Un moyen de tester si GZIP est activé pour votre site Web
• Réseautage de navigateur haute performance : un livre d'Ilya Grigorik