Faut-il externaliser le CSS et JavaScript de vos pages ?
- Le CSS/JS écrit dans le HTML ne peut pas être mis en cache : il se retélécharge à chaque page.
- Externalisé dans un fichier, il n’est chargé qu’une fois puis réutilisé partout : plus rapide et plus sobre.
- Un peu de CSS critique inline peut se justifier ; c’est l’inline massif et répété qu’il faut corriger (côté développeur).
Il existe deux façons d’ajouter du style ou des scripts à une page : les écrire directement dans le code HTML, ou les ranger dans des fichiers à part. La première paraît plus simple, mais elle a un défaut coûteux : ce code « en dur » ne peut pas être mis en cache, et se retélécharge à chaque page. Multiplié par tout un site, ça pèse.
C’est quoi le code « inline » ?
On parle de code inline (ou embarqué) quand le CSS (les styles) ou le JavaScript (les scripts) sont écrits directement à l’intérieur du fichier HTML de la page, plutôt que dans des fichiers séparés. Visuellement, le résultat est le même ; techniquement, la différence est importante.
Le problème : pas de mise en cache
Le navigateur sait mettre en cache les fichiers externes : une fois la feuille de style téléchargée, il la réutilise sur toutes les pages suivantes, sans la retélécharger. Mais le code écrit dans le HTML, lui, fait partie de la page : il est rechargé intégralement à chaque visite de chaque page. Le même bloc de styles voyage ainsi en double, en triple, à l’infini.
Pourquoi ça s’alourdit page après page
Imaginez 200 lignes de styles répétées dans chaque page d’un site de 50 pages, rechargées à chaque navigation. C’est autant de données transférées inutilement, à chaque fois. Externalisé dans un fichier, ce même code serait téléchargé une seule fois, puis réutilisé. L’inline transforme une dépense unique en dépense permanente.
Le double coût : vitesse et empreinte
Ce gaspillage ralentit la navigation (surtout pour les visiteurs qui parcourent plusieurs pages) et alourdit l’empreinte du site, puisque chaque octet rechargé consomme de l’énergie. C’est pourquoi le code inline est un critère suivi en éco-conception : l’externaliser, c’est à la fois accélérer et économiser.
Quand un peu d’inline se justifie
Nuance : une petite dose de CSS critique inline peut parfois être recommandée pour afficher plus vite le haut de la page. Le problème n’est donc pas l’inline en soi, mais l’inline massif et répété — des blocs entiers de styles ou de scripts dupliqués sur chaque page. C’est ce gaspillage-là qu’il faut corriger.
Pourquoi « côté développeur »
Déplacer le code embarqué vers des fichiers externes propres, sans rien casser, demande de toucher à la structure du site et au thème. C’est typiquement un travail de développeur. Votre rôle : repérer le problème via l’audit, et le faire traiter — souvent à l’occasion d’une refonte ou d’une optimisation plus large.
Comment repérer et corriger
- Limpi signale les pages avec beaucoup de CSS ou JS embarqué.
- Confiez à un développeur l’externalisation de ces blocs vers des fichiers dédiés, mis en cache.
- Conservez uniquement le minimum de CSS critique inline, si nécessaire, pour la vitesse d’affichage initiale.
Externaliser le code, c’est le télécharger une fois pour toutes les pages, au lieu de le recharger à chaque visite. Le visiteur navigue plus vite, et le site consomme moins.
Le code inline, c’est réimprimer le mode d’emploi dans chaque carton plutôt que de le ranger une fois sur l’étagère : du papier gaspillé à chaque envoi.
En résumé
Le CSS et le JS écrits directement dans le HTML ne peuvent pas être mis en cache : ils se retéléchargent à chaque page, alourdissant la navigation et l’empreinte du site. Externalisés dans des fichiers, ils ne sont chargés qu’une fois puis réutilisés. Un peu de CSS critique inline peut se justifier pour la vitesse, mais l’inline massif et répété est à corriger — un travail de développeur, à votre portée d’arbitrage.
Questions fréquentes
C’est quoi le code inline ?
Du CSS (styles) ou du JavaScript (scripts) écrit directement dans le fichier HTML de la page, plutôt que dans des fichiers séparés.
Pourquoi est-ce un problème ?
Parce que le code dans le HTML ne se met pas en cache : il est rechargé intégralement à chaque page, au lieu d’être téléchargé une seule fois.
Quel est l’impact ?
Une navigation plus lente (surtout sur plusieurs pages) et une empreinte alourdie, puisque chaque octet rechargé consomme de l’énergie.
Faut-il bannir tout l’inline ?
Non. Un peu de CSS critique inline peut accélérer l’affichage initial. Le problème est l’inline massif et répété sur chaque page.
Comment corriger ?
En externalisant ces blocs vers des fichiers dédiés (mis en cache) — un travail de développeur, souvent fait lors d’une optimisation.
Sources et références
- Sustainable Web Design / Green Web Foundation — Modèle de conception web durable (CO2.js)
- Collectif GreenIT (EcoIndex) — EcoIndex — éco-conception web
Vous voulez savoir ce qu'il en est sur VOTRE site ?
Limpi analyse votre site et vous dit, en clair, ce qui cloche et comment le corriger. Sans jargon.