Lors de votre dernier test sur GT Metrix ou Page Speed Insight, vous avez peut-être eu la notice ci-dessous et vous vous demandez qu’est ce que c’est, mais surtout comment résoudre ce problème pour augmenter la vitesse de votre site web.
Les ressources bloquant le rendu sont des fichiers statiques, tels que des polices, des fichiers HTML, CSS et JavaScript, qui sont essentiels au processus de rendu d’une page Web.
Lorsque le navigateur rencontre une ressource bloquant le rendu, il arrête de télécharger le reste des ressources jusqu’à ce que ces fichiers critiques soient traités.
Pendant ce temps, l’ensemble du processus de rendu est mis en attente. En revanche, les ressources qui ne bloquent pas le rendu ne retardent pas le rendu de la page.
Le navigateur peut les télécharger en toute sécurité en arrière-plan après le rendu initial de la page.
Cependant, toutes les ressources que le navigateur considère comme bloquant le rendu ne sont pas essentielles pour le premier rendu ; tout dépend des caractéristiques individuelles de la page.
Il existe des bonnes pratiques que vous pouvez utiliser pour transformer ces ressources non critiques bloquant le rendu en ressources ne bloquant pas le rendu.
En outre, vous pouvez également diminuer le nombre et/ou la taille des ressources bloquant le rendu qui sont toujours critiques et ne peuvent pas être éliminées.
Sommaire
Pourquoi éliminer les ressources bloquant le rendu ?
Si vous réduisez le nombre de ressources bloquant le rendu, vous pouvez raccourcir le chemin de rendu critique et réduire les temps de chargement des pages, améliorant ainsi l’expérience de l’utilisateur et l’optimisation des moteurs de recherche.
Il existe trois façons de réduire le nombre et l’impact des ressources bloquant le rendu :
- En faire des ressources non bloquantes pour le rendu en différant leur téléchargement.
- Diminuer le nombre total de ressources bloquant le rendu en utilisant des techniques telles que le regroupement (ce qui signifie également moins de requêtes HTTP).
- Réduisez la taille d’une ressource en la minifiant afin que la page ait moins d’octets à charger.
Améliorez la vitesse de votre site web en 5 minutes avec le plugin WordPress WP Rocket.
Les 5 types de ressources bloquant le rendu
En règle générale, le navigateur traite tout ce qu’il trouve dans la section <head> d’une page HTML comme une ressource bloquant le rendu.
Cela inclut :
- les feuilles de style CSS
- les fichiers JavaScript ajoutés dans la section <head>.
- les polices ajoutées depuis un CDN ou un serveur local
- les importations HTML (même si les importations HTML sont désormais obsolètes, vous pouvez encore les rencontrer sur des pages anciennes)
Les images, les fichiers multimédia et les balises <script> placés au bas de la section <body> sont traités comme des ressources ne bloquant pas le rendu.
Faisons maintenant un zoom sur cinq stratégies pour éliminer ou réduire le nombre et l’impact des ressources bloquant le rendu.
1. N’ajoutez pas de CSS avec la règle @import
Vous pouvez ajouter un CSS à une page en utilisant l’une des deux méthodes suivantes :
- La balise <link rel=“stylesheet”> que vous devez ajouter à votre fichier HTML.
- La règle @import que vous devez ajouter à votre fichier CSS.
Même si la règle @import permet de garder votre fichier HTML plus propre et de conserver toutes vos dépendances CSS au même endroit, ce n’est pas le meilleur choix en termes de performances. La règle @import vous permet d’importer des feuilles de style d’autres feuilles de style, mais cela ralentit le traitement de votre fichier CSS par le navigateur, car il doit également télécharger les fichiers importés.
Tant que ce téléchargement n’aura pas eu lieu, le processus de rendu sera bloqué.
Si vous souhaitez ajouter plus d’un fichier CSS à votre page, vous pouvez soit utiliser la balise <link>, soit enchaîner les fichiers à l’aide d’un outil de minification et/ou de regroupement.
Vous devez ajouter l’élément <link> à la section <head> de la page HTML de la manière suivante :
<head>
<link href="style.css" rel="stylesheet">
</head>
2. Utiliser l’attribut media pour le CSS conditionnel
Par défaut, le navigateur traite tous les fichiers CSS comme des ressources bloquant le rendu. Toutefois, si vous ajoutez l’attribut media à la balise <link>, vous pouvez indiquer au navigateur la présence d’un fichier CSS conditionnel.
Le CSS conditionnel ne s’applique que dans certaines conditions, par exemple en dessous ou au-dessus d’une taille de fenêtre donnée ou sur une page imprimée. Avec l’attribut media, vous pouvez définir une condition de média spécifique pour un fichier CSS. Vous pouvez utiliser n’importe quelle valeur que vous utiliseriez pour une requête de média dans un fichier CSS.
Par exemple :
<link href="print.css" rel="stylesheet" media="print">
<link href="large.css" rel="stylesheet" media="screen and (min-width: 1500px)">
<link href="mobile.css" rel="stylesheet" media="screen and (max-width: 600px)">
Même si ces fichiers sont toujours téléchargés sur tous les appareils, ils deviennent des ressources ne bloquant pas le rendu si la condition est évaluée comme fausse. Cependant, ils seront toujours bloquants pour le rendu si la condition est évaluée comme vraie.
Par exemple, la feuille de style mobile.css de l’exemple ci-dessus sera bloquante pour le rendu sur les appareils mobiles dont la largeur maximale de la fenêtre d’affichage est de 600px et non bloquante pour les fenêtres d’affichage supérieures à 600px.
Si vous avez un fichier CSS existant avec une ou plusieurs requêtes média, vous pouvez extraire toutes les règles @media et les enregistrer dans des fichiers séparés à l’aide de ce plugin PostCSS. Cette technique d’optimisation des performances est également appelée fractionnement du code.
Bien que le fractionnement du code soit généralement associé à JavaScript, vous pouvez également fractionner des fichiers CSS plus volumineux et ne charger chaque fichier que lorsque cela est nécessaire afin de raccourcir le chemin de rendu critique et de réduire le temps de chargement initial de la page.
3. Utilisez les attributs defer et async pour éliminer les JavaScript bloquant le rendu.
Les fichiers JavaScript ajoutés à la section <head> du document sont traités par défaut comme des ressources bloquant le rendu.
Vous pouvez les retirer du chemin de rendu critique en plaçant les balises <script> juste avant la balise de fermeture </body> au lieu de la section <head>.
Dans ce cas, ils ne commencent à se télécharger qu’après le téléchargement de l’ensemble du HTML. Cependant, comme le téléchargement de ces scripts commence plus tard, les éléments qu’ils chargent, comme les publicités, les animations ou les fonctionnalités dynamiques, peuvent se charger plus tard que le reste du frontend – surtout s’il s’agit d’un script plus long. Cela peut entraîner des retards notables et des interfaces utilisateur qui traînent sur des connexions plus lentes, ce qui est mauvais pour l’expérience utilisateur.
Les attributs defer et async de la balise <script> offrent une solution à ce problème. Ce sont tous deux des attributs booléens, ce qui signifie que si vous les ajoutez, ils se déclencheront sans autre configuration. Ils permettent également aux scripts ajoutés à la section <head> d’un document HTML de ne pas bloquer le rendu, mais d’une manière différente – les scripts différés respectent l’ordre du document tandis que les scripts asynchrones sont indépendants du DOM.
L’attribut defer indique au navigateur de télécharger le script en arrière-plan afin qu’il ne bloque pas le rendu de la page. Le script différé s’exécute une fois que le DOM est prêt mais avant que l’événement DOMContentLoaded ne se déclenche.
<script src="script01.js" defer></script>
<script src="script02.js" defer></script>
Les scripts différés suivent l’ordre du document, tout comme les scripts par défaut, non différés. Ainsi, dans l’exemple ci-dessus, script01.js sera exécuté en premier, quel que soit le script qui se charge en premier. Vous ne pouvez pas ajouter defer aux scripts en ligne ; cela ne fonctionne qu’avec les scripts externes qui spécifient l’emplacement du script à l’aide de l’attribut src.
D’autre part, l’attribut async informe le navigateur qu’un script est totalement indépendant de la page. Il sera téléchargé en arrière-plan en tant que ressource ne bloquant pas le rendu, tout comme les scripts différés.
Cependant, contrairement aux scripts différés, les scripts asynchrones ne suivent pas l’ordre du document, ils s’exécutent donc dès que leur téléchargement est terminé, ce qui peut arriver à tout moment.
Par exemple, dans l’exemple ci-dessous, nous ne pouvons pas être sûrs du script qui sera exécuté en premier ; cela dépend uniquement de celui qui se télécharge le plus rapidement (généralement le plus petit). N’oubliez pas que les scripts asynchrones sont indépendants à la fois du document et les uns des autres, donc l’ordre du document n’aura aucun impact sur eux.
<script src="script03.js" async></script>
<script src="script04.js" async></script>
L’attribut defer est recommandé pour les scripts qui ont besoin du DOM, mais que vous voulez commencer à télécharger avant le chargement du document, sans en faire une ressource bloquant le rendu. Vous devriez également utiliser defer plutôt qu’async si l’ordre du document est important – par exemple, lorsque des scripts consécutifs dépendent les uns des autres.
L’attribut async est recommandé pour les scripts tiers indépendants, tels que les annonces, les trackers et les scripts d’analyse. Par exemple, Google Analytics recommande d’ajouter l’attribut async pour prendre en charge le chargement asynchrone dans les navigateurs modernes.
4. Réduisez et regroupez les CSS et JavaScript
En plus de supprimer les CSS et JavaScript non essentiels du chemin de rendu critique, vous pouvez également réduire et regrouper les ressources bloquant le rendu et celles qui ne le bloquent pas.
Par exemple, vous pouvez créer des groupes pour les fichiers qui utilisent les mêmes règles de chargement et minifier chaque paquet séparément. Comme les fichiers minifiés sont plus légers et que les groupes impliquent moins de fichiers dans le chemin de rendu critique, le rendu initial de la page se terminera plus rapidement.
En outre, le téléchargement en arrière-plan de ressources ne bloquant pas le rendu prendra moins de temps.
De nombreux outils sont disponibles pour vous aider à effectuer la minification et le regroupement selon les meilleures pratiques, notamment Minify, CSS Minifier, Minify Code et PostCSS.
5. Charger localement les polices personnalisées
Comme les polices personnalisées sont appelées à partir de la section <head> du document, elles constituent également des ressources bloquant le rendu.
Par exemple :
<link href="https://fonts.googleapis.com/css2?family=Lato&display=swap" rel="stylesheet">
Vous pouvez réduire l’impact des polices personnalisées sur le rendu initial de la page en les ajoutant localement plutôt qu’en les tirant d’un réseau de diffusion de contenu tel que le CDN de Google. Les fournisseurs de polices ont tendance à ajouter plusieurs règles @font-face, dont beaucoup ne sont pas nécessaires.
Par exemple, Google Fonts ajoute des règles @font-face pour tous les jeux de caractères fournis avec un caractère, tels que le latin, le cyrillique, le chinois, le vietnamien, etc. Imaginons, par exemple, que le fichier CSS en ligne que vous ajoutez avec la balise <link> comprenne des règles @font-face pour sept jeux de caractères différents, mais que vous ne souhaitiez en utiliser qu’un seul (par exemple, le latin). Cependant, les polices Google Fonts ne téléchargent pas les fichiers de polices pour tous les jeux de caractères ; elles ajoutent simplement de nombreuses règles @font-face redondantes au fichier CSS.
Si vous ajoutez les polices localement, vous pouvez également réduire votre CSS relatif aux polices et le regrouper avec le reste de votre CSS. Vous pouvez utiliser l’aide Google Web Fonts Helper pour générer rapidement des règles @font-face locales pour les polices Google Fonts.
Par exemple, voici ce que vous devez ajouter pour inclure le visage de la police Lato Regular :
/* lato-regular - latin */
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'),
url('../fonts/lato-v16-latin-regular.woff2') format('woff2'),
url('../fonts/lato-v16-latin-regular.woff') format('woff');
}
Notez que Google Web Fonts Helper n’ajoute pas la règle font-display : swap ; je l’ai ajoutée moi-même à la déclaration ci-dessus. Il s’agit d’un descripteur de la règle @font-face qui vous permet de spécifier comment le navigateur doit afficher la face de la police sur la page.
En utilisant font-display avec la valeur swap, vous demandez au navigateur de commencer immédiatement à utiliser une police système et de la remplacer par la police personnalisée dès qu’elle est téléchargée (cette règle est également ajoutée lorsque vous tirez la police du CDN de Google). Cela vous permet d’éviter d’avoir du texte invisible sur la page pendant que la police personnalisée est encore en cours de chargement.
Lorsque vous chargez des polices localement, veillez à servir des formats de police compressés pour les navigateurs modernes, tels que WOFF et WOFF2. N’oubliez pas que des fichiers plus légers réduisent également l’impact du blocage des ressources de rendu. Outre la génération des règles @font-face, Google Web Fonts Helper vous permet également de télécharger un fichier zippé qui contient tous les formats de police dont vous avez besoin.
Résumé sur les ressources bloquant le rendu
Dans cet article, nous avons abordé cinq stratégies pour éliminer les ressources bloquant le rendu. Pour résumer :
- N’utilisez pas d’importations CSS
- Chargez les CSS conditionnels avec les attributs media
- Utilisez les attributs defer et async pour éliminer les JavaScript qui bloquent le rendu.
- Divisez, regroupez et réduisez les fichiers CSS et JavaScript.
- Chargez les polices personnalisées localement
Pour localiser vos fichiers bloquant le rendu, vous pouvez utiliser des outils d’analyse des performances tels que Lighthouse, web.dev (le même outil que Lighthouse, mais intégré à une application Web), GTmetrix, etc. En plus de vous aider à trouver des ressources de blocage de rendu, ces outils offrent des conseils pratiques pour vous aider à améliorer les performances de votre site.
La liste des meilleures pratiques abordées dans cet article n’est pas exhaustive. Par exemple, il est également judicieux d’effectuer des audits réguliers du site Web afin de détecter et de supprimer le code inutilisé, qui peut avoir un impact considérable sur les temps de rendu initiaux des pages.
Pour améliorer les temps de chargement globaux des pages, vous pouvez également utiliser des indications de ressources et la directive de préchargement. Elles n’éliminent pas en soi les ressources bloquant le rendu, mais vous pouvez les utiliser pour améliorer les temps de chargement des pages.
Les ressources bloquant le rendu n’arrêteront pas le processus de récupération des ressources préchargées, et vous pouvez également vous préconnecter au CDN de Google pour accélérer le chargement des polices Web si vous ne souhaitez pas les charger localement.
