L’impact énergétique d’internet n’est pas anodin. Il représente actuellement 3 à 4% des émissions Carbone [ Source ] avec une augmentation de 9% par an. Pourtant le sujet peine à dépasser le cadre des professionnels du secteur dont une majorité d’agences de communication se contentent de verdir leurs discours.

Quelques-un-e-s essayent néanmoins d’impulser de nouvelles pratiques pour un internet moins énergivore. Parmi les pistes avancées, les sites statiques sont une alternative plutôt intéressante : Plus rapides, plus légers, moins couteux, difficiles à pirater. Comment çà marche ? Pour le comprendre regardons le contexte.

Des sites dynamiques devenus lents

Aujourd’hui, la majorité des sites sont dynamiques - construit en PHP avec le CMS Wordpress • 43.1% de tous les sites. Le problème ? Une majorité de ces sites embarquent toujours plus de technologies - souvent inutiles - avec des appels incessants aux bases de données.

<!-- Dans cet exemple en PHP les fonctions (en vert) récupérent les données -->

<h1><?php get_the_title(); ?></h1>
<div><?php get_the_date(); ?></div>

Résultat, la plupart de ces sites dynamiques sont devenus lourds, et donc plus longs à charger. Avec un réseau fibre, vous ne devriez pas le constater mais si vous basculez sur un réseau 3G ou 4G avec un téléphone portable (la majorité des connexions), vous constaterez la lenteur de chargement. Vous pouvez faire ce simple test pour estimer les performances de n’importe quel site internet. Avec google pagespeed vous obtiendrez une analyse plus détaillée et une note sur 100.

Bien sûr vous pouvez - je le fais parfois - prendre le CMS Wordpress et l’optimiser au mieux, en vous débarrassant de tout ce qui est superflu. Mais cela représente quand même plusieurs heures de travail et des connaissances.

La solution ? Les sites statiques

Contrairement aux sites dynamiques, les sites statiques n’ont pas besoin de base de données [BDD], puisque toutes les données sont directement présentes dans le code HTLM (exemple ci-dessous). Il n’y a pas de temps perdu à récupérer les différentes ressources (titre, date de publication, contenu, tags etc.), le chargement est quasi immédiat1.

<!-- Dans cet exemple en HTML les données sont déjà intégrées -->

<h1>Titre de l'article</h1>
<div>20 Avril 2023</div>

L’autre avantage, c’est l’hébergement. Puisqu’il n’y a pas de BDD, vous pouvez générer votre site localement (ce que je fais) - sur votre ordinateur - puis le charger via FTP (Fillezilla par exemple) sur votre serveur. Chez n’importe quel hébergeur, le coût sera moindre. Que vous ayez 1 ou 20 ou 150 sites, le prix sera le même.

Mieux encore, vous pouvez héberger votre site gratuitement (il y a quelques conditions quand même) sur des plateformes de GIT, comme GITHUB, GITLAB, HEROKU. L’intérêt en plus du coût ? Ces plates formes permettent un travail collaboratif et sont disponibles en ligne. Une condition à la gratuité, le code est open-source.

Un dernier avantage - il y en a d’autres mais ce serait fastidieux de tous les nommer - les sites statiques “ne sont pas” piratables. Puisqu’il n’y a pas de BDD, il sont moins exposés aux attaques. Les pirates peuvent s’attaquer à votre serveur mais ils n’entreront pas via votre site comme c’est le cas avec les sites dynamiques.

Les petits inconvénients des sites statiques

Rien de grave mais il faut le savoir. Le temps de génération d’un site statique augmente à mesure du nombre de pages et de ressources. Si vous avez 30 pages dans votre site, cela prendra quelques secondes. Si vous en avez 10.000, ce sera quelques minutes. Même si certains générateur de site statique (HUGO) vont apparemment très vite.

L’autre inconvenient est un peu plus génant. La gestion de contenu se fait par ligne de commande (c’est mon cas avec visual composer). Je suppose que pour beaucoup cette pratique n’est pas engageante. Je les comprends.

Heureusement, il existe pour cela des solutions de gestion de contenu autrement dit un tableau de bord qui permet via une interface de piloter son site de façon plus conviviale.

Si vous hébergez votre site sur une plateforme GIT cela ne posera aucun problème. J’ai testé Jekyll avec GITHUB avec NETLIFY et son CMS DECAP. Je le conseille, c’est vraiment trés bien pour les utilisateurs comme pour les développeurs.

Par contre. En version locale - sur votre ordinateur - ou même autohéberger, j’ai l’impression que les solutions sont moindres. J’ai testé (Publii et Jekyll-admin) mais je n’ai pas été franchement convaincu2. A mon sens ce manque de solutions CMS reste a combler pour permettre d’ouvrir les sites statiques à un public plus large.

Pour conclure

Vous l’aurez compris… Les sites statiques présentent pleins d’avantages. Même s’ils souffrent de quelques petits défauts, ils sont une vrai solution d’avenir face aux sites dynamiques [en PHP] toujours plus lents et lourds.

Évidemment, ils ne régleront pas le probléme de la surconsommation de données (qui est surtout dû à la vidéo) mais ils sont une alternative crédible dans la conception web, avec plus de performances et moins d’énergie consommée. Que des bonnes raisons pour les tester !

Cet article est vulgarisé à dessein. Pour en savoir plus sur les sites statiques, vous pouvez consulter le site Jamstatique avec pleins de sujets sur la question.


  1. Cela ne marche que si vous respectez l’optimisation des ressources web : images, SASS ou CSS, JS; 

  2. Si un développeur a des solutions CMS pour Jekyll a me soumettre, je prend!