Et oui, nous n'utilisons plus WordPress !

Pourquoi ne pas avoir choisi WordPress ?

Peut-être que je ne vous surprends pas beaucoup en vous disant que le site sur lequel vous êtes actuellement est 100% réalisé sous Jekyll. Après, avec un titre comme ça, on s’en serait douté.

Mais est-ce que je vous surprend plus en disant que nous adorons WordPress depuis 2009 et que nous en avons même été des acteurs et actrices de la communauté ?

Après tout, en regardant de plus près, notre site aurait dû pouvoir se faire naturellement sous WordPress. En fait, nous pouvons même l’affirmer, ce site était parfait pour être sous WordPress.

Forcément, nous avons d’excellentes raisons d’avoir fait ce choix.

Pourquoi ne pas avoir utilisé WordPress ?

Bien que nous ferons un billet entièrement consacré à la non-utilisation de WordPress, cela peut se résumer en trois raisons :

• La sécurité,
• Les temps de chargement,
• La consommation énergétique.

Si l’on y réfléchit bien, ces trois problèmes sont liés à une seule chose :
Le côté dynamique de son site web.

Maintenant, demandons-nous si un site web de contenu a réellement besoin d’être dynamique ?

La réponse est simple : pas le moins du monde. Aucun besoin de recourir à la toute la mécanique de construction dynamique d’une page, pour afficher une page de contenu qui n’a pas vocation à être modifiée toutes les trois secondes.

Et vous savez quoi ? La très grande majorité des sites propulsés par WordPress le sont… pour mettre en avant du contenu, et uniquement cela.

Une solution disproportionnée ? Nous le pensons.

Mais alors, pourquoi les CMS sont-ils si populaires ?

On peut présenter les choses ainsi : le CMS, c’est la première génération de brique logicielle venue interagir avec les utilisateurs non techniciens dans le but de créer et gérer un site web.

Le but d’un CMS est plutôt simple : offrir une interface d’administration permettant de venir interagir avec une base de données, qui elle-même sert de base à l’affichage des données sur votre site.

Dis autrement, un CMS c’est une interface d’administration pour son site web. Pratique, je déploie ma brique CMS et je peux créer et administrer un site web rapidement et simplement.

Cela a permis à de nombreuses personnes de se lancer dans la mise en ligne d’un site web sans avoir à trop creuser dans la technique.

Vous l’aurez compris, les CMS sont avant tout populaires parce qu’ils viennent faciliter la vie des gestionnaires de sites web. Enfin… même sur ce point nous pourrions en débattre. Toujours est-il que la simplicité de prise en main et les possibilités offertes par les CMS ont conquis le monde, WordPress en tête.

Mais nous pourrions aussi présenter les choses comme cela : nous avons déporté la complexité sur l’architecture informatique, la rendant :

• Énergivore,
• Volumineuse à charger,
• Sensible aux attaques.

Malgré un temps de chargement parfois “un peu long”, il faut bien reconnaître que certains inconvénients des CMS passent la plupart du temps inaperçus ; les architectures réseaux se sont dimensionnées avec le temps… au prix d’une consommation énergétique accrue.

Pour ce qui est de son côté à être sensible aux attaques, c’est une autre question. Par expérience, nous savons que cela peut hanter de nombreux propriétaires de sites (surtout ceux ayant déjà été victimes de ce type d’attaques en fait).

Pourtant, il existe une solution qui vient résoudre tous ces problèmes en une seule fois : les SSG.

À la découverte des SSG

L’informatique semble très friande des acronymes en trois lettres ; en voici un nouveau à intégrer rapidement à son vocabulaire : les SSG ou Static Site Generator.

Vous avez compris, nous allons parler de web statique.

C’est quoi un Static Site Generator ?

Il est possible qu’à la simple lecture du mot “static”, certains et certaines d’entre vous aient tout de suite envie de dire “OK boomer, donc en fait, tu vas me parler de front page⁽¹⁾ c’est ça ?”

D’une certaine manière, on pourrait presque le dire, si l’on s’arrête uniquement sur la partie génération de pages statiques. Une fois la page générée en local, il suffit de l’envoyer sur son serveur web ; c’est un peu l’idée.

En fait, un SSG va plus loin que cela, il organise et génère un site statique en full HTML à partir de données brutes et d’un template. Par exemple, un SSG peut venir gérer dynamiquement les pages de catégories d’un blog au moment de sa compilation par exemple.

Pour fonctionner, un SSG est souvent installé sur une machine séparée de son serveur web. Ce dernier étant généralement réduit à sa plus simple expression : ce sont des pages HTML pures qu’il faut gérer, c’est tout.

Pourquoi choisir un SSG ?

Lorsqu’il est question de faire tourner un site basé sur le contenu comme un blog ou un site d’entreprise, on comprend très rapidement tous les avantages que l’on a, à tirer d’un système de génération de contenu statique : très faible impact écologique (aucun appel en base de données), construction de pages ultra rapide (toujours pas de base de données), grande résilience aux attaques (impossible d’attaquer une base de données qui n’existe pas).

