Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**Last month, I wrote about Ubuntu Phone, intending to follow up on it this month. Unfortunately, I’ve lacked the time to complete the article for this issue – you can expect it to be in next month’s issue. Instead, I’ll discuss a new website creation tool called ‘static site generation’. If you’re not interested in websites, and want to learn more about Ubuntu Phone programming, check back next month!

What is static site generation?

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, 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 ?

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.


**But… why?

Anyone who has had to work to optimize a page for performance knows that static sites load much faster (and with less effort), because there is no delay while querying the database, or while running for-loops to insert information. Naturally, some sites lend themselves to content management systems (really large sites, sites with various editors and moderators, or sites that need to serve dynamic content). As is always the case in web design, it’s a matter of picking the right tool for the job, in order to create the site as fast as possible, to have it perform well, and to avoid reinventing the wheel at every turn.

But my CMS site loads quickly?

It’s possible to have a site load very quickly when being used with a CMS, but this is generally the result of a great deal of testing, and plenty of performance tweaks.

A comparison

Note: According to studies by Google, any site that takes longer than 1 second to load (on mobile, mainly) will generally have users leave due to the wait. Studies from Amazon and Google also saw that an increase of loading time of 1 second (say, for example, from 400ms to 1.4s) could result in a drop of revenue between 14 and 18%.**

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 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 ?

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

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.**

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?

There are various static site generators on offer. The most common and well-known is Jekyll, which is used for GitHub Pages, among other things. Jekyll uses the Liquid templating language, and is written in Ruby. I, however, am currently using Pelican, and for two main reasons:
It uses Jinja2 for templating, which is the same as Django. Meaning I could carry over existing templates quickly.
It is written in Python, and so has integrated translation options for multilingual sites (using Jinja2 i18n). As my site is always in English and German, this was a big factor for me.

So, depending on what you’re most comfortable with, you may prefer Jekyll over Pelican, or a number of other static site generators over either. Use what you’re comfortable with, as it will help cut down the learning curve. If you want to use plugins for automatic integration of bootstrap (for example), then I would recommend checking the plugin options before choosing a generator.**

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é 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 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.

**Does this mean I can’t use forms, or any dynamic content at all?

Forms are essentially just HTML that gets sent via POST (typically) to a php file. If you use a combination of Nginx and apache (or just apache), you can still include a php file for sending the information around. Depending on what you mean by dynamic content, it should be possible too. iFrames or widgets from other sites shouldn’t be an issue, or, if you want to semi-dynamically create a grid (for example), you can create templates using for-loops to iterate through information in order to insert it into HTML. If you’re looking for login areas and personalized HTML, a CMS will probably be easier for this.

Okay, I’ve installed a generator. What now?

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 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.

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 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?

Since static HTML is so easily served, there are some offerings where you can upload a site without much trouble. For example, GitHub Pages. Technically, you could even host it in some fashion on Dropbox. So, depending on your needs, you may not need to pay for additional hosting - or if you do, you’ll most likely not need too powerful a server to adequately serve the content.

Should I optimize?

Depending on how quickly your site loads, you may not feel you need to. My recommendation, at least, is to optimize images and enable server compression if your site is going to be mobile-friendly. Assuming, of course, that you’ve minimized your CSS and JS already. You’ll most likely not need to do every optimization you can for that last 3% decrease in size, but some basics are recommended.

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 ?

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 ?

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

**Further Reading

Jekyll homepage: https://jekyllrb.com/

Pelican: https://github.com/getpelican/pelican** 

Pour aller plus loin

La page de Jekyll : https://jekyllrb.com/

Celle de Pelican : https://github.com/getpelican/pelican