Les bases
Un site web, ça reste un tas de HTML, d'élégantes CSS et d'indispensables bouts de javascript. Écrire des pages à la main, c'était fun avant l'an 2000, mais maintenant l'usage de gabarits est indispensable, et surtout la maitrise du HTML ne doit pas être un prérequis pour publier quoi que ce soit en ligne.
Protéger et servir
Les CMS ont conquis et formés tous les rédacteurs webs du monde, avec des interfaces utilisateurs agréables, mais en quoi est-ce indispensable de recalculer chaque page pour chaque visiteur ? Ça mange du CPU, ça peut être long, il y a toujours un doute sur les performances en cas de forte affluence.
On peut le cacher derrière un cache, accompagné ou non d'un CDN, effectivement, mais il faut bien maitriser l'ensemble.
Pourquoi ne pas faire simple ? Si le contenu n'est pas modifié à chaque instant, et le servir en statique, à l'ancienne : un fichier index.html et son Nginx configuré aux petits ognons.
Il y a une longue tradition d'incertitude sur la sécurité des CMS les plus utilisés, alors qu'avec un site statique, le stress du défacement baisse tout de suite d'un cran, un grand cran.
Autres avantages, un site statique n'a pas besoin de mise à jour de sécurité, et on peut même mettre à jour son optimisation (passage à HTTP/2, TLS 1.3, les headers qui vont bien, compression brotli…) indépendamment du contenu.
Bref, le contenu statique est beau, sobre et pérenne.
Créer du contenu statique
On va tout de suite zapper vi comme outil d'édition et passer directement aux choses sérieuses.
Techniquement, les bases de données relationnelles (Mariadb et ses amis, quoi) sont particulièrement inadaptées à la gestion de version, de diff et de patch , alors qu'il existe de très bon outils de gestion de version, comme l'incontournable combo git+gitlab.
Les moulinettes se basent sur une arborescence de fichiers plats qui vont pouvoir aller s'épanouir dans un git avec ses pull requests.
Je ne vous cache pas qu'il existe plein de solutions de génération de contenu statique comme l'énumère staticgen
Moulinage sans UI
Jekyll doit être un des premiers outils populaires pour créer des sites statiques. Hugo est la proposition de golang pour aller plus vite. Pour aller encore plus vite, il faut bien sûr demander à Rust avec Zola . Il existe bien sur une palanquée d'outils, plus ou moins connus, plus ou moins maintenus, plus ou moins pertinents.
Moulinage avec UI
Tout le monde n'est pas fan de ligne de commande, et pouvoir naviguer dans la version locale de son site, puis éditer un contenu, avant de le publier. Lektor propose une interface sympathique, mais inadaptée au travail collectif. Attention, je parle bien de l'interface web, lektor reste un classique tas de markdown qui se range dans un git.
Lektor est tellement bien qu'on l'utilise pour écrire ce contenu.
Générer du contenu statique à partir d'un CMS traditionnel
Pour avoir une vraie UI web, multiutilisateur, et tout, le plus simple est d'aller du coté des grands classiques : Wordpress avec WP2static et Drupal avec Tome .
Les rédacteurs gardent leur UI, les thémeurs leurs thèmes, le site devient à l'épreuve des balles : tout le monde est heureux.
Techniquement, ça s'intègre bien à une CI, et en versionnant le contenu (dans un très classique git), on peut choisir sereinement quelle version on livre, avant de oups, changer d'avis : on a la main sur l'historique.
Par contre, oui, tous les plugins ne fonctionneront pas en statique, ça semble logique, mais ça ne coute rien de le rappeler.
Ajouter quand même du dynamique
On a déjà l'habitude d'ajouter des trucs et des machins, as a service, sur ses sites webs, un peu comme les très connus disqus ou google analytics. Avec un site statique, ça fonctionnera pareil.
Bon, on vous conseillera quand même de préférer Comento ou Matomo .
Go static
Pas mal de sites peuvent être statiques, tout simplement statiques. Le gain en performances, sérénité et efficience justifie largement le petit effort pour faire la bascule.
