Corriger l'avertissement Lighthouse éliminer les ressources bloquant le rendu
Débarrassez-vous des ressources bloquant le rendu et améliorez les Core Web Vitals
« Éliminer les ressources bloquant le rendu » en bref
Lorsqu'un navigateur rencontre du CSS ou du JavaScript bloquant le rendu dans le <head>, il arrête tout. Aucun pixel n'est affiché tant que ces ressources n'ont pas fini d'être téléchargées et exécutées. C'est ce que vous indique l'avertissement Lighthouse « Éliminer les ressources bloquant le rendu » : quelque chose dans votre <head> retarde le premier affichage.
Corrigez cet avertissement Lighthouse en supprimant ou en différant 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 « Éliminer les ressources bloquant le rendu » ?
Dernière révision par Arjen Karel en mars 2026
Qu'est-ce qui cause l'avertissement Éliminer les ressources bloquant le rendu dans Lighthouse ? Lighthouse signale les pages qui ont soit :
- Une balise de script dans l'en-tête qui n'est pas différée.
Les scripts dans l'en-tête de la page bloquent le rendu par défaut s'ils n'ont pas l'attribut defer ou async. - Une feuille de style liée qui correspond au média de l'appareil.
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 une tierce partie bloquant le rendu. Google Fonts à lui seul est responsable de requêtes bloquant le rendu sur plus de 5,8 millions de sites.
Qu'est-ce qui cause les « ressources bloquant le rendu » ?
Les ressources bloquant le rendu sont toujours des feuilles de style et des JavaScripts dans l'en-tête de la page. Cela signifie qu'ils ne peuvent être ajoutés 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 à ces endroits :
- Le template. Le modèle de votre site web est le premier endroit où regarder. Trouvez l'endroit où se trouve le code <head> et recherchez les styles et scripts codés en dur.
- 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 des scripts) a révélé que, bien que 87 % des pages utilisent async sur au moins un script, seulement 49 % des balises de script individuelles l'ont réellement. Et à peine 13 % des scripts utilisent defer. La plupart des scripts sur le web sont encore chargés sans l'un ou l'autre de ces attributs, ce qui signifie qu'ils bloquent le rendu.
Comment corriger « Éliminer les ressources bloquant le rendu »
Pour corriger les ressources bloquant le rendu, vous devez vous assurer qu'elles ne bloquent plus le rendu. La meilleure solution consiste à supprimer entièrement la ressource. Les anciens scripts et feuilles de style inutilisés qui se trouvent encore dans le <head> sont plus fréquents que vous ne le pensez. Si vous ne pouvez pas les supprimer, différez-les.
Différer le JavaScript
Le JavaScript peut être différé en ajoutant l'attribut defer ou async à la balise de script.
<!-- deferred: se télécharge en parallèle, s'exécute après l'analyse HTML, dans l'ordre --> <script defer src="script.js"></script> <!-- async: se télécharge en parallèle, s'exécute immédiatement lorsque prêt (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 les outils d'analyse. 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, consultez 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 de différer les scripts. Lorsqu'une feuille de style est différée, la page s'affiche d'abord sans ces styles, puis le navigateur les applique une fois chargés. Cela provoque un scintillement et des décalages de mise en page. C'est pourquoi vous devez associer les feuilles de style différées au CSS critique en ligne.
Étape 1 : Mettez en ligne votre CSS critique. Le CSS critique est l'ensemble minimal de styles nécessaires pour afficher la partie visible de la page. Mettez-le en ligne directement dans une balise <style> dans le <head>. Cela donne au navigateur tout ce dont il a besoin pour afficher le contenu au-dessus de la ligne de flottaison sans attendre un fichier externe. Extraire le CSS critique à la main est fastidieux. 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 indiquer au navigateur que cette ressource ne doit pas rivaliser avec le contenu critique :
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Vous pourriez voir d'anciens articles recommander une astuce media="print" qui passe à media="all" au chargement. Je ne le recommande pas. Cela abuse de l'attribut media pour quelque chose pour lequel il n'a pas été conçu, cela dépend d'un gestionnaire onload fragile, et si ce gestionnaire échoue, vos styles ne s'appliqueront jamais. Utiliser fetchpriority="low" est l'approche sémantique correcte : cela indique exactement au navigateur ce que vous voulez dire sans utiliser d'astuces.
Pour les feuilles de style dont vous n'avez pas du tout besoin sur la page actuelle (par exemple, des styles utilisés uniquement sur un type de page spécifique), la solution la plus propre consiste à 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 modèle ou votre CMS peut nécessiter 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 de chaîner les requêtes critiques.
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. 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>distinctes pour que les deux se téléchargent en parallèle. - Déchargez 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 pour vous assurer que les ressources critiques se chargent en premier et que les ressources non critiques ne se disputent 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 420 ms en moyenne.
Real time data. Not 28 day averages.
CoreDash segments every metric by route, device, browser, and connection type.
Explore CoreDash
