Ressources bloquant le rendu : définition et explications

Les ressources bloquant le rendu (render-blocking resources) sont des fichiers que le navigateur doit récupérer et traiter avant de pouvoir afficher quoi que ce soit à l’écran. Pendant leur chargement, le visiteur fixe une page blanche, alors même que le HTML est déjà arrivé.

Quelles ressources bloquent le rendu

• Les feuilles de style liées dans le head. Par défaut, le navigateur n’affiche rien tant qu’il n’a pas le CSS, pour éviter de montrer un contenu sans style.
• Les scripts classiques sans async, defer ni type="module". Ils bloquent l’analyseur HTML lui-même : le navigateur arrête de construire la page, télécharge le script, l’exécute, puis reprend.
• Les polices web, indirectement. Un texte mis en forme avec une police qui n’est pas chargée peut rester invisible jusqu’à trois secondes dans la plupart des navigateurs.

Chaque fichier bloquant ajoute au moins un aller-retour réseau avant le premier affichage, et sur les réseaux mobiles les allers-retours coûtent cher. Ce retard se répercute directement sur le Largest Contentful Paint.

Avant et après

<!-- Avant : tout bloque -->
<link rel="stylesheet" href="/css/all.css">
<script src="/js/slider.js"></script>
<script src="https://tags.example/analytics.js"></script>

<!-- Après -->
<style>/* CSS critique de la partie visible, quelques Ko */</style>
<link rel="stylesheet" href="/css/all.css" media="print" onload="this.media='all'">
<script src="/js/slider.js" defer></script>
<script src="https://tags.example/analytics.js" async></script>

Ce qui a changé :

• defer télécharge le script en parallèle et l’exécute après l’analyse du document, dans l’ordre d’apparition : c’est le choix sûr par défaut pour vos propres scripts (MDN : l’élément script).
• async exécute un script dès qu’il arrive, sans ordre particulier : adapté aux balises tierces indépendantes.
• Intégrer le CSS critique en ligne permet d’afficher immédiatement le premier écran. Une feuille de style dont le media ne correspond pas, comme print, se télécharge sans bloquer ; le basculement onload l’applique ensuite à l’écran.

Erreurs courantes

• Différer une bibliothèque dont dépend du code en ligne, ce qui produit des erreurs comme « jQuery is not defined ».
• Utiliser async pour des scripts qui dépendent les uns des autres. L’ordre d’exécution n’est pas garanti.
• Différer tout le CSS, ce qui provoque un flash de contenu sans style et des décalages de mise en page. Il faut bien que quelque chose mette en forme le premier écran.
• Des polices tierces sans preconnect, qui ajoutent du temps DNS et TLS au chemin critique.
• Peaufiner vos propres fichiers alors qu’une bannière de consentement ou un script de test A/B dans le head bloque tout. Certains outils de test bloquent exprès pour éviter le scintillement ; pesez ce coût honnêtement.

Comment établir les priorités

Commencez par tout ce qui se trouve dans le <head> sans être nécessaire au premier écran. Les balises tierces sont souvent les gains les plus faciles : beaucoup n’ont pas besoin de s’exécuter avant que le visiteur voie quoi que ce soit. Réduisez ensuite le CSS qui reste bloquant (les règles inutilisées d’un thème ou d’un framework sont courantes), pour que le chemin critique ne porte que ce que la première vue exige.

Les repérer sur votre page

Le test de vitesse de page liste les scripts et feuilles de style bloquant le rendu de votre page, avec le nombre et le poids des scripts et des styles : vous savez ainsi précisément quelles balises différer, intégrer ou supprimer. Pour la vue d’ensemble, voir vitesse de page.

Questions fréquentes