Un site de contenu, c’est un site dont la plupart des pages ne changent pas entre deux visiteurs : une vitrine, un blog, une documentation. Trois familles d’outils le font bien, et le débat entre elles est souvent tranché sur de mauvais critères.

Les mauvaises raisons

Les notes de performance. Tous les outils cités atteignent d’excellents scores sur un site de contenu correctement construit. Elles mesurent surtout combien de JavaScript vous avez ajouté, pas quel outil vous avez choisi.

La popularité. Elle dit qu’on trouvera des réponses aux questions courantes. Elle ne dit rien de l’adéquation.

Les trois options et leur facture

Du HTML statique, écrit ou généré par un script à soi. Le moins cher à faire tourner, le plus pénible à faire évoluer. Tenable pour dix pages, intenable pour cent, parce qu’on finit par réécrire un générateur de gabarits en moins bon.

Astro. Envoie zéro JavaScript par défaut et n’en ajoute que sur les composants qu’on déclare interactifs. Bien adapté à un site dont 95 % du contenu est immobile. Son défaut : dès que l’interactivité devient centrale, on se bat contre le modèle.

Next.js. Le plus complet, et celui qui coûte le plus cher en complexité sur un site de contenu. Rendu serveur, mise en cache par couches, composants serveur et client : autant de puissance et autant de choses à comprendre. Sur une application, ça se rentabilise. Sur une vitrine, ça se paie sans rien rapporter.

Le critère qui tranche

Quelle proportion de vos pages a besoin d’un état côté navigateur ?

Moins de 10 %, prenez Astro. Plus de la moitié, prenez Next. Entre les deux, la question devient : est-ce que ces pages interactives peuvent vivre ailleurs, comme une application séparée sur un sous-domaine ?

Sur le site que vous lisez, la réponse était nette : trente-deux pages, dont aucune n’a besoin d’état persistant. Une bascule de thème et un menu, soit une vingtaine de lignes. Il sert aujourd’hui zéro kilo-octet de JavaScript applicatif et pèse deux mégaoctets en tout, images et police comprises.

Le produit que je vends à côté, lui, est en Next.js : il a des sessions, des droits, des formulaires, des mises à jour en direct. Le même choix aurait été mauvais des deux côtés.

Un an plus tard

L’internationalisation par routes. Deux langues, deux arborescences, des balises canoniques et hreflang correctes. Astro ne l’impose pas, ce qui m’a obligé à l’écrire, et ce qui m’a évité de me battre contre une mécanique toute faite qui ne correspondait pas.

Les images. Le traitement à la construction, avec vérification des dimensions sur les couvertures d’articles, a empêché plusieurs fois de publier une image trop petite.

La stabilité. Une mise à jour majeure du cadriciel en un an, sans casse. Sur un site qu’on touche une fois par mois, c’est le critère qui compte le plus, et celui dont on parle le moins.

Le gabarit de départ m’a coûté un an

J’ai sous-estimé le coût du gabarit de départ. Partir d’un modèle tout fait m’a fait gagner deux jours et m’a laissé, un an plus tard, des images de démonstration en couverture d’articles, une icône d’onglet qui n’était pas la mienne, et une feuille de style de neuf lignes où aucune décision graphique n’avait été prise.

Le gabarit ne vous fait pas gagner du temps : il vous le fait payer plus tard, en moins visible.