Guides

Ressources bloquant le rendu : ce qui bloque vraiment, et pourquoi async n'est pas la solution

vuetelemetry
Guides
8 min de lecture

Lighthouse nomme l'audit et liste les fichiers. Il n'explique pas qu'un script sans attribut arrête net l'analyseur, qu'async bloque encore le rendu au moment de s'exécuter, et que le CSS bloque pour une raison entièrement différente.

« Éliminer les ressources bloquant le rendu » est l'audit le plus fréquent d'un rapport Lighthouse, et le moins expliqué. Il nomme les fichiers et s'arrête là. Deux mécanismes différents se cachent derrière cette seule ligne, et ils demandent des correctifs différents.

Les scripts : ce que fait vraiment chaque attribut

Des personnes faisant la queue le long d'une bordure, vues de dessus, avec des marquages routiers sur le bitume à côté. Un script bloquant fait la même chose à l'analyseur : tout ce qui suit attend, dans l'ordre, que celui de devant ait fini.

**Un script classique sans attribut arrête l'analyseur.** MDN le dit sans détour : les scripts sans `async`, `defer` ni `type="module"` sont *« récupérés et exécutés immédiatement, avant que le navigateur ne continue à analyser la page »*. Le navigateur construit votre document, rencontre la balise, et s'arrête : télécharger, exécuter, puis reprendre. Tout ce qui est sous cette ligne attend.

**`defer` est la réponse la plupart du temps.** L'attribut indique que le script *« est destiné à être exécuté après l'analyse du document, mais avant le déclenchement de DOMContentLoaded »*. L'analyse continue sans interruption, et les scripts différés *« s'exécutent dans l'ordre où ils apparaissent dans le document »* : un script qui dépend d'un autre l'obtient donc toujours.

**`async` est celui qu'on emploie de travers.** Il est récupéré *« en parallèle de l'analyse et évalué dès qu'il est disponible »*, ce qui semble strictement meilleur. Ce qu'on omet, c'est la phrase juste après : *« une fois le téléchargement terminé, le script s'exécute, ce qui empêche la page de s'afficher »*.

Async supprime donc le blocage pendant le **téléchargement**, pas pendant l'**exécution**. Un gros script chargé en async arrive quand il arrive, au milieu de l'analyse, et bloque le rendu à ce moment-là. Et comme l'ordre d'exécution suit l'ordre d'arrivée, MDN prévient qu'il n'y a *« aucune garantie que les scripts s'exécutent dans un ordre précis »* — ce qui casse tout ce qui a des dépendances.

La règle courte : **defer pour vos propres scripts, async uniquement pour des tiers réellement indépendants**, comme une balise d'analytics qui ne parle à personne.

Le CSS bloque pour une autre raison

**Le CSS bloque pour une autre raison, et le correctif n'est pas un attribut.** Une feuille de style n'arrête pas l'analyseur HTML, mais le navigateur ne peindra pas tant qu'il n'a pas le CSS dont il a besoin, parce que peindre d'abord et restyler ensuite montrerait un éclair de contenu non stylé. C'est un blocage du rendu, pas de l'analyse.

Sans attribut : récupéré et exécuté immédiatement, l'analyse s'arrête
defer : s'exécute après l'analyse, dans l'ordre du document, avant DOMContentLoaded
async : pas de blocage au téléchargement, mais l'exécution bloque le rendu, et l'ordre n'est pas garanti
CSS : ne bloque pas l'analyse, bloque la peinture — limitez sa portée avec media
Les balises tierces représentent souvent la plus grosse part de l'audit

Le levier est ici la portée plutôt que le moment. Une feuille qui ne s'applique qu'à un contexte peut porter un attribut `media`, et le navigateur la récupérera sans la laisser bloquer le premier affichage — `media="print"` étant le cas connu. Reste le CSS dont le premier écran a réellement besoin, et c'est celui-là qu'il vaut la peine de garder petit.

- vuetelemetry

Où se trouve le poids, et comment le confirmer

**Les balises tierces pèsent généralement le plus lourd.** Votre propre bundle est sous vos yeux et finit optimisé ; le gestionnaire de balises, le widget de discussion et la bannière de consentement arrivent comme des scripts que vous n'avez pas écrits, chargeant souvent d'autres scripts à leur tour. Auditer ce qu'ils coûtent vraiment — et si chacun le mérite — déplace le chiffre bien plus que de gratter des kilo-octets sur votre code.

**Ensuite, mesurez sur le terrain, pas sur le rapport.** Lighthouse vous dit qu'une ressource bloque le rendu ; il ne vous dit pas si la retirer a changé quoi que ce soit pour vos visiteurs. Cette différence entre un audit de labo et des utilisateurs réels est [un sujet en soi](/fr/articles/donnees-terrain-vs-donnees-labo), et c'est elle qui décide si le travail en valait la peine.

FAQ

Que veut dire « éliminer les ressources bloquant le rendu » ?

C'est un audit Lighthouse qui liste les scripts et feuilles de style retardant le premier affichage. Deux mécanismes différents se cachent derrière : un script classique sans attribut arrête net l'analyseur HTML, tandis qu'une feuille de style laisse l'analyse continuer mais empêche la peinture jusqu'à son chargement. Ils demandent des correctifs différents, et c'est pourquoi l'audit seul ne suffit pas pour agir.

Faut-il utiliser async ou defer ?

defer pour vos propres scripts, async uniquement pour des tiers réellement indépendants. defer s'exécute après l'analyse, dans l'ordre du document, donc les dépendances fonctionnent encore. async s'exécute dès la fin du téléchargement, ce qui bloque le rendu à cet instant, et MDN prévient qu'il n'y a aucune garantie sur l'ordre d'exécution.

async rend-il un script non bloquant ?

Pas entièrement, et c'est le contresens courant. async supprime le blocage pendant le téléchargement : le script est récupéré en parallèle de l'analyse. Mais MDN indique qu'une fois le téléchargement terminé, le script s'exécute et que cette exécution empêche la page de s'afficher. Un gros script async bloque simplement à un moment imprévisible au lieu d'un moment prévisible.

Pourquoi le CSS bloque-t-il le rendu ?

Parce que peindre avant l'arrivée de la feuille de style afficherait du contenu non stylé, qu'il faudrait ensuite refaire. Le navigateur attend donc. Contrairement à un script, le CSS n'arrête pas l'analyseur HTML : il arrête la peinture. Le correctif n'est pas un attribut mais la portée — une feuille limitée par un attribut media est récupérée sans retenir le premier affichage.

Comment savoir si la correction a servi ?

Pas par le rapport Lighthouse, qui vous dit seulement qu'une ressource bloquait le rendu. Que le changement ait atteint vos visiteurs se lit dans les données terrain, au 75e centile sur 28 jours. Un audit de labo désigne le candidat ; seul le terrain confirme le résultat.