Si un SSG offre des avantages indéniables, qui nous ont fait choisir Jekyll pour notre site, il existe toutefois des inconvénients. Logique, sinon vous en auriez entendu parler bien avant.

Les inconvénients d’un SSG

Les SSG, ce n’est pas franchement la nouveauté de 2022.

En fait, les SSG sont nés bien avant le simple fait qu’une page web puisse interagir avec une base de données. C’est
donc dès 1990⁽²⁾ que l’on retrouve des traces de ce que l’on nomme maintenant un SSG.

Bien évidemment, ils ont particulièrement évolué, nous permettant de proposer des interfaces modernes à nos visiteurs.

Le gros talon d’achille dans l’appropriation massive des SSG, la manière dont il faut les administrer. Avec un SSG, tout se passe en ligne. Ah oui, tout de suite, c’est moins sympa qu’avec une belle interface d’administration et cela peut clairement déstabiliser au départ.

Avec les SSG, tout va aussi se jouer dans vos fichiers. Une approche différente du monde des CMS.

Bref, une interface où l’on voit tout de suite plus un·e geek qu’un·e responsable marketing.

Le fond du problème n’est-il pas là justement ? Avoir déporté la complexité sur l’infrastructure informatique ? Après tout, logique de devoir passer par une certaine phase de remise en question de ses habitudes, pour en créer de nouvelles, plus vertueuses.

Les SSG, par leurs natures statiques, sont aussi limités sur le côté dynamique et ne proposent pas, par exemple, de possibilité de créer un compte ou encore de mettre à jour son contenu en temps réel. Bien que cela disqualifie par nature les SSG sur certains types de sites, cela en fait leur plus grande force sur le type de site qui existe le plus sur le web : ceux traitant du contenu ; un type de site où les SSG ont toute leur place.

Pourquoi avons-nous choisi Jekyll ?

Qu’on se le dise, le monde des SSG est riche. On y retrouve naturellement différentes solutions, répondant à différents besoins.

Le monde des SSG

Lorsqu’il est question de SSG, voici la liste des solutions les plus communes :

• Gatsby,
• NextJS,
• Hugo
• Jekyll,
• Nuxt.

Clairement, la solution qui semble avoir le plus le vent en poupe lorsqu’il est question de SSG, c’est Gatsby. Pourquoi ? Tout simplement parce qu’il sait notamment très bien travailler dans un environnement headless. Gatsby sait par exemple travailler dans un environnement WordPress, Shopify, Drupal… Plutôt séduisant.

Mais… Notre but n’est pas de travailler dans un environnement Headless, mais bien sur du web statique. La différence entre les deux ? La consommation d’énergie.

Hugo vs Jekyll

Si nous excluons par défaut les frameworks JS, il nous reste deux concurrents : Hugo, Jekyll.

La principale différence entre les deux ? Le langage de programmation. Cela ira en faveur de Ruby, tout de même plus répandu que le Go⁽³⁾ (et cela va compter pour la suite).

L’écosystème Jekyll

Bien que Ruby soit le neuvième langage de programmation le plus utilisé dans le monde, on peut largement s’autoriser à imaginer que la communauté travaillant avec du PHP est nettement plus importante. Ok, ce n’est pas la même chose. Mais c’est bien à cela que l’on va venir comparer Jekyll à la fin, à des solutions reposant sur du PHP.

Pourquoi je précise cela tout de suite ? Car il faut le reconnaître, l’écosystème Jekyll peut sembler assez pauvre quand on le compare au monde WordPress. Mais après tout, quel CMS ne semble pas proposer un catalogue anémique face à du WordPress ?

Les thèmes Jekyll

Contrairement à du WordPress, il va falloir passer par la case intégrateur ou intégratrice web, spécialisé·e sous Jekyll. Et oui, l’offre de thème est… quasiment inexistante. Alors ok, il y a bien une centaine de thèmes plutôt sympa à utiliser. Mais le choix est assez limité et l’on tourne assez vite en rond il faut bien le reconnaître.

Sympa pour faire des tests et se convaincre de l’utiliser, mais pas plus. C’est que nous avons notamment fait avec mademoisellebulle.fr, notre magazine féminin en ligne. Il repose sur Zoltan, un thème Jekyll minimaliste et chic.

Mais ce qui est une faiblesse se révèle être une force lorsque l’on recherche à minimiser l’impact de son site. Ici, rien de superflu n’est jamais envoyé puisque tout est fait sur-mesure. Avec Jekyll, dites adieu à JQuery et autres bibliothèque JS indispensables à votre CMS, quel que soit votre thème, même personnalisé from scratch.

Les plugins Jekyll

Tout comme pour les thèmes, Jekyll ne tient pas la comparaison en terme de nombre de plugins mis à disposition par rapport à du WordPress.
Même si un jour Jekyll devenait la solution numéro un dans le monde, cela restera toujours ainsi. Pourquoi ? Car Jekyll n’a pas besoin :

