Jekyll / Octopress et d'autres moteurs de blogs statiques pourraient-ils être une bonne option pour un magazine en ligne lourd?
(Avertissement: je pensais que cette question devrait être posée sur SuperUser, mais il semble que ce n'était pas le bon endroit. J'espère que celui-ci est plus approprié.)
J'explore plusieurs options pour configurer un moteur de blogging statique et y migrer le contenu de certains blogs que j'ai. J'aimerais tester les performances de ces moteurs et j'ai entendu de bonnes choses de Jekyll et d'Octopress.
Je me demande cependant si ce type de moteur conviendrait aux sites lourds , qui sont mis à jour 20-30 fois par jour (ou plus) et reçoivent un bon nombre de visites chaque jour (posons un nombre hypothétique de départ: 1 million uniques par mois).
WordPress est un fantastique CMS, avec beaucoup de potentiel sur tous les plans, mais il existe des plugins de cache tels que W3 Total Cache qui permettent à certaines parties du blog/magazine de se comporter de manière statique, la dépendance d’autres parties et surtout La nécessité d'accéder à MySQL en permanence peut rendre le blog problématique.
Etant donné que les moteurs de blogs statiques n’ont pas besoin de base de données, je me demande s’il serait fou d’essayer d’adapter l’un d’eux à publier un magazine dans lequel tous les articles seraient des pages Web statiques et qui aurait des commentaires basés par exemple dans Disqus. Y at-il des problèmes techniques avec cette idée?
Rappelant mes idées, voici les avantages et les inconvénients:
Pros
- Tout est statique (sauf les commentaires, Disqus là)
- Pas d'accès à la base de données, probablement meilleurs temps de chargement/réponse
Inconvénients
- Pas beaucoup de plugins (oui, Octopress en a )
- La personnalisation n'est pas aussi facile ni aussi puissante
- Publier des messages?
- Docs et communauté inférieurs à Wordpress si vous avez besoin d'aide - n exemple fantastique ;)
Un très grand nombre de sites très fréquentés/à fort trafic sont passés à des générateurs de sites statiques tels que Jekyll et Octopress. Cependant, s'il existe des avantages en termes de performances, de déploiement et de sécurité sur un site statique, ils présentent également de nombreux inconvénients. De nos jours, la plupart des sites Web sont dynamiques et la plupart des CMS ne sont pas des générateurs de sites statiques.
Les principaux inconvénients à prendre en compte sont les suivants:
Temps de génération du site
Un repas gratuit n'existe pas. Les générateurs de sites statiques ne suppriment pas la génération de pages et le traitement que font les CMS conventionnels; ils dévient simplement cette tâche vers un endroit/une heure différente. Le même travail reste à faire, mais au lieu de scinder ce travail en plusieurs centaines, voire plusieurs milliers de demandes, le générateur le fait tout en même temps. Cela peut faire économiser à vos visiteurs de précieuses millisecondes, mais cela peut vraiment s’ajouter au temps de génération du site.
Au fur et à mesure que votre site grandit (ou si vous convertissez un site qui compte déjà un nombre important de pages), vos temps de génération permettent d'effectuer des modifications de mise en page (navigation, titre, pied de page, contenu de la barre latérale, etc.), de générer un tag ou Les pages d'archives, etc. commencent à prendre de plus en plus de temps. Je recommande fortement de lire le compte rendu de ce commutateur par le webmaster avant de vous lancer vous-même.
Donc, si vous avez un site volumineux qui dépend de mises à jour ponctuelles, vous devrez peut-être vous débarrasser de fonctionnalités telles que les balises, les articles associés, les pages d'archives, etc. afin que le site ne vous prenne pas une heure à chaque fois que vous créez un site. poster.
Heureusement, si le délai de mise à jour du contenu n'affecte pas votre site, vous pouvez probablement automatiser le processus de sorte que vos rédacteurs de contenu soumettent simplement leurs publications dans une file d'attente de mise à jour et que le script de mise à jour gère la génération du site en arrière-plan. Cela peut prendre encore une heure avant que le poste soit créé, mais cela ne fait perdre du temps à personne.
Les sites statiques ont une fonctionnalité très limitée
Vous pouvez incorporer des composants non statiques dans votre site, mais cela supprime de nombreux avantages liés à l'exécution d'un site statique et vous oblige également à gérer votre site à partir de plusieurs emplacements. Et certaines fonctionnalités ne peuvent tout simplement pas être fournies via un service intégré SaaS, par exemple. gestion de contenu en direct, commentaires conviviaux pour les moteurs de recherche, sans JS +, gestion des utilisateurs, etc.
Autres fonctionnalités, telles que la recherche par facettes, la navigation dynamique (par exemple les publications les plus populaires , , les pages récentes , le balisage de communauté, etc.), Web services (SOAP/XML-RPC), la gestion de session, etc. deviennent vraiment difficiles et difficiles à mettre en œuvre. En gros, vous devez être sûr de ne pas vouloir étendre votre site au-delà d’un blog de base.
Heureusement, cependant, la plupart des sites de blogs peuvent voir leurs fonctionnalités essentielles implémentées sur un site statique. Les inconvénients ne sont donc pas aussi graves que pour d’autres types de sites (sites communautaires ou de membres, sites de commerce électronique, etc.); il s'agit donc simplement de peser les coûts par rapport aux avantages. Il n’ya pas vraiment de bonne ou de mauvaise réponse ici, et cela dépend autant des préférences personnelles que des exigences du site.
Toutefois, si les performances sont principalement motivées par le passage à un générateur de site statique, vous devez probablement commencer par explorer d’autres options telles que:
- déchargement d'actifs statiques sur un serveur Web léger tel que nginx + un domaine sans cookie
- utilisation de la mise en cache de page complète (qui, après la première demande de la page, revient essentiellement à avoir une page statique)
- mise en cache des requêtes afin que les requêtes de base de données se produisent rarement
- utiliser la mise en cache côté client
- consolider les ressources pour minimiser les requêtes HTTP
- augmentation des téléchargements parallèles
Si vous configurez correctement le site dynamique, son chargement risque d’être plus rapide que celui d’un site statique qui utilise un ensemble d’incorporations JS tierces pour des commentaires tels que des rétroliens, etc. Comme le propose John dans vos commentaires, vous devriez en fait Analysez votre site et découvrez où se trouvent vos véritables goulots d'étranglement en termes de performances. Il se peut qu’une consolidation CDN ou CSS/JS présente un avantage en performances plus performant pour votre site que le passage à un site statique qui ajoute encore plus de dépendances JS et tierces.
Je ne comprends pas. Si vous utilisez la mise en cache appropriée, que faut-il interroger la base de données tout le temps, comme vous le dites? Et est-ce quelque chose que vous devez utiliser? Si oui, ne devrez-vous pas l'utiliser sur un site statique?
1M uniques par mois équivaut à 24 uniques par minute. Ce n'est pas une charge lourde, même pour un VPS à mi-portée. Surtout si vous cachez des choses. Et vous pouvez toujours utiliser quelque chose comme nginx pour rendre la distribution des parties statiques plus efficace (images, etc.).