Optimiser le chargement des ressources

Dans le module précédent, quelques théories concernant le chemin critique du rendu étaient et comment les ressources bloquant l'affichage et l'analyseur peuvent retarder le rendu initial de la page. Maintenant que vous comprenez une partie de la théorie sous-jacente vous êtes prêt à vous familiariser avec quelques techniques pour optimiser le chemin de rendu.

Lors du chargement d'une page, de nombreuses ressources sont référencées dans son code HTML, ce qui fournit un avec son apparence et sa mise en page via CSS, ainsi que son interactivité. via JavaScript. Dans ce module, nous abordons un certain nombre de concepts importants ces ressources et leur impact sur le temps de chargement d'une page.

Blocage de l'affichage

Comme nous l'avons vu dans le module précédent, CSS est une ressource qui render-blocking. car il empêche le navigateur d'afficher du contenu jusqu'à ce que le CSS Object Model (CSSOM). Le navigateur bloque l'affichage pour éviter un Flash Contenu sans style (FOUC), ce qui n'est pas souhaitable du point de vue de l'expérience utilisateur.

Dans la vidéo précédente, il y a un bref FOUC où vous pouvez voir la page sans quel que soit le style. Par la suite, tous les styles sont appliqués une fois que le code CSS de la page se termine par le chargement à partir du réseau, et la version sans style de la page est immédiatement remplacé par la version stylisée.

De manière générale, une FOUC est quelque chose que l’on ne voit normalement pas, mais le concept est important à comprendre afin de comprendre pourquoi le navigateur bloque l'affichage jusqu'à ce que le code CSS soit téléchargé et appliqué à la page. Blocage de l'affichage n'est pas nécessairement indésirable, mais vous devez réduire au maximum sa durée pour que votre CSS soit optimisé.

Blocage de l'analyseur

Une ressource qui bloque l'analyseur interrompt l'analyseur HTML, par exemple <script>. sans attribut async ou defer. Lorsque l'analyseur rencontre un <script>, le navigateur doit évaluer et exécuter le script avant l'analyse du reste du code HTML. C'est logique, car les scripts peuvent modifier ou accéder au DOM pendant une période où il est encore en cours de construction.

<!-- This is a parser-blocking script: -->
<script src="/script.js"></script>

Lorsque vous utilisez des fichiers JavaScript externes (sans async ni defer), l'analyseur est est bloqué, à partir du moment où le fichier est découvert, et jusqu'à ce qu'il soit téléchargé, analysé et exécuté. Lorsque vous utilisez du code JavaScript intégré, l'analyseur est également bloqué jusqu'à ce que le script intégré est analysé et exécuté.

Analyseur de préchargement

L'outil d'analyse du préchargement permet d'optimiser le navigateur sous la forme d'un code HTML secondaire analyseur qui analyse la réponse HTML brute afin de la rechercher et de l'extraire de manière spéculative avant que l'analyseur HTML principal les découvre. Pour l'analyseur de préchargement permet au navigateur de télécharger ressource spécifiée dans un élément <img>, même lorsque l'analyseur HTML est bloqué. lors de l'extraction et du traitement des ressources telles que CSS et JavaScript.

Pour tirer le meilleur parti de l'analyseur de préchargement, les ressources critiques doivent être incluses dans le balisage HTML envoyé par le serveur. Les modèles de chargement de ressources suivants non détectable par l'analyseur de préchargement:

• Images chargées par CSS à l'aide de la propriété background-image Ces images sont en CSS et ne peuvent pas être détectées par l'outil d'analyse du préchargement.
• Scripts chargés dynamiquement sous la forme d'un balisage d'élément <script> injecté dans le DOM à l'aide de JavaScript ou de modules chargés à l'aide d'un import() dynamique.
• Code HTML affiché sur le client à l'aide de JavaScript. Ce balisage est contenu dans dans les ressources JavaScript et n'est pas visible par le préchargement. d'analyse.
• Déclarations @import du CSS.

Ces modèles de chargement de ressources sont tous des ressources récemment découvertes. ne bénéficient pas de l'analyseur de préchargement. Évitez-les autant que possible. Si il est impossible d'éviter ces comportements, mais vous pouvez utiliser un Indice preload pour éviter les retards de découverte des ressources.

CSS

Le CSS détermine la présentation et la mise en page d'une page. Comme décrit précédemment, CSS est une ressource qui bloque l'affichage. Par conséquent, l'optimisation de votre code CSS sur le temps de chargement global de la page.

Réduction

