Render blocking et critical CSS : définition et correction

Render blocking : de quoi parle-t-on ?

Pour afficher une page, le navigateur lit le HTML et en tire le DOM. Une feuille de style ou un script dans le head ? Il s'arrête net. Tant que ces fichiers ne sont pas arrivés, rien ne s'affiche : c'est ce qu'on appelle une ressource render-blocking.

Le visiteur, lui, voit un écran blanc. Rien d'autre. Sur un smartphone avec un réseau moyen (dans le métro, par exemple), l'attente se sent vraiment. Elle dégrade les Core Web Vitals, le LCP en tête, et donc l'expérience comme le référencement.

Pourquoi le CSS et le JavaScript bloquent

Pour le CSS, la raison est simple : le navigateur refuse de montrer une page sans mise en forme. Le JavaScript, lui, peut modifier le DOM ou le CSSOM, alors le navigateur l'exécute d'abord et ne reprend qu'ensuite. Les pires ? Les fichiers javascript posés tout en haut de page.

Render blocking vs parser blocking

Un script classique cumule les deux peines : il bloque l'analyse du HTML et il bloque le rendu. Une feuille de style ne bloque que le rendu, et le navigateur continue de lire le code en attendant. Cette nuance oriente directement le choix de la correction.

Repérer les ressources bloquant le rendu

Passez vos pages clés dans PageSpeed Insights ou Lighthouse, les deux outils de Google. Le rapport regroupe les fichiers en cause sous un intitulé du type « Render blocking requests ». Pour chacun, il indique le gain estimé. C'est votre liste de travail.

• Relevez chaque fichier CSS et chaque script signalé.
• Séparez ce qui vient de votre code de ce qu'ajoutent les extensions et les outils tiers.
• Faites le test sur mobile : c'est là que l'effet saute aux yeux.

Corriger le render blocking : la méthode pas à pas

Étape 1 : extraire le critical CSS

Le critical CSS, c'est le strict minimum de style pour afficher ce qui apparaît sans défiler, ce qu'on nomme l'above the fold. Il se glisse directement dans une balise style, dans le head. Résultat : le navigateur peint l'écran sans attendre le moindre fichier externe.

Étape 2 : charger le reste du CSS plus tard

Reste la feuille de style complète, appelée avec rel='stylesheet'. Elle peut arriver de façon asynchrone, une fois l'essentiel affiché. Les requêtes média aident aussi : un fichier réservé à l'impression ou aux grands écrans ne bloquera pas le rendu sur un téléphone. N'oubliez pas non plus la minification CSS et JS, qui allège chaque fichier.

Étape 3 : ajouter async ou defer aux scripts

Avec defer, le script se télécharge en parallèle, puis s'exécute une fois le HTML entièrement lu, dans l'ordre. Async le lance dès qu'il est prêt, sans garantie d'ordre. Mon conseil : gardez async pour les scripts indépendants, une mesure d'audience par exemple, et utilisez defer ailleurs. Un petit script vital ? Intégrez son code javascript directement dans la page.

Étape 4 : reporter ce qui n'est pas critique

Carrousel, chat, lecteur vidéo : beaucoup de scripts ne servent qu'à ajouter de l'interactivité. Rien ne presse. Ils peuvent attendre que la page chargée soit visible, et le code splitting permet de ne livrer à chaque page que le code dont elle a besoin.

Ce qui fait varier l'effort et le coût

Combien de temps faut-il ? Tout dépend du nombre de fichiers, des extensions installées et de la manière dont le thème a été codé. Je le constate souvent : un site sur-mesure se corrige plus proprement qu'un thème générique. Autre atout, le rendu côté serveur réduit la dépendance au JavaScript pour le contenu.

Chez RankerSquare, nous proposons un site vitrine sur-mesure dès 19,90 € par mois en abonnement, pensé dès le départ pour un premier affichage rapide. Pour corriger un site existant ou lancer une refonte de site internet, il faut passer par un devis.

Questions fréquentes