Migration de mon site de Jekyll Ă  Gatsby

  • gatsby
  • jekyll

Published at 2021-09-30

Je viens tout juste de migrer mon site qui utilisait Jekyll vers Gatsby. Dans cet article je vais essayer de faire le bilan de cette migration:

  • pourquoi j'ai fais ce choix?
  • comment j'ai pu rĂ©aliser cette migration?
  • quels on Ă©tĂ© les bĂ©nĂ©fices?

TLDR: Gatsby est un outil avec une courbe d'apprentissage bien plus longue que Jekyll. Il ne fait pas tout out of the box mais c'est un plaisir de développer avec cet outil. Si tu souhaite faire un site et basta, il vaut mieux se tourner vers Jekyll. Si tu veux travailler avec un écosystÚme moderne, alors Gatsby est un meilleur choix.

Un site statique

Pour mon site j'ai fais le choix d'utiliser un outil de générateur de site statique.

Si tu ne connais pas le principe, un générateur de site statique consiste à générer un site sous forme de fichier HTML / CSS / JavaScript lors d'une étape de compilation1. Une fois que c'est fait, le site peut fonctionner sans interprétation cÎté serveur. En d'autre terme, plus besoins de PHP, Ruby ou autre. Il suffira juste déplacer les fichiers sur ton serveur web statique.

Les sites statiques te proposent souvent de rédiger le contenu sous forme de Markdown qui est un langage de balisage trÚs accessible.

Un site statique possÚde beaucoup d'avantages. L'avantage principal est qu'il n'y a pas de base de données ni de langage interprété cÎté serveur. Donc

  1. La sécurité est renforcée. La plupart des failles de sécurité reposent sur le langage interprété cÎté serveur.
  2. Le coĂ»t du serveur est rĂ©duit. J'utilise un simple VPS chez OVH Ă  3€/mois qui hĂ©berge aussi d'autres sites statiques. Et avant de passer chez OVH, j’utilisai un Raspberry PI branchĂ© Ă  ma box SFR
  3. Les performances sont excellentes car le serveur n'a pas besoin d’interprĂ©ter un langage ni de faire des requĂȘtes en base de donnĂ©es.
  4. Le positionnement dans les moteurs de recherche est amélioré, car il dépend directement de la performance du site et notamment du temps de réponse

Je peux te prouver le résultat avec cette commande cURL qui montre le temps de réponse de mon site comparé à wordpress.com (qui est site fonctionnant avec un CMS et une base de données):

curl -w %{time_total} -s -o /dev/null https://rsseau.fr      # 0.010383
curl -w %{time_total} -s -o /dev/null https://wordpress.com/ # 0.467470

On voit donc que mon site répond en 10ms alors que Wordpress en presque une demie seconde. Donc un site statique répond 45 fois plus vite qu'un CMS classique 2.

Cette performance se retranscrit trĂšs bien avec le rĂ©sultat de l'outil PageSpeed de Google qui parlent d'eux mĂȘme:

Capture d'écran de mon résultat PageSpeed

Capture d'écran de mon résultat PageSpeed

Bref, si ton contenu n'est pas voué a évoluer tous les jours et que tu à la possibilité de l'écrire dans un générateur de site statique est la solution.

Jekyll

Étant un fan du langage Ruby, j'avais initialement choisis Jekyll pour gĂ©nĂ©rer mon site. Jekyll est un des outils les plus populaire pour gĂ©nĂ©rer un site statique rapidement. C'est d’ailleurs l'outil utilisĂ© pour Github Pages. C'est un outil que je recommande pour dĂ©buter car il est trĂšs facile Ă  prendre en mains, mĂȘme sans connaissance du langage Ruby.

Mais...

Je me suis fixé comme objectif de monter en compétence sur le design. J'ai donc décider de refaire complÚtement le design de mon site. J'ai trÚs vite rencontré des difficultés.

Je suis habitué aux frameworks frontend. Je ne sais donc plus faire du HTML/CSS "à l'ancienne". Je me suis habitué à l'architecture par composants. La philosophie de Jekyll à utiliser du HTML/CSS natif me ralentissais. Aussi, je travaille majoritairement avec l'écosystÚme JavaScript. Je n'aime pas écrire du JavaScript "à l'ancienne" (a.k.a document.querySelector et autres joyeusetés). C'est totalement objectif mais je voulais me tourner vers une façon de faire moderne.

