| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| issue103:c_c [2015/12/11 23:39] – erlevo | issue103:c_c [2015/12/13 12:02] (Version actuelle) – andre_domenech |
|---|
| Static site generators are command-line tools that can take content from formats such as markdown and reStructuredText, and insert the content into HTML templates. At the most basic, you can think of it as a content management system that, when compiled, doesn’t save content to a database, but straight into a static html page.** | Static site generators are command-line tools that can take content from formats such as markdown and reStructuredText, and insert the content into HTML templates. At the most basic, you can think of it as a content management system that, when compiled, doesn’t save content to a database, but straight into a static html page.** |
| |
| Le mois dernier j'ai fait un article sur les téléphones Ubuntu avec l'intention de le poursuivre ce mois-ci. Malheureusement, j'ai manqué de temps pour être prêt pour ce numéro – attendez-vous à ce qu'il soit dans le prochain. À la place je vais parler d'un outil de création de nouveau site web appelé "génération de site statique". Si les sites web ne vous intéressent pas mais que vous souhaitez en apprendre plus sur la programmation des téléphones Ubuntu, ne manquez pas le prochain article. | Le mois dernier j'ai fait un article sur les téléphones Ubuntu avec l'intention de le poursuivre ce mois-ci. Malheureusement, par manque de temps, je n'ai pas pu être prêt pour ce numéro ; attendez-vous à ce qu'il soit dans le prochain. À la place je vais parler d'un outil de création de nouveau site Web appelé « génération de site statique » (static site generation). Si les sites Web ne vous intéressent pas, mais que vous souhaitez en apprendre plus sur la programmation des téléphones Ubuntu, ne manquez pas le prochain article. |
| |
| Qu'est-ce que la génération de site statique ? | Qu'est-ce que la génération de site statique ? |
| |
| Le générateur de site statique est un outil en ligne de commande qui accepte des contenus de divers formats tel que Markdown et reStructuredText, et les insère dans des trames HTML. En première approche, vous pouvez l'assimiler à un gestionnaire de contenus (NdT : CMS) qui, une fois compilé, n'enregistre pas le contenu dans une base de données mais directement dans une page HTML statique. | Un générateur de site statique est un outil en ligne de commande qui accepte des contenus de divers formats, tels que Markdown et reStructuredText, et les insère dans des trames HTML. En première approche, vous pouvez l'assimiler à un gestionnaire de contenus [Ndt : CMS] qui, une fois compilé, n'enregistre pas le contenu dans une base de données, mais directement dans une page HTML statique. |
| |
| |
| Mais... pourquoi ? | Mais... pourquoi ? |
| |
| Toute personne qui a eu à travailler à l'optimisation d'une page pour des questions de performance sait que des sites statiques se chargent plus vite (et avec moins d'efforts), parce qu'il n'y a pas à interroger une base de données ou attendre qu'une boucle ait inséré les informations. Quelques sites se prêtent par essence aux gestionnaires de contenus (de très gros sites ou des sites comportant plusieurs éditeurs ou modérateurs ou des sites qui délivrent des contenus dynamiques). Comme c'est toujours le cas dans l'élaboration d'un site il s'agit de choisir l'outil adapté, de façon à créer un site aussi rapide que possible afin qu'il soit performant et éviter de réinventer la roue à chaque fois. | Toute personne qui a eu à travailler à l'optimisation d'une page pour des questions de performance sait que des sites statiques se chargent plus vite (et avec moins d'efforts), parce qu'il n'y a pas à interroger une base de données ou à attendre qu'une boucle for ait inséré les informations. Quelques sites se prêtent par essence aux gestionnaires de contenus (de très gros sites ou des sites comportant plusieurs éditeurs ou modérateurs ou des sites qui délivrent des contenus dynamiques). Comme c'est toujours le cas dans l'élaboration d'un site, il s'agit de choisir l'outil adapté, de façon à créer un site aussi rapide que possible afin qu'il soit performant et à éviter de réinventer la roue à chaque fois. |
| |
| Mais mon site CMS se charge rapidement ? | Mais mon site CMS se charge rapidement ? |
| |
| Il est possible d'avoir un site qui se charge très rapidement alors qu'il est animé par un CMS, mais c'est habituellement le résultat d'un très grand nombre de tests et de d'ajustements. | Il est possible d'avoir un site qui se charge très rapidement alors qu'il est animé par un CMS, mais c'est habituellement le résultat d'un très grand nombre de tests et d'ajustements. |
| Une comparaison | Une comparaison |
| Note : Selon des études faites par Google, tout site dont le chargement prend plus d'une seconde (principalement sur les téléphones mobiles), découragera les utilisateurs du fait de l'attente. Des études d'Amazon et de Google montrent également qu'un accroissement du temps de chargement de 1 seconde (disons de 400 ms à 1,4 s) peut entraîner une chute de chiffre d'affaire de l'ordre de 14 à 18 %. | |
| | Note : Selon des études faites par Google, tout site dont le chargement prend plus d'une seconde (principalement sur les téléphones mobiles), découragera les utilisateurs du fait de l'attente. Des études d'Amazon et de Google montrent également qu'un accroissement du temps de chargement de 1 seconde (disons de 400 ms à 1,4 s) peut entraîner une chute de chiffre d'affaires de l'ordre de 14 à 18 %. |
| |
| **A site I am working on was originally created using Django CMS - where it would load in about 612ms from my local machine (with no network latency, a quad core CPU, and an SSD), which is perfectly reasonable. Shifting it to an Nginx server running uwsgi saw the load times jump up to 700-800ms. However, the more content that was added to the page, the longer it would take. Version 3.2 of Django CMS seems to have improved on the speed, but it is not, as of writing, at a final release. The equivalent site using Pelican (a static site generator) loads in 402ms, and the only optimization I have done so far is to merge my CSS files. There is no compression of any sort running, and is being served only with python http.server. As the site is a redesign for my own company, and I will be the only one managing it, I have no need for a CMS – I could just as easily write the HTML by hand. However, the number of pages make it unreasonable to create everything by hand, which is where Pelican comes in. I can manage my content easily in reStructuredText (or, theoretically, anyone who knows Markdown, HTML, or reStructuredText), and can assign various templates to the pages, according to the meta information. The resulting static site can be hosted easily and quickly on Nginx, and use less resources than a Django CMS setup running Nginx, uwsgi, and postgresql. Note: this is not a criticism of Django CMS, as I could probably optimize my approach in order to reduce load times. A static site generator simply reduces the amount of optimization I need to accomplish.** | **A site I am working on was originally created using Django CMS - where it would load in about 612ms from my local machine (with no network latency, a quad core CPU, and an SSD), which is perfectly reasonable. Shifting it to an Nginx server running uwsgi saw the load times jump up to 700-800ms. However, the more content that was added to the page, the longer it would take. Version 3.2 of Django CMS seems to have improved on the speed, but it is not, as of writing, at a final release. The equivalent site using Pelican (a static site generator) loads in 402ms, and the only optimization I have done so far is to merge my CSS files. There is no compression of any sort running, and is being served only with python http.server. As the site is a redesign for my own company, and I will be the only one managing it, I have no need for a CMS – I could just as easily write the HTML by hand. However, the number of pages make it unreasonable to create everything by hand, which is where Pelican comes in. I can manage my content easily in reStructuredText (or, theoretically, anyone who knows Markdown, HTML, or reStructuredText), and can assign various templates to the pages, according to the meta information. The resulting static site can be hosted easily and quickly on Nginx, and use less resources than a Django CMS setup running Nginx, uwsgi, and postgresql. Note: this is not a criticism of Django CMS, as I could probably optimize my approach in order to reduce load times. A static site generator simply reduces the amount of optimization I need to accomplish.** |
| |
| Le site sur lequel je travaille actuellement a été créé à l'aide du CMS Django – à partir duquel il se charge localement en 612ms environ FIXME je supprimerais le « environ » qui me fait franchement rigoler (sans latence réseau, un CPU quatre cœurs et un SSD) ce qui est tout à fait acceptable. En passant sur un serveur Nginx (NdT : serveur à hautes performances) tournant sur uWSGI (NdT : conteneur d'applications et de CMS rapide), le temps de chargement monte à 700 - 800 ms. Toutefois, plus on ajoute de contenu à la page, plus le temps de chargement est long. La version 3.2 du CMS Django semble être plus rapide mais n'est pas, au moment où j'écris, dans sa version définitive. Le site équivalent, utilisant Pelican (un générateur de site statique) se charge en 402 ms et l'unique optimisation que j'ai faite jusqu'à présent est d'y intégrer les fichiers CSS. Je n'en ai fait aucune compression et elle n'utilise que des serveurs HTTP sous Python. Comme le site est une refonte pour ma propre société, je serai le seul à l'administrer, je n'aurai aucun besoin de CMS - je peux tout aussi simplement écrire le HTML. Toutefois le nombre de pages rend la fabrication manuelle irréaliste et c'est là qu'intervient Pelican. Je peux gérer facilement mon contenu en reStructuredText (ou, suivant les connaissance de chacun, Markdown, HTML ou reStructuredText) et peux attribuer différents canevas aux pages, en fonction des meta informations. Le site statique résultant peut être facilement et rapidement hébergé sous Nginx et utiliser moins de ressources qu'une configuration de CMS Django tournant sous Nginx, uWSGI et postgresql. Note : ce n'est pas une critique du CMS Django car je peux probablement optimiser mon approche de façon à réduire le temps de chargement. Un générateur de site statique me permet simplement de diminuer le travail d'optimisation. | Le site sur lequel je travaille actuellement a été créé à l'aide du CMS Django, à partir duquel il se charge localement en plus ou moins 612 ms (sans latence réseau, un CPU quatre cœurs et un SSD) ce qui est tout à fait acceptable. En passant sur un serveur Nginx [Ndt : serveur à hautes performances] tournant sous uWSGI [Ndt : conteneur d'applications et de CMS rapide], le temps de chargement monte à 700/800 ms. Toutefois, plus on ajoute de contenu à la page, plus le temps de chargement est long. La version 3.2 du CMS Django semble être plus rapide, mais n'est pas, au moment où j'écris, dans sa version définitive. Le site équivalent, utilisant Pelican (un générateur de site statique) se charge en 402 ms et l'unique optimisation que j'ai faite jusqu'à présent est d'y fusionner mes fichiers CSS. Je n'en ai fait aucune compression et elle n'utilise que des serveurs HTTP sous Python. Comme le site est une refonte pour ma propre société, je serai le seul à l'administrer et je n'aurai aucun besoin de CMS, je peux tout aussi simplement écrire le HTML. Toutefois le nombre de pages rend la fabrication manuelle irréaliste et c'est là qu'intervient Pelican. Je peux gérer facilement mon contenu en reStructuredText (ou, suivant les connaissances de chacun, en Markdown ou HTML) et peux attribuer différents canevas aux pages, en fonction des meta-informations. Le site statique résultant peut être facilement et rapidement hébergé sous Nginx et utiliser moins de ressources qu'une configuration de CMS Django tournant sous Nginx, uWSGI et postgresql. Note : ce n'est pas une critique du CMS Django car je peux probablement optimiser mon approche de façon à réduire le temps de chargement. Un générateur de site statique me permet simplement de diminuer le travail d'optimisation. |
| |
| **I’m sold! Where do I start? | **I’m sold! Where do I start? |
| Vendu ! Par où dois-je commencer ? | Vendu ! Par où dois-je commencer ? |
| |
| Il existe différents générateurs de sites statiques. Le plus diffusé et le plus connu est Jekyll, utilisé pour les pages GitHub, en particuliers. Jekyll utilise le langage de trame (templating) Liquid qui est écrit en Ruby. Néanmoins j'utilise Pelican à l'heure actuelle et cela pour deux raisons : | Il existe différents générateurs de sites statiques. Le plus diffusé et le plus connu est Jekyll, utilisé notamment pour les pages GitHub. Jekyll utilise le langage de trame (templating) Liquid qui est écrit en Ruby. Néanmoins j'utilise Pelican à l'heure actuelle et cela pour deux raisons : |
| Il utilise Jinja2pour les trames, le même langage que Django. Ce qui signifie que je peux importer rapidement des trames existantes. | |
| Il est écrit en Python et a de ce fait des options de traduction intégrées pour les sites multilingues (en utilisant Jinja2 i18n). Comme mon site est toujours à la fois en anglais et en allemand cela comptait beaucoup pour moi. | Il utilise Jinja2 pour les trames, le même langage que Django. Ce qui signifie que je peux importer rapidement des trames existantes. |
| | |
| | Il est écrit en Python et a, de ce fait, des options de traduction intégrées pour les sites multilingues (en utilisant Jinja2 i18n). Comme mon site est toujours à la fois en anglais et en allemand, cela compte beaucoup pour moi. |
| |
| Donc, en fonction de ce qui vous convient le mieux, vous choisirez plutôt Jekyll que Pelican ou l'un des nombreux autres générateurs de sites statiques. Choisissez celui qui vous va le mieux car cela réduira le temps d'apprentissage. Si vous voulez utiliser des options (plugins) pour l'intégration automatique de programmes d'amorçage (par exemple), je vous recommande de bien contrôler les options avant de choisir votre générateur. | Donc, en fonction de ce qui vous convient le mieux, vous choisirez plutôt Jekyll que Pelican ou l'un des nombreux autres générateurs de sites statiques. Choisissez celui qui vous va le mieux, car cela réduira le temps d'apprentissage. Si vous voulez utiliser des options (plugins) pour l'intégration automatique de programmes d'amorçage (par exemple), je vous recommande de bien contrôler les options avant de choisir votre générateur. |
| |
| **Does this mean I can’t use forms, or any dynamic content at all? | **Does this mean I can’t use forms, or any dynamic content at all? |
| Now would be the time to check the homepage and view the documentation. As each generator has a slightly different file structure, and different commands to compile, it’s necessary to check the documentation. Once you’ve created a project (most likely done with a quickstart command), then it’s time to create some sample content, and a template (or to adjust an existing template).** | Now would be the time to check the homepage and view the documentation. As each generator has a slightly different file structure, and different commands to compile, it’s necessary to check the documentation. Once you’ve created a project (most likely done with a quickstart command), then it’s time to create some sample content, and a template (or to adjust an existing template).** |
| |
| Cela signifie-t-il que je ne peux pas utiliser du tout de masque de saisie ou de contenu dynamique ? | Cela signifie-t-il que je ne peux point utiliser de masque de saisie ou de contenu dynamique ? |
| |
| Les masques sont constitués essentiellement de HTML envoyé par POST (habituellement) vers un fichier php. Si vous utilisez une combinaison de Nginx et Apache (ou simplement Apache), vous pouvez toujours inclure un fichier php pour transmettre les données. En fonction de ce que vous entendez par fichier dynamique, ce devrait être également possible. Les iFrames ou les widgets d'autres sites ne posent pas de problème ou, si vous voulez créer de façon semi-dynamique une grille (par exemple), vous pouvez créer une trame (template) qui s'incrémentera en fonction des informations grâce à une boucle for de façon à l'intégrer dans le HTML. Si vous recherchez des zones d'enregistrement (Login) et du HTML personnalisé, il sera plus simple d'utiliser alors un CMS. | Les masques sont constitués essentiellement de HTML envoyé par POST (habituellement) vers un fichier php. Si vous utilisez une combinaison de Nginx et Apache (ou simplement Apache), vous pouvez toujours inclure un fichier php pour transmettre les données. En fonction de ce que vous entendez par fichier dynamique, ce devrait être également possible. Les iFrames ou les widgets d'autres sites ne posent pas de problème ou, si vous voulez créer de façon semi-dynamique une grille (par exemple), vous pouvez créer une trame (template) qui s'incrémentera en fonction des informations grâce à une boucle for de façon à l'intégrer dans le HTML. Si vous recherchez des zones d'enregistrement (Login) et du HTML personnalisé, il sera plus simple d'utiliser alors un CMS. |
| Bien, j'ai installé un générateur. Et maintenant ? | Bien, j'ai installé un générateur. Et maintenant ? |
| |
| Maintenant il va falloir mettre au point la page d'accueil et regarder la documentation. Comme chaque générateur a une structure de fichier légèrement différente et des commandes différentes à compiler, il va être nécessaire de consulter la documentation. Une fois que vous avez créé un projet (le plus souvent avec la commande quickstart) il est alors bon de créer quelques contenus exemples et une trame (ou d'ajuster une trame existante). | Maintenant il va falloir mettre au point la page d'accueil et regarder la documentation. Comme chaque générateur a une structure de fichier légèrement différente et des commandes différentes pour compiler, il va être nécessaire de consulter la documentation. Une fois que vous aurez créé un projet (le plus souvent avec la commande quickstart), il est alors bon de créer quelques contenus exemples et une trame (ou d'ajuster une trame existante). |
| |
| **My site is done...do I have to buy hosting? | **My site is done...do I have to buy hosting? |
| I hope this article has been interesting for anyone looking at, or working on, a project where you keep thinking “this site is almost too small for a CMS, but too large for doing it by hand!”. Or anyone interested in creating a quick project website for GitHub. If you have questions, suggestions, or comments, you can reach me at lswest34+fcm@gmail.com.** | I hope this article has been interesting for anyone looking at, or working on, a project where you keep thinking “this site is almost too small for a CMS, but too large for doing it by hand!”. Or anyone interested in creating a quick project website for GitHub. If you have questions, suggestions, or comments, you can reach me at lswest34+fcm@gmail.com.** |
| |
| Mon site est terminé… Dois-je acheter un hébergement ? | Mon site est terminé... Dois-je acheter un hébergement ? |
| |
| Puisque le HTML statique est très facilement géré, vous trouverez quelques endroits où l'on peut charger un site sans trop de problèmes. Les GitHub Pages par exemple. Techniquement vous pourriez même les stocker, de façon exotique, sur Dropbox. Donc, en fonction de vos besoins, vous pourriez ne pas avoir à payer d'hébergement additionnel – ou, si c'était le cas, vous ne devriez pas avoir besoin d'un serveur très puissant pour gérer le contenu. | Puisque le HTML statique est très facilement géré, vous trouverez quelques endroits où l'on peut charger un site sans trop de problèmes. Les GitHub Pages par exemple. Techniquement, vous pourriez même le stocker, de façon exotique, sur Dropbox. Ainsi, en fonction de vos besoins, vous pourriez ne pas avoir à payer d'hébergement additionnel, ou, si c'était le cas, vous ne devriez pas avoir besoin d'un serveur très puissant pour gérer le contenu. |
| |
| Dois-je optimiser ? | Dois-je optimiser ? |
| |
| Cela dépend de la vitesse à laquelle votre site se charge, vous pourriez n'en avoir pas besoin. Ma recommandation néanmoins serait d’optimiser les images et d'autoriser la compression du serveur si votre site doit être compatible avec le monde des mobiles. Partant du principe bien sûr que vous avez minimisé votre CSS et votre JS il est fort probable qu'il ne soit pas nécessaire de faire toutes les optimisations possibles pour gagner les 3 derniers pour cent de réduction de taille. Toutefois une optimisation basique est nécessaire. | Selon la vitesse à laquelle votre site se charge, vous pourriez n'en avoir pas besoin. Ma recommandation néanmoins serait d’optimiser les images et d'autoriser la compression du serveur si votre site doit être compatible avec le monde des mobiles. Partant du principe, bien sûr, que vous avez déjà minimisé votre CSS et votre JS, il est fort probable qu'il ne soit pas nécessaire de faire toutes les optimisations possibles pour gagner les 3 derniers pour cent de réduction de taille. Toutefois une optimisation basique est recommandée. |
| |
| J'espère que cet article aura intéressé ceux qui envisagent, ou travaillent sur, un projet et qui continuent de se dire que « ce site est pratiquement trop petit pour un CMS mais trop important pour être écrit à la main ». Ou ceux qui pourraient être intéressés par la création d'un site sur GitHub. Si vous avez des questions, suggestions ou commentaires, vous pouvez me contacter à lswest34+fcm@gmail.com | J'espère que cet article aura intéressé ceux qui envisagent, ou travaillent sur, un projet et qui continuent de se dire que « ce site est pratiquement trop petit pour un CMS mais trop important pour être écrit à la main ». Ou ceux qui pourraient être intéressés par la création d'un site sur GitHub. Si vous avez des questions, suggestions ou commentaires, vous pouvez me contacter à lswest34+fcm@gmail.com |
| La page de Jekyll : https://jekyllrb.com/ | La page de Jekyll : https://jekyllrb.com/ |
| |
| celle de Pelican : https://github.com/getpelican/pelican | Celle de Pelican : https://github.com/getpelican/pelican |
