Scripts bloquants : pourquoi votre site se fige au chargement
Le test #07 analyse les balises <script> et vérifie si elles bloquent le premier affichage. Un problème courant, facile à corriger, qui change tout pour l'utilisateur.
- Un script sans defer ni async bloque le rendu de la page : le visiteur voit un écran blanc pendant le téléchargement.
- Orilyt compte les scripts externes et calcule le pourcentage de scripts non-bloquants. ≥ 50 % = score 100, 0 % = score 30.
- La correction est simple : ajouter defer (ou async) à chaque balise <script src="..."> suffit dans la plupart des cas.
Quand un navigateur rencontre une balise <script src="...">, il s'arrête, télécharge le fichier, l'exécute, puis reprend le rendu de la page. Pendant ce temps, le visiteur ne voit rien — ou pire, une page à moitié construite.
C'est le comportement par défaut du HTML. Sans indication contraire, chaque script externe est « bloquant ». Plus il y a de scripts dans le <head>, plus l'affichage est retardé.
Le test #07 d'Orilyt détecte ce problème et mesure la proportion de scripts non-bloquants. Voyons comment il fonctionne et comment exploiter ses résultats.
Pourquoi les scripts bloquants sont-ils un problème ?
Sur un site WordPress typique, on trouve entre 5 et 15 fichiers JavaScript externes : analytics, cookie banner, sliders, formulaires, plugins divers. Si aucun n'utilise defer ou async, le navigateur les charge un par un avant d'afficher quoi que ce soit.
L'impact est direct sur les Core Web Vitals : le LCP (Largest Contentful Paint) et le FCP (First Contentful Paint) sont retardés. Google pénalise les sites lents dans son classement.
Pour l'utilisateur, le ressenti est immédiat : le site semble « gelé » pendant 2 à 5 secondes sur une connexion mobile. En 2026, c'est rédhibitoire.
Comment le test #07 fonctionne-t-il ?
Orilyt analyse le code HTML de la page et extrait toutes les balises <script> avec un attribut src (scripts externes). Trois informations sont relevées pour chaque script :
- Présence de l'attribut defer — le script est téléchargé en parallèle et exécuté après le parsing HTML.
- Présence de l'attribut async — le script est téléchargé en parallèle et exécuté dès qu'il est prêt.
- Position dans le <head> — un script bloquant dans le <head> est le pire cas.
Le score est calculé selon le pourcentage de scripts non-bloquants (defer ou async) :
Si aucun script externe n'est détecté, le score est automatiquement 100/100 — pas de risque de blocage.
Le rapport affiche aussi les « head offenders » : les scripts bloquants situés dans le <head>, ceux qui ont le plus d'impact sur le premier affichage.
defer vs async : quelle différence ?
Les deux attributs permettent au navigateur de télécharger le script sans bloquer le rendu. La différence est dans le moment de l'exécution :
defer : le script s'exécute après que le HTML est entièrement parsé, dans l'ordre d'apparition. Idéal pour la majorité des scripts (analytics, UI, plugins).
async : le script s'exécute dès qu'il est téléchargé, sans attendre le HTML ni les autres scripts. Utile pour les scripts indépendants (tracking, A/B testing).
En cas de doute, utilisez defer — c'est le choix le plus sûr car il préserve l'ordre d'exécution.
Comment utiliser ce test dans vos propositions ?
Les scripts bloquants sont un argument particulièrement efficace en avant-vente : le problème est invisible pour le propriétaire du site (il a une bonne connexion) mais critique pour ses visiteurs mobiles.
Voici comment structurer votre recommandation avec la méthode FIA :
- Fait : « Votre site charge X scripts JavaScript sans defer ni async. Ils bloquent l'affichage pendant Y secondes. »
- Impact : « Sur mobile, les visiteurs voient un écran blanc pendant le chargement. Google pénalise les sites lents dans ses résultats. »
- Action : « Ajouter l'attribut defer à chaque balise <script>. Temps estimé : 30 minutes (thème + plugins). »
Le rapport Orilyt liste les scripts bloquants par URL — vous pouvez montrer au client exactement quels fichiers posent problème.
Intégrer ce test dans votre workflow
Le test #07 complète les autres tests de performance pour un diagnostic complet :
- Lancez l'audit Orilyt → le score « Chargement des scripts » apparaît dans la section Performance.
- Si le score est rouge ou orange, ouvrez le détail : vous verrez le nombre de scripts bloquants, les « head offenders » et le pourcentage global.
- Après correction (ajout de defer/async), relancez l'audit et utilisez la comparaison avant/après pour montrer le gain.
Combiné aux tests TTFB (#16), compression (#04) et cache navigateur (#03), ce test forme le socle d'un diagnostic performance solide.
Conclusion
Les scripts bloquants sont l'une des causes les plus fréquentes de lenteur sur les sites WordPress. Le problème est invisible à l'œil nu mais mesurable : c'est exactement le type de découverte qui justifie un audit professionnel.
Le test #07 d'Orilyt vous donne un diagnostic précis : nombre de scripts, pourcentage non-bloquant, liste des contrevenants. Un argument concret, chiffré, prêt à intégrer dans votre proposition.
Testez un site client dès maintenant — vous serez probablement surpris par le nombre de scripts bloquants.