Les CMS pour des sites simples : Attention au gâchis

Qu'est-ce qu'un site simple ?

Beaucoup de sites ont vocation à présenter des informations, plus ou moins régulièrement mises à jour. Ces infos contiennent du texte, des images, des vidéos, ... En lisant ça, vous pensez immédiatement que ceci est vrai pour énormément de sites et vous avez raison.

C'est ce que j'appelle des sites simples.

Ceci exclut de prime abord les sites avec des interactions utilisateurs, je parle là du public consultant le site, pas de ceux qui l'alimentent. Cette notion de sites simples exclut ceux affichant des données rafraîchies très régulièrement (plusieurs fois par jour). Ainsi, un site eCommerce n'est évidemment pas un site simple.

Ceci n'empêche pas qu'un nombre énorme de sites rentre dans cette définition des sites simples. Dans les années 1990-2000, cette distinction était évidente : Les sites simples étaient les sites "statiques". Aujourd'hui, ce mot statique est devenu un gros mot. Personne n'osera dire que son site est statique, ça fait "has been". Oui mais... nous y reviendrons.

De plus, pourraient facilement rentrer dans cette catégorie des sites simples les sites faussement dynamiques : C'est à dire ceux qui affiche une fonctionnalité dynamique mais qui ne sert à rien ou n'est pas utilisée. Je pense là au système de commentaires de certains sites (pas tous!), Combien de blogs ne dénombrent aucun commentaire une fois que tous les spams ont été supprimés ?

Bref, vous avez compris à présent ce que j'entends par sites simples, alors rentrons dans le vif du sujet.

En quoi est-ce un gâchis d'utiliser un CMS pour afficher ces sites ?

Par définition, les CMS affichent des contenus qui ont été préalablement saisis par des webmasters ou administrateurs du site. C'est toute leur raison d'être. Sans refaire tout l'article sur l'intérêt d'un CMS, ils permettent d'afficher de manière cohérente les différentes pages qu'un gentil utilisateur a pris la peine de saisir, d'alimenter les images et illustrations ou tout autre contenu jugé pertinent...

Ensuite, à chaque demande d'un internaute qui passe par là, le CMS va gentiment regarder dans sa base les contenus à afficher, les formater dans un template, voire optimiser un peu le rendu en compressant son contenu afin de le restituer au navigateur de cet internaute. Même si le CMS est un peu plus évolué avec un système de cache, le CMS ira voir si son cache n'est pas périmé afin de présenter une information actualisée.

Toute cette mécanique est bien huilée, croyez-moi. Cependant, ceci représente des traitements répétés inlassablement pour présenter la plupart du temps le même contenu : Voici l'essence même du gâchis que je souhaite souligner ici.

Que d'énergie gâchée : Faire ronronner le microprocesseur, le disque dur où la base est stockée, compresser, tout ça pour produire un même résultat. A notre époque où l'empreinte énergétique se doit d'être améliorée, cela laisse à réfléchir.

Que de temps gâché : Effectuer toutes ces opérations requiert du temps. Ce temps, chaque internaute le paie, sans même y faire attention, à coup de secondes par-ci, par-là, à attendre l'affichage de sa page. A notre époque où chacun court après le temps, où un internaute impatient va cliquer sur son bouton "page précédente" pour tester le résultat de recherche suivant en espérant qu'il sera plus rapide à s'afficher, tout ceci manque de cohérence.

Que de ressources gâchées : Chacun a bien conscience de cette recherche de l'optimisation. Ce n'est pas pour rien que Google prend en compte le temps de chargement des pages dans son classement. Par conséquent, une course à la puissance s'enclenche et amène à mettre des serveurs surpuissants pour pouvoir afficher inlassablement les mêmes pages. En ces temps de pénurie sur le silicium et autres composants électroniques, il y a sûrement mieux à faire...

Quelles solutions pour, malgré tout, avoir des sites régulièrement mis à jour et attrayants ?

Un moyen radical pour contrer ces gâchis est de revenir aux sites statiques créés avec des éditeurs HTML. Cependant, ce serait se priver des différents apports extrêmement bénéfiques d'un CMS :

  • Il faudrait se préoccuper des menus, des plans du site, des remontées d'articles à la main.
  • Il faudrait s'assurer que d'une page à l'autre le même thème soit bien utilisé, même si entre temps vous avez changé tel ou tel élément de votre charte graphique.
  • Il faudrait apprivoiser un nouvel outil de saisie des articles, voire un outil de développement pour cela.

Cela ferait beaucoup de barrières que bon nombre de webmasters refuseraient de franchir.

