Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue103:c_c [2015/12/12 14:08] – auntiee
+++ issue103:c_c [2015/12/13 12:02] (Version actuelle) – andre_domenech
@@ Ligne 38: / Ligne 38: @@
 **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, 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?
@@ Ligne 51: / Ligne 51: @@
 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 compte 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.
@@ Ligne 70: / Ligne 72: @@
 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?
@@ Ligne 82: / Ligne 84: @@
 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 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.
+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 ?