Réduire la taille des fichiers CSS permet de réduire la taille de fichier d'une ressource CSS. plus rapide à télécharger. Pour cela, nous supprimons le contenu d'une le fichier CSS source, comme des espaces et d'autres caractères invisibles, et la sortie le résultat dans un fichier récemment optimisé:

/* Unminified CSS: */

/* Heading 1 */
h1 {
  font-size: 2em;
  color: #000000;
}

/* Heading 2 */
h2 {
  font-size: 1.5em;
  color: #000000;
}

/* Minified CSS: */
h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}

Dans sa forme la plus basique, la minimisation CSS est une optimisation efficace qui pourrait améliorer le FCP de votre site web, voire même le LCP dans certains cas. Des outils tels que Les bundleers peuvent effectuer automatiquement cette optimisation en production. compilations.

Supprimer les ressources CSS inutilisées

Avant d'afficher un contenu, le navigateur doit tout télécharger et analyser feuilles de style. Le temps nécessaire pour effectuer l'analyse inclut également les styles ne sont pas utilisés sur la page active. Si vous utilisez un bundler qui combine tous les CSS ressources dans un seul fichier, il est probable que vos utilisateurs téléchargent plus de CSS nécessaires pour afficher la page actuelle.

Pour découvrir les CSS inutilisés pour la page actuelle, utilisez l'outil Couverture dans Chrome. DevTools.

</ph> <ph type="x-smartling-placeholder">

Supprimer les fichiers CSS inutilisés a un double effet: en plus de réduire le nombre de téléchargements vous optimisez la construction de l'arborescence de rendu, car le navigateur doit moins de règles CSS.

Éviter les déclarations CSS @import

Bien que cela puisse sembler pratique, vous devriez éviter les déclarations @import en CSS:

/* Don't do this: */
@import url('style.css');

Comme pour l'élément <link> en HTML, la déclaration @import de CSS vous permet d'importer une ressource CSS externe à partir d'une feuille de style. La la principale différence entre ces deux approches est que l'élément HTML <link> fait partie de la réponse HTML et est donc découvert beaucoup plus tôt qu'un CSS téléchargé par une déclaration @import.

En effet, pour qu'une déclaration @import soit découverte, le fichier CSS qui le contient doit d'abord être téléchargé. Ce entraîne ce qu'on appelle une chaîne de demande qui, dans le cas du CSS, retarde le temps nécessaire pour qu'une page s'affiche initialement. Un autre inconvénient est que les feuilles de style chargées à l'aide d'une déclaration @import ne peuvent pas être détectées par qui bloquent le rendu, et deviennent donc des ressources découvertes tardivement.

<!-- Do this instead: -->
<link rel="stylesheet" href="style.css">

Dans la plupart des cas, vous pouvez remplacer @import en utilisant un Élément <link rel="stylesheet">. Les éléments <link> permettent d'ajouter des feuilles de style téléchargée simultanément et réduit le temps de chargement global, contrairement à @import. , qui télécharge les feuilles de style consécutivement.

Intégrer les fichiers CSS critiques

Le temps de téléchargement des fichiers CSS peut augmenter le FCP d'une page. Intégrer styles critiques dans le document <head> élimine la requête réseau pour une ressource CSS et, lorsqu'elle est correctement effectuée, peut améliorer les temps de chargement initiaux lorsqu'une le cache du navigateur de l'utilisateur n'est pas prêt. Le CSS restant peut être chargé de manière asynchrone ou ajoutée à la fin de l'élément <body>.

<head>
  <title>Page Title</title>
  <!-- ... -->
  <style>h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}</style>
</head>
<body>
  <!-- Other page markup... -->
  <link rel="stylesheet" href="non-critical.css">
</body>

En revanche, l'intégration d'une grande quantité de CSS ajoute davantage d'octets au fichier Réponse HTML. Souvent, les ressources HTML ne peuvent pas être mises en cache très longtemps Cela signifie que le CSS intégré n'est pas mis en cache pour les pages suivantes utiliser le même code CSS dans les feuilles de style externes. Testez et mesurez les performances les performances pour s'assurer que les compromis en valent la peine.

Démonstrations CSS

JavaScript

JavaScript génère la majeure partie de l'interactivité sur le Web, mais a un coût. Si vous envoyez trop de code JavaScript, votre page Web risque de ralentir le chargement de la page. et peuvent même causer des problèmes de réactivité qui ralentissent les interactions, ce qui peut être frustrant pour les utilisateurs.

Code JavaScript bloquant l'affichage

Lors du chargement d'éléments <script> sans les attributs defer ou async, le navigateur bloque l'analyse et l'affichage jusqu'à ce que le script soit téléchargé, analysé exécuté. De même, les scripts intégrés bloquent l'analyseur jusqu'à ce que le script soit analysé. et exécuté.