La solution intermédiaire que je propose est moins radicale tout en arrivant au même résultat : Garder son CMS, mais l'utiliser en local. Ensuite basculer les pages produites sur le serveur d'hébergement. Cette orientation offre de nombreux avantages :

  • L'environnement de contribution des pages ou articles reste connu : C'est le même CMS.
  • Les éléments produits automatiquement par le CMS le restent : Plan du site, menus, remontés d'articles restent gérés par le CMS. Donc il n'est pas nécessaire d'y apporter plus d'attention qu'avant.
  • Le CMS continue d'utiliser le thème habituel. Il reste donc possible de modifier tout le thème en très peu d'opérations et sans risque de rendre le site incohérent graphiquement.

Au final, avec cette solution, le site est généré en une seule fois lorsque les modifications apportées le nécessitent. Les internautes peuvent continuer d'y accéder sans provoquer la génération des pages en dynamique. On évite alors tout le gâchis évoqué précédemment.

Comment faire pour produire un tel site ?

Cette orientation n'étant pas encore généralisée, elle nécessite un peu de mise en œuvre et de connaissances techniques pour l'installer une fois pour toute. Mais une fois en place, il suffit d'utiliser les outils mis en place. Cette marche initiale à franchir peut s'automatiser dès l'instant où les porteurs de CMS prendront conscience qu'il y a une vraie utilité à produire ainsi les sites simples. Je suis plutôt confiant sur le sujet, ça va venir...

En attendant, voici comment je produis mes sites :

  • J'utilise Typo3 comme CMS sur mon PC, en local. C'est à dire que je pourrais tout à fait mettre à jour mon site sans accès internet. Tout est sur ma machine et fonctionne de manière très fluide.
  • Lorsque mon cycle de mise à jour est terminé, j'utilise l'outil httrack pour capturer les pages en statique.
  • J'exécute ensuite un petit script de mon cru pour revoir les URLs des pages et faire le ménage des fichiers temporaires que Typo3 crée à chaque fois de manière unique.
  • J'utilise ensuite un script kermit pour tout transférer d'un coup sur le serveur d'hébergement d'ads-COM.

Et là, tout est en ligne.

Vous pourrez noter que les 3 dernières étapes, comme elles sont automatiques, pourraient être lancées régulièrement par un cron. Mais, là encore, ce serait du gâchis, donc non, je ne les lance que quand cela vaut vraiment le coup.

Afin d'en arriver-là, j'ai dû dans un premier temps mettre en place mon environnement comme indiqué dans cet article pour que tout fonctionne correctement.

Puis vient l'automatisation du transfert. Cette étape est cruciale car tout doit fonctionner à la perfection. C'est pour cela que je me suis appuyé sur des outils réputés pour leur fiabilité car utilisés depuis des années (out donc le dernier petit outil tout buggé...).

La capture du site par httrack

L'outil httrack permet de parcourir tout un site et d'en enregistrer une copie. Il est très pratique et efficace. Par contre, pour offrir une telle efficacité, il présente de nombreuses options. Du coup, la difficulté est alors de trouver les options qui correspondent à ce qu'on veut faire.

Dans mon cas, j'ai deux sites à traiter d'un coup. Ce n'est pas un problème : La gestion multi-site est également possible avec ce système. Chaque site arrive dans un répertoire portant son nom de domaine localxxx.

Voici donc la ligne de commande que j'utilise, avec toutes ses options :

httrack https://localwww.emmguyot.com https://locallibertylook.emmguyot.com -*/syntax_highlighter/* \
   -o0 -R5 -b1 -K4 -v -%k -s0 -%l "fr, en, *" \
   -F "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0"

