Corriger l'avertissement Lighthouse eliminate render-blocking resources
Débarrassez-vous des ressources bloquant le rendu et améliorez les Core Web Vitals
'Eliminate render-blocking resources' en bref
Lorsqu'un navigateur rencontre des CSS ou JavaScript bloquant le rendu (render-blocking) dans le <head>, il arrête tout. Aucun pixel n'est peint tant que ces ressources n'ont pas fini d'être téléchargées et exécutées. C'est ce que vous dit l'avertissement 'Eliminate render-blocking resources' dans Lighthouse : quelque chose dans votre <head> retarde le premier paint.
Corrigez cet avertissement Lighthouse en supprimant ou en différant (deferring) ces ressources bloquant le rendu. Selon le Web Almanac 2025, seulement 15 % des pages mobiles réussissent cet audit. Cela représente 85 % du web avec des retards de rendu inutiles.
Qu'est-ce que l'avertissement Lighthouse 'Eliminate render-blocking resources' ?
Dernière révision par Arjen Karel en mars 2026
Qu'est-ce qui cause l'avertissement Eliminate render-blocking resources dans Lighthouse ? Lighthouse signale les pages qui ont soit :
- Une balise script dans le head qui n'est pas différée (deferred).
Les scripts dans le head de la page bloquent le rendu par défaut s'ils n'ont pas l'attribut defer ou async. - Une feuille de style (stylesheet) liée qui correspond aux médias de l'appareil (device media).
Un <link rel="stylesheet"> bloquera le rendu de la page s'il n'est pas désactivé et correspond au média du navigateur. Par exemple <link rel="stylesheet" media="print"> ne bloquera pas le rendu sur les appareils à écran.
Trop de ressources bloquant le rendu affecteront très probablement le First Contentful Paint (FCP) et le Largest Contentful Paint (LCP) directement. Vodafone a réduit le JavaScript bloquant le rendu et a constaté une amélioration de 31 % du LCP, ce qui s'est traduit par une augmentation de 8 % des ventes.
Selon le Web Performance Calendar, 67,7 % des sites web chargent au moins un tiers (third party) bloquant le rendu. Les Google Fonts à elles seules sont responsables de requêtes bloquant le rendu sur plus de 5,8 millions de sites.
Qu'est-ce qui cause les 'render-blocking resources' ?
Les ressources bloquant le rendu sont toujours des feuilles de style et des JavaScripts dans le head de la page. Cela signifie qu'elles ne peuvent être ajoutées que par votre CMS, par votre développeur web ou par un plugin. Lorsque vous essayez de trouver l'origine d'une ressource bloquant le rendu, essayez de chercher dans ces endroits :
- Le template. Le template de votre site web est le premier endroit où chercher. Trouvez l'endroit où se trouve le code <head> et cherchez les styles et scripts codés en dur (hardcoded).
- Le CMS. Parfois, le CMS lui-même nécessite certains scripts (par exemple jQuery) pour fonctionner correctement.
- Les plugins. Les plugins sont connus pour injecter des styles et des scripts dans la page. Même lorsqu'un plugin n'est utilisé que sur une seule page, il charge souvent ses ressources sur toutes les pages.
Le chapitre JavaScript du Web Almanac 2024 (l'édition la plus récente avec des données au niveau du script) a révélé que, bien que 87 % des pages utilisent async sur au moins un script, seules 49 % des balises de script individuelles l'ont réellement. Et seulement 13 % des scripts utilisent defer. La plupart des scripts sur le web sont encore chargés sans l'un ou l'autre des attributs, ce qui signifie qu'ils bloquent le rendu.
Comment corriger 'Eliminate render-blocking resources'
Pour corriger les ressources bloquant le rendu, vous devez vous assurer qu'elles ne bloquent plus le rendu. La meilleure solution consiste à supprimer complètement la ressource. Les anciens scripts et feuilles de style inutilisés qui sont toujours dans le <head> sont plus courants que vous ne le pensez. Si vous ne pouvez pas les supprimer, différez-les (defer).
Différer le JavaScript
Le JavaScript peut être différé en ajoutant l'attribut defer ou async à la balise de script.
<!-- deferred : télécharge en parallèle, s'exécute après l'analyse HTML, dans l'ordre --> <script defer src="script.js"></script> <!-- async : télécharge en parallèle, s'exécute immédiatement lorsque prêt (dans n'importe quel ordre) --> <script async src="script.js"></script>
Pour la plupart des scripts, defer est le choix le plus sûr car il préserve l'ordre d'exécution. Utilisez async pour les scripts qui sont complètement indépendants, comme l'analytics. Si vous utilisez des modules ES (<script type="module">), vous obtenez le comportement defer automatiquement. Les scripts de module ne bloquent jamais le rendu.
Pour un guide complet sur toutes les façons de contrôler le timing du JavaScript, voir 16 méthodes pour différer le JavaScript. Si vous voulez comprendre comment async et defer affectent les Core Web Vitals différemment, nous avons également un article dédié à ce sujet.
Différer les feuilles de style
Différer les feuilles de style est plus délicat que différer les scripts. Lorsqu'une feuille de style est différée, la page est d'abord rendue sans ces styles, puis le navigateur les applique une fois chargés. Cela provoque des scintillements (flickering) et des décalages de mise en page (layout shifts). C'est pourquoi vous devez associer les feuilles de style différées au CSS critique (critical CSS) inline.
Étape 1 : Mettez en ligne (inline) votre CSS critique. Le CSS critique est l'ensemble minimum de styles nécessaire pour rendre la partie visible de la page. Mettez-le inline directement dans une balise <style> dans le <head>. Cela donne au navigateur tout ce dont il a besoin pour peindre le contenu au-dessus de la ligne de flottaison (above-the-fold) sans attendre un fichier externe. L'extraction manuelle du CSS critique est fastidieuse. Vous pouvez utiliser notre Générateur de CSS Critique pour automatiser cela.
<style>/* CSS critique ici */</style>
Étape 2 : Chargez le reste avec une faible priorité. Pour la feuille de style non critique, ajoutez fetchpriority="low" pour dire au navigateur que cette ressource ne doit pas concurrencer le contenu critique :
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Vous pourriez voir des articles plus anciens recommander un hack media="print" qui passe à media="all" au chargement (on load). Je ne recommande pas cela. Cela abuse de l'attribut media pour quelque chose pour lequel il n'a pas été conçu, cela dépend d'un gestionnaire (handler) onload fragile, et si ce gestionnaire échoue, vos styles ne s'appliqueront jamais. L'utilisation de fetchpriority="low" est l'approche sémantique et correcte : elle indique exactement au navigateur ce que vous voulez dire sans astuces.
Pour les feuilles de style dont vous n'avez pas du tout besoin sur la page actuelle (par exemple, les styles utilisés uniquement sur un type de page spécifique), la solution la plus propre est de supprimer entièrement le CSS inutilisé de cette page.
Réduire l'impact des ressources bloquant le rendu
Parfois, vous ne pouvez pas éliminer les ressources bloquant le rendu. Vous n'avez peut-être pas accès au template ou votre CMS peut exiger certains scripts. Il existe quelques moyens de réduire l'impact :
- Minifiez et compressez vos styles et scripts.
Les ressources plus petites ont moins d'impact sur les performances de chargement que les ressources plus volumineuses. Assurez-vous que la compression gzip ou brotli est activée sur votre serveur. - Évitez d'enchaîner les requêtes critiques (chaining critical requests).
Si une feuille de style bloquant le rendu charge une autre feuille de style via@import, vous avez créé une chaîne de requêtes (request chain). Le deuxième fichier ne peut pas commencer à se télécharger tant que le premier n'est pas entièrement chargé et analysé. Utilisez plutôt des balises<link>séparées pour que les deux se téléchargent en parallèle. - Déchargez (Unload) les ressources par page.
Lorsqu'une ressource ne peut pas être supprimée d'une page, cela ne signifie pas qu'elle est requise sur toutes les pages. Les plugins WordPress ont tendance à ajouter des scripts et des styles à toutes les pages, même lorsque le plugin n'est actif que sur quelques-unes. - Priorisez ce qui compte.
Utilisez la priorisation des ressources (resource prioritization) pour vous assurer que les ressources critiques se chargent en premier et que les ressources non critiques ne concurrencent pas la bande passante.
Dans les données de surveillance de CoreDash, les sites qui ont éliminé toutes les ressources bloquant le rendu ont vu leur FCP s'améliorer de [CD:placeholder] ms en moyenne.
Performance degrades unless you guard it.
I do not just fix the metrics. I set up the monitoring, the budgets, and the processes so your team keeps them green after I leave.
Start the Engagement
