Un blog avec Jekyll et Codeship

Depuis plusieurs mois, ce blog est propulsé par Jekyll et Codeship. Une page explicative existe, mais elle est « vivante » et si je change quelque chose demain, elle évoluera. J’utilise donc un article daté pour figer un peu les choses, et tant pis pour le contenu dupliqué.

Sous le capot

Consultant en Web Performance depuis quelques années, j’ai décidé un jour de ne pas être le cordonnier mal chaussé. Depuis, dans une saine compétition avec mon collègue Nicolas Hoizey, je n’ai de cesse d’en améliorer les temps de réponse.

Côté serveur

J’ai commencé par jeter mon blog Wordpress pour le remplacer par un générateur de site statique en node, Hexo. Après avoir déterminé les limites de l’outil et contribué à quelques plugins, j’ai décidé de migrer vers Jekyll, plus rapide, plus abouti et dont la communauté Ruby me semblait plus mûre.

Mes dépendances Ruby sont gérées par Bundler :

• pour la gestion des ressources statiques (hors images) : jekyll-assets ;
• pour la gestion des archives : jekyll-archives ;
• pour la génération d’images responsive : jekyll-responsive_image ;
• pour le sitemap.xml : jekyll-sitemap.

L’internationalisation est permise par i18n et le i18n_filter¹.

Jekyll ayant tendance à produire du code HTML très « aéré » et aucun moteur de rendu Markdown ne m’ayant convaincu quant à sa capacité à traité certaines spécificités typographiques françaises, j’ai mis en place un script « maison » de remplacement et de compression, libre adaptation de ce tutoriel de Sylvain Durand. De plus, Jekyll ne semble pas proposer de syntaxe simple pour la navigation précédent/suivant au sein d’une même catégorie, j’utilise donc ce plugin d’Adams Clarkson.

En local, j’utilise parfois node, et plus particulièrement gulp et browsersync, pour que mon navigateur se mette seul à jour au fil de mes sauvegardes².

Compilation et déploiement

Mon code est architecturé en deux dépôts. Un dépôt contient les articles du blog au format Markdown, une syntaxe légère idéale pour rédiger³. J’utilise les hooks de GitHub pour interfacer ce dépôt à Codeship (une solution d’intégration continue) qui se charge d’exécuter des tests avec rspec pour vérifier que le contenu des en-têtes Front-Matter sont valides en YAML. Si c’est le cas, alors Codeship publie les articles sur un dépôt public. Puis clone le dépôt Jekyll et met à jour la référence du submodule git⁴.

Ce dépôt, mis à jour, lance également une opération sur Codeship : récupération de la dernière version des articles, du code et des dépendances, compilation de tout cela en un site Web et tests via html-proofer.

Si cette étape d’intégration est valide et que le code est bien contribué sur la branche master, alors Codeship s’occupe du déploiement du site statique ainsi généré chez mon hébergeur, alwaysdata. Le dernier déploiement a été réalisé le 2024-11-12 09:53:48 +0100.

Si tout se passe bien, alors le site se retrouve en Production.

Côté Client

Le chargement des polices privilégie la vitesse en affichant une première version avant qu’elles soient disponibles puis une seconde version une fois les polices chargées, sans clignotement au remplacement⁵.

Une partie de mon code CSS et JS est dédiée à l’accessibilité et j’essaie également de contribuer de manière responsable, pour être le plus inclusif possible à la fois envers les personnes, mais aussi envers les contextes (par exemple, j’utilise la librairie abbr-touch pour permettre aux personnes en situation de mobilité de visualiser la définition d’une abréviation ou d’un acronyme.

La recherche instantanée est le fruit du branchement du site sur Algolia, une solution très performante d’indexation et de recherche côté client qui a le mérite de proposer un exemple d’implémentation pour Jekyll qui cadrait parfaitement avec mon besoin. Il faudra néanmoins que je repasse dessus car le code JavaScript nécessaire me semble un peu complexe (jQuery, Hogan, MomentJs… je dois pouvoir faire plus simple).

J’ai ajouté au site InstantClick, une librairie JavaScript qui augmente considérablement la vitesse perçue en préchargement les pages internes au survol des liens, donnant l’impression à l’utilisateur que l’ensemble du site est préchargé, comme dans une application web single page.

Afin de contrôler ce qui se passe sur mon site (notamment pour détecter des tentatives d’injections), j’ai positionné un certain nombre de règles Content Security Policy et des rapports sont enregistrés dans une base de données à chaque infraction⁶.

Parce que je suis curieux, j’ai installé Google Analytics. Je suis conscient que certains d’entre vous veulent un peu d’intimité. Je vous encourage, dans ce cas, à faire comme moi : bloquer l’ensemble des domaines auxquels vous ne souhaitez pas faire confiance, au sein de votre navigateur ou ailleurs sur votre machine. Ça passe par la manipulation de votre fichier hosts et il y a des scripts pour automatiser tout ça⁷. Enfin, contrairement aux ads blockers, c’est transparent en performance.

1. La technique de localisation est détaillée dans le guide de démarrage Jekyll de Thomas Brelet. ↩

2. voir l’article de Vladimir Iakovlev. ↩

3. Lire à ce propos cet excellent article de Romy sur les syntaxes légères ↩

4. Ne ratez pas cette présentation complète des submodules git par Christophe Porteneuve ↩

5. Les articles du Filament Group sur le chargement des polices sont de très bonnes références si le sujet vous intéresse. ↩

6. Merci à Nicolas Hoffman de m’avoir sensibilisé à cette problématique durant sa présentation à Paris Web 2015. ↩

7. J’utilise pour ma part les scripts de blocage de domaines de Steven Black. ↩