Petite explication des options ci-dessus :

  • -o0 : Pas de génération de page HTML en cas d'erreur (404, ...). Ces pages ne doivent pas être déployées car le but est qu'il n'y ait pas d'erreur.
  • -R5 : Nombre de tentatives pour charger la page. C'est une simple sécurité au cas où mon poste rame un peu.
  • -b1 : Accepte les cookies. Option un peu inutile dans mon cas, mais au cas où.
  • -K4 : Conserve les liens originaux. C'est au final la meilleure option pour moi compte tenu des scripts que j'ai ajouté en fin de production.
  • -v : Affichage à l'écran de l'avancée de la capture. C'est surtout utile pour vérifier que tout va bien au début.
  • -%k : Utilisation de connexion "keep-alive" lors de l'échange avec le serveur Apache. Cela permet de gagner en vitesse lors de la capture.
  • -s0 : Ignore les balises pour les robots
  • -%l "fr, en, *" : Langues acceptées. C'est utile pour moi car le site LibertyLook est en français et en anglais.
  • -*/syntax_highlighter/* : Ceci est un cas particulier car httrack ne parvient pas à analyser ces scripts SyntaxHighligter qui chargent dynamiquement d'autres scripts. Ces fichiers seront déposés à la main en attendant de trouver une meilleure solution.

La transformation des pages capturées

Les pages capturées par httrack peuvent contenir des références à des fichiers index.html, au domaine capturé. Pour nettoyer ça et obtenir une capture propre, les deux premiers scripts suivants sont déroulés.

De plus, Typo3 génère des fichiers minifiés avec un paramètre pour éviter le cache, ce qui est sauvegardé par httrack par un ajout d'un suffixe au nom de fichier. Il convient donc de revenir au nom de fichier initial. Un troisième script est alors joué.

A noter que ces trois scripts pourraient tout à fait être regroupés.

sed -i 's#\(href="[^"]*\)/index\.html"#\1"#ig' $(find . -type f -iname "*.html")
sed -i 's#\href="index\.html"#href="\#"#ig' $(find . -type f -iname "*.html")
Supprime les index.html pour pointer vers les répertoires directement
sed -i 's#local\(www.emmguyot.com\)#\1#ig' $(find . -type f -iname "*.html")
sed -i 's#local\(www.emmguyot.com\)#\1#ig' $(find . -type f -iname "*.js")
sed -i 's#local\(www.emmguyot.com\)#\1#ig' $(find . -type f -iname "*.css")
sed -i 's#local\(libertylook.emmguyot.com\)#\1#ig' $(find . -type f -iname "*.html")
sed -i 's#local\(libertylook.emmguyot.com\)#\1#ig' $(find . -type f -iname "*.js")
sed -i 's#local\(libertylook.emmguyot.com\)#\1#ig' $(find . -type f -iname "*.css")
Remplace les domaines locaux par les domaines publics
for f in `find . -type f -iname "merged-*" -print`
do
	f2=`echo $f | sed 's#\(merged-[0-9a-f]*-min\)[0-9a-f]*#\1#ig' ` 
	if [ "$f2" != "$f" ]; then
		mv "$f" "$f2"
	fi
done
Renomme les fichiers pour revenir au nom initial

Le transfert du site vers le serveur d'hébergement

Pour transférer automatiquement le site statique sur le serveur d'hébergement, le script ftpsyncup de kermit a été utilisé comme base et légèrement remanié pour gérer mes deux sites et l'authentification.

Ce point n'est pas encore parfait car la suppression sur le serveur n'est pas encore gérée, mais ça va venir... En effet, il ne suffit pas de supprimer les fichiers en trop, d'un point de vue référencement il est essentiel de rediriger vers d'autres pages.

Un peu de réécriture d'URL pour finir tout ça...

Afin que tout fonctionne à merveille, il est nécessaire d'avoir un fichier .htaccess un peu remanié sur le serveur d'hébergement. En effet, les URLs peuvent avoir plusieurs formes et au final, il faut pointer vers le bon fichier html. De plus, la gestion du multi-site redirigeant vers le bon répertoire en fonction du domaine est traitée également à ce niveau.

A coup de réécriture d'URLs conformément à cet extrait de mon .htaccess, chaque requête retrouve le bon fichier à afficher.

	RewriteCond %{DOCUMENT_ROOT}/%{HTTP_HOST}%{REQUEST_URI} -f
	RewriteRule ^(.*)$ /%{HTTP_HOST}/$1 [L]

	RewriteCond %{DOCUMENT_ROOT}/%{HTTP_HOST}%{REQUEST_URI}.html -f
	RewriteRule ^(.*)$ /%{HTTP_HOST}/$1.html [L]

	RewriteCond %{REQUEST_URI} ^(.+)/$ 
	RewriteCond %{DOCUMENT_ROOT}/%{HTTP_HOST}%1.html -f
	RewriteRule ^(.+)/$ /%{HTTP_HOST}/$1.html [L]

	RewriteCond %{DOCUMENT_ROOT}/%{HTTP_HOST}%{REQUEST_URI} -d
	RewriteCond %{DOCUMENT_ROOT}/%{HTTP_HOST}%{REQUEST_URI}/index.html -f
	RewriteRule ^(.*)$ /%{HTTP_HOST}/$1/index.html [L]

La cerise sur le gâteau

Cette méthode de travail apporte différents avantages que je viens de vous détailler. Cependant, il y un bonus non négligeable à cette orientation :

Il n'est plus nécessaire de suivre les mises à jour de sécurité du CMS puisque tout est en local.

Quand on sait le temps que peut représenter les mises à jour de sécurité, c'est vraiment un gain substantiel et une liberté d'esprit plus grande puisqu'il n'est plus nécessaire de s'en soucier. Vous pouvez alors mettre à jour le CMS quand vous le souhaitez et non lorsque la communauté a sorti une n-ième mise à jour de sécurité.

Nota bene

Attention, je ne dis pas ici que les CMS sont inutiles et doivent être évités sur les serveurs hébergés. Il faut, comme toujours, utiliser le bon outil : Celui qui est adapté à ses propres besoins.

Alors évitons les bazookas pour tuer une mouche...