Mon second point est que Jekyll devient plus compliqué lorsqu'on souhaite sortir des clous. Voici par exemple quelques fonctionnalités qu'il m'était compliqué de développer:

  • intĂ©grer une recherche rapide des articles
  • gĂ©rer correctement l'internationalisation
  • ajouter une section "articles liĂ©es" qui trouve automatiquement les articles ressemblant Ă  celui affichĂ© par l'utilisateur

Mon troisiĂšme point, est que je cherchais Ă  m’expĂ©rimenter sur de nouvelles technologies. Si tu es dĂ©veloppeur, tu sais tout comme moi que le web bouge et trĂšs vite. Les technologies d'il y a quelques annĂ©es ne sont pas obsolĂšte.

Pour conclure, Jekyll faisait trÚs bien le travail et reste un outil trÚs adapté. Il ne me correspondais juste plus.

Quel générateur de site statique choisir?

Il existe plus de 300 générateur de site statique. Il est trÚs difficile de s'y retrouver. Le choix dépend essentiellement de

  1. tes affinités sur un langage ou un framework en particulier
  2. la complexité du site que tu cherches à développer
  3. la taille de ton site. Certains outils sont plus adapté au trÚs gros sites.

Je travaille beaucoup avec l'Ă©cosystĂšme JavaScript et j'ai donc choisis Gatsby!.

Gatsby est est un outil reposant sur React. En plus de React, il intÚgre une surcouche qui va optimiser les performances et intégrer des outils pour construire ton site statique. Au lieu de te décrire ce qu'est Gatsby, laisse moi te montrer pourquoi je l'ai choisis.

Utiliser du JavaScript moderne sans générer une application web lourde

A l'heure du Green IT, on entend beaucoup parler d'éco-conception de site. Cela consiste à limiter les ressources cÎté serveur et cÎté client nécessaire à notre site. C'était un critÚre important pour moi car je souhaite de faire mon maximum pour que mon site soit efficient 3

Les frameworks web-moderne comme React, Vue.js ou Angular sont de superbes outils pour des applications web mais ils peuvent gĂ©nĂ©rer des sites nĂ©cessitant de tĂ©lĂ©charger et d’exĂ©cuter plusieurs mĂ©ga-octets de JavaScript. Je trouve que c'est un non-sens pour un simple blog. Les librairies qu'on charge sur un site reprĂ©sentent une grande quantitĂ© de donnĂ©es.

Les librairies JavaScript pĂšse lourd

Les librairies JavaScript pĂšse lourd

Gatsby répond parfaitement à cela car il effectue tout un tas d'optimisations par défaut:

  1. il s'appuie sur Webpack pour morceler le code en petits fichiers qui ne seront téléchargées que lorsque c'est nécessaire
  2. le code est transpilĂ© lors de l'Ă©tape de compilation, ainsi le site fonctionne mĂȘme si l'utilisateur Ă  dĂ©sactivĂ© JavaScript
  3. et bien d'autres

SEO friendly

Google indexes les pages webs avec son robot qui parcourt le web de liens en liens. Vu la quantité de ressources que cela nécessite, Google définit un budget d'indexation par site et prend plus de temps à indexer un site nécessitant JS.

Les frameworks JavaScript modernes pĂątissent de ce problĂšme car sans JavaScript, le contenu HTML ne peut pas ĂȘtre construit. Voici un exemple avec Twitter:

Capture d'écran de Twitter avec JavaScript désactivé

Capture d'écran de Twitter avec JavaScript désactivé

Il y a plusieurs maniÚre de contourner ce problÚme mais c'est trÚs souvent compliqué à mettre en place.

La bonne nouvelle c'est que Gatsby le fait tout pour nous! Vu que React est exécuté sur notre ordinateur durant l'étape de compilation, le HTML est visible sans JavaScript.

Hackable

Gatsby propose tout un tas de plugins (2824 à l'heure ou j'écris cet article). Ton besoin a déjà été codé par quelqu'un. Imaginons par exemple que tu souhaite:

Si tu souhaites créer ton propre plugin, la documentation est là.

Comment migrer depuis Jekyll

J'ai dĂ©veloppĂ© de zĂ©ro le site avec Gatsby afin de le prendre en main. Cela a Ă©tĂ© le plus gros du travail. NĂ©anmoins, Il est possible d'utiliser un modĂšle prĂȘt Ă  l’emploi de blog pour Gatsby. Cela Ă©vite la partie dĂ©veloppement pur.