• de protéger votre interface d’administration^(4),
• de maximiser ses performances avec des systèmes de caches avancés⁽⁵⁾,
• de gérer “plantage” de WordPress⁽⁶⁾.

En dehors de ce micro-troll, Jekyll est très loin de la souplesse offerte par un WordPress, c’est indéniable. Mais encore une fois, n’est-ce pas la racine du problème, pouvoir tout faire ?

Bien qu’on ne foisonne pas de plugins avec cette solution, Jekyll propose les principaux pour gérer le SEO, l’inclusion de JS, les images, le lazyloading…

De vous à moi, nous n’avons pas besoin de plus en fait.

Comment utilisons-nous Jekyll ?

Jusqu’ici, il est possible qu’au fond, vous n’ayez pas encore compris la différence entre un CMS et un SSG. Après tout, tous deux proposent :

• de gérer un site de contenu,
• fonctionnent à partir d’un thème,
• s’appuient sur l’ajout de plugin.

La différence entre un CMS et un SSG

On peut aller plus loin en disant même que sur le front office de votre site, difficile de faire la différence entre un site sous WordPress et un site sous Jekyll n’est-ce pas ?
La différence réside principalement dans la manière de gérer son site.

D’un côté, pour les CMS, vous devez :

• déployer votre CMS sur votre serveur,
• travailler directement dans le back office de votre site
• et… c’est tout. Votre front office est mis à jour en fonction de ce qui se trouve dans la base de données ; ce n’est plus à vous de travailler.

Pour les SSG, la situation est différente :

• vous installez en local Jekyll et son environnement Ruby,
• vous travaillez sur des fichiers de la configuration à l’écriture de contenu,
• vous “compilez” votre site en local
• vous l’envoyez en FTP
• et Voilà !

Une autre différence qui a toute son importance selon moi : un CMS se pilote à la souris alors qu’un SSG, à la ligne de commande / variables dans un fichier. Bien que fondamentalement, cela ne change pas grand chose, aucun système ne vient appuyer la création lorsqu’on travaille avec Jekyll. Et ça, ça oblige à être encore plus concentré à la création de son contenu.

Un exemple ? La gestion des tags. C’est à vous de bien l’écrire dans le “front matter” de votre fichier Jekyll. Ici, pas de menu déroulant qui vous propose déjà une liste. Cerise sur le gâteau, il ne faut pas se tromper dans l’orthographe sous peine de créer une nouvelle catégorie.

Si cela n’est clairement pas optimal et impose des procédures de contrôle. il n’en demeure pas moins que le résultat est là : un site qui répond aux attentes de vos utilisateurs et utilisatrices tout en consommant très peu de ressources.

Jekyll au quotidien

Comme sur tout site web publiant du contenu, notre principale activité avec Jekyll est… de publier du contenu. Original n’est-ce pas ?

Alors, une fois que l’on a installé son environnement Jekyll sur sa machine, comment faire pour ajouter du contenu ? En utilisant des fichiers textes s’appuyant sur le Markdown, tout simplement. Il existe de nombreux convertisseurs en ligne pour passer d’un doc ou une page html à un fichier Markdown. En sommes, c’est un peu comme si vous mettiez à disposition de Jekyll un fichier doc. Il se chargera de l’intégrer sur votre site.

Bien évidemment, il faut ajouter certaines directives à ce fameux fichier. Ces directives sont comprises dans ce qui s’appelle le front matter. Le but de ce billet n’est pas d’apprendre à utiliser Jekyll, mais de comprendre comment il peut venir s’inscrire dans :

• une stratégie de réduction de sa consommation énergétique,
• une stratégie de sécurisation de sa présence sur le web,
• une stratégie de réduction du temps de chargement de son site.

Je me contenterais donc de dire que ce Front matter⁽⁷⁾ s’apprivoise très rapidement et qu’au quotidien, cela se limite à venir copier coller ceux que l’on a déjà fait, tout en les adaptant légèrement.

Jekyll, à mettre entre toutes les mains ?

Si l’on se voulait quelque peu acerbe, on pourrait dire les choses ainsi :
Donc si l’on résume bien, Jekyll, c’est chiant non ?

Honnêtement, c’est bien l’impression que l’on peut avoir en se frottant les premières fois à son interface d’administration très geek. Mais en fait, cela n’est qu’une fausse impression donnée par le fait que l’on doit instancier Jekyll au travers de la ligne de commande.

Mais dans les faits, Jekyll, c’est :

• deux lignes de commandes à comprendre,
• copier coller son front matter,
• convertir son contenu en markdown.

Quand on obtient un temps de réponse de 440 ms sur son LCP avec un hébergement à 10€ par an, quelque soit la charge, on comprend tout de suite pourquoi nous faisons cela :
offrir un web plus responsable, en commençant par nous.