async et defer

async et defer autorisent le chargement des scripts externes sans bloquer le code HTML. analyseur, tandis que les scripts (y compris les scripts intégrés) avec type="module" sont automatiquement. Cependant, async et defer présentent des différences qui qu’il est important de comprendre.

</ph> <ph type="x-smartling-placeholder">

Les scripts chargés avec async sont analysés et exécutés immédiatement après leur téléchargement. tandis que les scripts chargés avec defer sont exécutés lorsque l'analyse de document HTML est terminé : l'événement se produit en même temps que l'événement DOMContentLoaded du navigateur. De plus, les scripts async peuvent s'exécuter dans le désordre, tandis que les scripts defer sont exécutés dans l'ordre dans lequel ils apparaissent dans le balisage.

Rendu côté client

En règle générale, vous devez éviter d'utiliser JavaScript pour afficher du contenu essentiel ou une l'élément LCP de la page. C'est ce qu'on appelle le rendu côté client. Il s'agit d'une technique largement utilisée dans les applications monopages (SPA).

Le balisage rendu par JavaScript ignore l'outil d'analyse de préchargement, car les ressources contenues dans le balisage affiché par le client ne sont pas visibles par celui-ci. Ce pourrait retarder le téléchargement de ressources essentielles, comme une image LCP. Le navigateur ne commence à télécharger l'image LCP qu'après l'exécution du script et ajouté l'élément dans le DOM. De son côté, le script ne peut être exécuté qu'après avoir découvert, téléchargé et analysé. C'est ce qu'on appelle une requête critique. chaîne et doit être évitée.

De plus, le balisage à l'aide de JavaScript a plus de chances de générer de longues tâches que le balisage téléchargé depuis le serveur en réponse à une navigation requête. Une utilisation intensive du rendu HTML côté client peut avoir un impact négatif la latence d'interaction. Cela est particulièrement vrai lorsque le DOM d'une page est Très grande, ce qui entraîne une surcharge de rendu lorsque JavaScript modifie le DOM.

Réduction

Comme pour le CSS, la réduction de la taille des ressources JavaScript permet de réduire la taille du fichier d'une ressource de script. Cela peut accélérer les téléchargements et permettre au navigateur de passer plus rapide d'analyse et de compilation JavaScript.

En outre, la minimisation de JavaScript va plus loin que la minimisation. d'autres éléments, tels que des fichiers CSS. Lorsque la taille du code JavaScript est réduite, il n'est pas seulement supprimé. tels que les espaces, les tabulations et les commentaires, mais les symboles dans la source JavaScript sont abrégés. Ce processus est parfois appelé uglification. À voyez la différence, prenez le code source JavaScript suivant:

// Unuglified JavaScript source code:
export function injectScript () {
  const scriptElement = document.createElement('script');
  scriptElement.src = '/js/scripts.js';
  scriptElement.type = 'module';

  document.body.appendChild(scriptElement);
}

Une fois le code source JavaScript précédent amélioré, le résultat peut sembler l'extrait de code suivant:

// Uglified JavaScript production code:
export function injectScript(){const t=document.createElement("script");t.src="/js/scripts.js",t.type="module",document.body.appendChild(t)}

Dans l'extrait précédent, vous pouvez voir que la variable lisible par l'humain Dans la source, scriptElement est abrégé en t. Lorsqu'elle est appliquée à un grand de scripts, vous pouvez réaliser des économies considérables, les fonctionnalités que fournit le code JavaScript de production d'un site Web.

Si vous utilisez un bundler pour traiter le code source de votre site Web, se fait souvent automatiquement pour les builds de production. Uglificateurs, tels que Terser, par exemple) sont également hautement configurables, ce qui vous permet d'ajuster l'utilisation de l'algorithme d'optimisation pour atteindre un maximum d'économies. Cependant, les valeurs par défaut des outils d'optimisation suffisent généralement le juste équilibre entre taille de sortie et conservation des capacités.

Démonstrations JavaScript

Tester vos connaissances

Prochaine étape: aider le navigateur avec des indices de ressources

Maintenant que vous savez comment les ressources chargées dans l'élément <head> peuvent affectent le chargement initial de la page et d'autres métriques, il est temps de passer à autre chose. Dans dans le module, des indices de ressources sont abordés et la manière dont ils peuvent que le navigateur commence à charger des ressources et à ouvrir des connexions en multi-origine les serveurs plus tôt que le navigateur ne le ferait autrement sans eux.