Nouvelle version du site đŸ’„

— Temps de lecture: 8 minutes

Le passage de PHP Ă  Jekyll #

AprĂšs quelques annĂ©es d’existence, mon ancien site commençait Ă  vieillir.

(Les sources de mon ancien site sont toujours disponibles sur Github, mais remontent Ă  l’époque de mon DUT, soyez indulgents ! 😁)

De plus, le premier et unique article prĂ©sent sur ce site n’était mĂȘme pas hĂ©bergĂ© sur ce site, mais sur un sous-domaine (dĂ©sormais inexistant) et avec la plateforme Ghost (qui est un excellent logiciel libre au passage !).

Cela faisait donc deux sites à maintenir, pour un trafic plus que faible 😀 !

Le choix de PHP avait Ă©tĂ© fait Ă  l’époque car il s’agissait du seul langage que je maitrisais.

En y rĂ©flĂ©chissant, pour effectuer une refonte du site, j’ai listĂ© les points que je souhaitais avoir.

1. Des performances améliorées #

Pour cette refonte, je souhaitais obtenir des performances dignes de ce nom. N’ayant pas de logique cĂŽtĂ© serveur (puisque le but de ce site est simplement de servir du contenu, pas d’effectuer un traitement dessus ou de traiter des donnĂ©es externe), le choix d’un langage cĂŽtĂ© serveur ne me semblait plus trĂšs cohĂ©rent.

Etant donnĂ© que j’ai que du contenu statique, pourquoi ne pas envoyer au client un simple fichier HTML, plutĂŽt que de consommer du temps CPU et des processus PHP pour gĂ©nĂ©rer une page d’une faible complexitĂ© ? Pourquoi ne pas construire une fois toutes les pages nĂ©cessaire, pour n’avoir plus qu’à les servir ensuite, supprimant le temps de gĂ©nĂ©ration de la page cĂŽtĂ© serveur ?

J’ai donc commencĂ© Ă  creuser la question des gĂ©nĂ©rateurs de sites et en ai trouvĂ© plusieurs (le trĂšs bon site StaticGen m’a beaucoup aidĂ© Ă  trouver des ressources et des avis). C’est ainsi que mon choix s’est portĂ© sur Jekyll.

Voici une illustration des performances actuelles du site, ainsi qu’un rapport Dareboost. Je suis assez satisfait du rĂ©sultat, mĂȘme s’il me reste du travail Ă  faire dessus (mais comme le produit parfait n’existe pas, le site parfait n’existe pas non plus ! 😜)

Google page Speed résultat

2. Le contenu prime sur le design (pour moi) #

Je suis un trĂšs mauvais designer et l’intĂ©gration CSS est pour moi un vrai calvaire.

C’est d’ailleurs pour cela que je suis parti d’un template Jekyll que j’ai ensuite adaptĂ© Ă  mes besoins.

Le thĂšme de base que j’ai utilisĂ© peut ĂȘtre consultĂ© ici

NĂ©anmoins, je ne voulais pas d’un thĂšme complexe, qui allait ainsi influer sur les performances du site (plus il y a de CSS et de JS, plus le site sera long Ă  charger pour l’utilisateur). C’est pourquoi le thĂšme que j’ai choisi n’intĂšgre aucun javascript. Ainsi, seule une feuille de style, quelques emojis provenant de Github, et une feuille SVG1 sont chargĂ©es en plus du contenu.

Je n’exclus pas d’utiliser du javascript lorsque je ferai Ă©voluer le site, mais je vais tenter d’en limiter au maximum l’usage.

Certes, le thĂšme du site semblera au mieux austĂšre Ă  certains, au pire hideux Ă  d’autres, 
 Mais au moins, le site est lisible sur (presque, je n’ai pas de montre connectĂ©e pour tester !) tous les supports et charge rapidement 😀

3. La rédaction doit se faire en Markdown et une séparation style/contenu doit exister #

C’est Ă©galement l’une des raisons qui m’a poussĂ© vers les gĂ©nĂ©rateurs de site statiques.

J’aime beaucoup le markdown, et m’en sert beaucoup en cours pour ma prise de note. Il s’agit d’un langage extrĂȘmement simple pour la rĂ©daction, et en mĂȘme temps, trĂšs puissant.

Concernant la séparation style/contenu, les layouts de Jekyll répondent parfaitement à ce besoin.

4. Sécurité #

Je souhaitais un site qui ne sera pas facilement corrompu. Avec des pages HTML, aucune faille PHP / Node / Java / (mettez le nom de votre langage prĂ©fĂ©rĂ© ic) possible. Avec un gĂ©nĂ©rateur de site statique, on gĂ©nĂšre le contenu une fois, on publie le rĂ©sultat et on sert le contenu, c’est tout !

Concernant l’hĂ©bergement, je me suis tout d’abord dis que j’allais profiter de l’hĂ©bergement avec Github Pages. Cela fonctionne trĂšs simplement, mĂȘme avec un domaine personnel, puisqu’il suffit simplement d’utiliser le gestionnaire DNS de son registrar pour faire pointer le domaine sur l’IP de Github Page.