Ensuite, concernant la migration du contenu est trÚs facile car Jekyll et Gatsby s'appuient sur le Markdown. Il suffit donc de déplacer les articles et de les retoucher un peu. Dans mon cas j'ai eu besoin:

  • d'uniformiser l'en-tĂȘte frontmater des fichiers Markdown. Tous les articles doivent comporter les mĂȘmes clĂ©s comme date, title, etc...
  • les liens entre les posts peuvent changer. Gatsby utilise des liens relatifs comme [title](./other-post)
  • les URL des images peuvent changer aussi. Dans mon cas j'ai crĂ©e un dossier content/posts/images et j'utilise ses images en faisant ![alt](./images/dog.png)

GĂ©rer la transition pour le SEO

Il est important de prendre en compte le SEO lorsqu'on change l'architecture d'un site 4. Dans mon cas j'avais plusieurs choses Ă  faire:

  1. rediriger les pages ayant changés d'URL avec un statut HTTP 301 - redirect permanent
  2. indiquer les pages ayant disparues avec un statut HTTP 410 - Gone

Pour envoyer ces statuts, il est possible d'utiliser un fichier .htaccess avec Apache.

J'ai donc commencé par exporter mes pages indexées via Google Search Console et j'ai fait le mapping dans le fichier .htaccess. En voici un extrait.

Redirect permanent /benchmarking/2018/11/12/benchmark-templates.html /2018-11-12-benchmark-templates
Redirect permanent /blog/page/2/ /blog
Redirect gone /books/api_on_rails_5-en.html

Afin de mettre en place le fichier .htaccess, j'ai choisis d'utiliser le plugin gatsby-plugin-htaccess. que j'ai configuré rapidement comme ceci

// gatsby-config.js
module.exports = {
  // ..
  plugins: [
    // ...
    {
      resolve: "gatsby-plugin-htaccess",
      options: {
        custom: `
            Redirect permanent /benchmarking/2018/11/12/benchmark-templates.html /2018-11-12-benchmark-templates
            Redirect permanent /blog/page/2/ /blog
            Redirect gone /books/api_on_rails_5-en.html
            ...
        `,
      },
    },
  ],
};

Il faut s'assurer que la configuration apache autorise le .htaccess et ensuite on peut tester la redirection avec cURL

curl https://rsseau.fr/blog/page/2/
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
  <head>
    <title>301 Moved Permanently</title>
  </head>
  <body>
    <h1>Moved Permanently</h1>
    <p>The document has moved <a href="https://rsseau.fr/blog">here</a>.</p>
  </body>
</html>

Et le tour est joué!

Conclusion

Les générateurs de site statiques sont de formidables outils. Gatsby pousse le site statique bien plus loin en donnant la possibilité d'alimenter le contenu avec des données extérieurs (Wordpress, Airtable, etc..) alors que Jekyll permet simplement d'utiliser du Markdown.

Dans mon cas, n'utilisant que du Markdown, la migration de Jekyll à Gatsby n'était pas nécessaire. Si tu utilise aussi Jekyll et que cela te conviens, reste avec Jekyll. Dans mon cas, la motivation de cette migration était vraiment motivée par apprendre de nouveaux outils.

Développer avec Gatsby ma demandé beaucoup d'efforts car c'est un outils beaucoup plus complexe. En revanche, je ne regrette pas le temps que j'y ait investi. Je me servirai trÚs certainement de cet outils lors d'un futur projet.

Gatsby m'a aussi offert la possibilitĂ© d'utiliser des technologies modernes tout en me donnant les performances que j'attendais. Ça a Ă©tĂ© vraiment plaisant de pouvoir utiliser React au seins de mon petit projet!

Aujourd'hui j'ai mon propre systĂšme que je peut faire Ă©voluer comme je le souhaite. Je pourrais trĂšs bien faire Ă©voluer mon site comme un digital garden par exemple.


  1. le terme "compilation" n'est pas tout Ă  fait exacte. L'Ă©tape de build est en fait une transpilation puisqu'on n'obtient pas un binaire mais du HTML/CCS/JS. Afin de vulgariser, je prĂ©fĂšre parler de compilation.↩
  2. mon test n'est vraiment pas poussĂ© car il faudrait bombarder de plusieurs requĂȘtes et lisser les rĂ©sultats.↩
  3. C'est d’ailleurs une des raison pour laquelle j'ai choisis de ne pas intĂ©grer de module de tracking et que je m'appuie sur les logs pour analyser les pages les plus consultĂ©es.↩
  4. J'ai fait le choix de changer les URL de mes articles mais il est possible de reproduire la mĂȘme architecture en pimpant gatsby-node.js.↩

Related posts