NĂ©anmoins, cela un inconvĂ©nient majeur Ă  mon sens : la maĂźtrise des paramĂštres du site est impossible, que cela soit au niveau du cache, des headers de sĂ©curitĂ©, 
 Github empĂȘche toute modification des headers sur les sites hĂ©bergĂ©s par Github Pages2

Au final, nous ne sommes jamais aussi bien servi que par soi-mĂȘme, j’ai donc utilisĂ© Travis CI pour dĂ©ployer le site gĂ©nĂ©rĂ© sur mon petit Raspberry avec un Rsync : pas besoin de plus compliquĂ©, cela me suffit amplement. Un serveur web devant, un certificat Let’s Encrypt et voilĂ  !

J’ai ainsi pu obtenir une note convenable, selon l’observatoire Mozilla et Cryptcheck. Il me reste nĂ©anmoins un peu de travail Ă  faire sur les CSP (Content Security Policy), ce concept n’est pas Ă©vident Ă  apprĂ©hender 😣 !

5. SEO #

Il s’agit de ma premiĂšre rĂ©elle expĂ©rience SEO3 et Jekyll offre de nombreux plugins4 permettant de gĂ©nĂ©rer des sitemap, un flux RSS, des mĂ©tadonnĂ©es, 
 J’ai donc essayĂ© de tirer profit de cela au maximum.

Workflow #

Mon processus de développement est assez simple :

  • Je dĂ©veloppe en local mes articles et pages.
  • Le code est versionnĂ© sur Github
  • Travis s’assure de la qualitĂ© du site, avec des tests de validitĂ© des liens et des images, ainsi que la structure des pages HTML.
  • Travis dĂ©ploie une version (correspondant Ă  la branche master) de production.
  • Je dĂ©ploie Ă©galement avec une autre branche une version de dĂ©veloppement, qui me permet de tester le site avant d’effectuer un merge sur master :smiley:

Un nouveau site, pour quoi faire #

Ce site va principalement me servir Ă  exposer mes projets rĂ©alisĂ©s, et Ă  effectuer ma veille technologique. J’y Ă©crirais des articles sur mes expĂ©riences de dĂ©veloppement, afin de garder une trace de ce qui m’est arrivĂ©. Je ne m’impose cependant aucun rythme de publication, il est donc possible que le site reste quelques mois sans nouveaux contenus.

Evolutions #

Ce site est fonctionnel, mais pourtant il me reste quelques petits éléments à améliorer/régler.

SystĂšme de commentaire #

Etant sur un site statique, il n’est pas possible d’inclure des commentaires directement, puisqu’il n’y a aucun traitement cĂŽtĂ© serveur.

Evidemment, il est possible d’intĂ©grer des solutions tel que Disqus ou encore Facebook Comments mais ces solutions Ă©tant peu protectrice de notre vie privĂ©e, j’ai prĂ©fĂ©rĂ© chercher une alternative.

AprĂšs quelques recherches, j’ai trouvĂ© 2 solutions :

  1. Isso
  2. Staticman

Le premier est un serveur de commentaire basique et lĂ©ger Ă©crit en Python. Je n’ai pas encore eu beaucoup de temps Ă  consacrer Ă  ce sujet, notament pour l’auto-hĂ©berger, mais je pense qu’il s’agit d’une trĂšs bonne solution et risque de me pencher dessus dans les prochaines semaines !

Le deuxiĂšme semblait trĂšs prometteur mais malheureusement victime de son succĂšs. En effet, il s’agit d’un bot Github, interagissant avec le dĂ©pĂŽt Github, et qui ajoute les commentaires directement dans la branche master ou crĂ©Ă© une pull request si une approbation est nĂ©cessaire avant la publication des commentaire.

De plus, comme indiquĂ© sur leur site, cet outil s’intĂšgre trĂšs bien avec Jekyll et Github. NĂ©anmoins, il utilise l’API Github, et Ă©tant un projet public commençant Ă  prendre de l’ampleur, les limitations de l’API Github semble bloquer/ralentir ce projet, entrainant de nombreuses erreurs.

Une solution pour parer au problĂšme serait d’auto-hĂ©berger le projet avec une clĂ© d’API Github personnelle mais semble beaucoup pour “simplement des commentaires”, mĂȘme si j’aimais beaucoup l’idĂ©e de pouvoir avoir des pull request pour chaque commentaire !

Edit : Les commentaires sont maintenant disponible ! đŸ’„

Voir l’article

Conclusion #

Merci à tous d’avoir lu cet article, j’espùre qu’il vous aura plu.

Si vous avez des remarques, n’hĂ©sitez pas Ă  me faire vos retours !


  1. Scalable Vector Graphics ↩

  2. Ce qui n’est en soit pas une mauvaise chose, si une totale libertĂ© Ă©tait donnĂ© Ă  tous, ils se retrouveraient sĂ»rement avec des sites mal configurĂ©s dans certains cas et leur infrastructure pourrait alors ĂȘtre compromise ! ↩

  3. DĂ©finition WikipĂ©dia du SEO ↩

  4. Pour en citer quelques uns : jekyll-sitemap, jekyll-seo-tag et jekyll-feed ↩