Catégories
Astuces et Design

Comparaison des temps de construction du générateur de site statique

Il y a tant générateurs de sites statiques (SSG). Il est extrêmement difficile de décider par où commencer. Bien qu'une abondance d'articles utiles puisse aider à parcourir les options (populaires), ils ne facilitent pas la décision par magie.

J'ai cherché à faciliter cette décision. Un de mes collègues a construit une feuille de triche d'évaluation du générateur de site statique. Il fournit un très bon aperçu de nombreux choix SSG populaires. Ce qui manque, c'est la manière dont ils se comportent réellement en action.

Une caractéristique commune de chaque générateur de site statique est qu'il prend des données d'entrée, les exécute via un moteur de création de modèles et génère des fichiers HTML. Nous appelons généralement ce processus La construction.

Il y a trop de nuances, de contexte et de variabilité nécessaires pour comparer les performances de divers SSG pendant le processus de construction pour s'afficher sur une feuille de calcul – et commence ainsi notre test pour comparer les temps de construction aux générateurs de sites statiques populaires.

Il ne s’agit pas seulement de déterminer quel SSG est le plus rapide. Hugo a déjà cette réputation. Je veux dire, ils le disent sur leur site Web – Le cadre le plus rapide au monde pour la création de sites Web – donc ça doit être vrai!

Il s'agit d'une comparaison approfondie des temps de construction entre plusieurs SSG populaires et, plus important encore, pour analyser Pourquoi ces temps de construction ressemblent à eux. Choisir aveuglément le plus rapide ou discréditer le plus lent serait une erreur. Voyons pourquoi.

Les tests

Le processus de test est conçu pour commencer simplement – avec seulement quelques SSG populaires et un format de données simple. Une base sur laquelle étendre à plus de SSG et à des données plus nuancées. Pour aujourd'hui, le test comprend six choix SSG populaires:

Chaque test a utilisé l'approche et les conditions suivantes:

  • La source de données pour chaque build sont des fichiers Markdown avec un titre (en tant que frontmatter) et un corps (contenant trois paragraphes de contenu) générés aléatoirement.
  • Le contenu ne contient aucune image.
  • Les tests sont exécutés en série sur une seule machine, ce qui rend les valeurs réelles moins pertinentes que la comparaison relative entre le lot.
  • La sortie est du texte brut sur une page HTML, exécutée via le démarreur par défaut, en suivant le guide respectif de chaque SSG pour démarrer.
  • Chaque test est un course à froid. Les caches sont effacés et les fichiers Markdown sont régénérés pour chaque test.

Ces tests sont considérés référence des tests. Ils utilisent des fichiers Markdown de base et produisent du HTML sans style dans la sortie intégrée.

En d'autres termes, la sortie est techniquement un site Web qui pourrait être déployé en production, même s'il est pas vraiment un scénario du monde réel. Au lieu de cela, cela fournit une comparaison de base entre ces cadres. Les choix que vous faites en tant que développeur utilisant l'un de ces frameworks ajusteront les temps de construction de différentes manières (généralement en le ralentissant).

Par exemple, une façon dont cela ne représente pas le monde réel est que nous testons constructions froides. Dans le monde réel, si vous avez 10 000 fichiers Markdown comme source de données et que vous utilisez Gatsby, vous allez utiliser le cache de Gatsby, qui très réduisez les temps de construction (jusqu'à la moitié).

La même chose peut être dite pour builds incrémentiels, qui sont liés aux exécutions à chaud et à froid en ce sens qu'ils ne construisent que le fichier qui a changé. Nous ne testons pas l'approche incrémentielle dans ces tests (pour le moment).

Les deux niveaux de générateurs de sites statiques

Avant de faire cela, considérons d'abord qu'il y en a vraiment deux niveaux de générateurs de sites statiques. Appelons-les de base et Avancée.

  • Générateurs de base (qui ne sont pas de base sous le capot) sont essentiellement une interface de ligne de commande (CLI) qui prend des données et génère du HTML, et peut souvent être étendue pour traiter les actifs (ce que nous ne faisons pas ici).
  • Les générateurs avancés offrent quelque chose en plus de la sortie d'un site statique, comme le rendu côté serveur, les fonctions sans serveur et l'intégration du framework. Ils ont tendance à être configurés pour être plus dynamiques dès la sortie de la boîte.

J'ai choisi intentionnellement trois de chaque type de générateur dans ce test. Tomber dans le de base seau serait Eleventy, Hugo et Jekyll. Les trois autres sont basés sur un cadre frontal et sont livrés avec diverses quantités d'outillage. Gatsby et Next sont construits sur React, tandis que Nuxt est construit sur Vue.

Générateurs de base Générateurs avancés
Onze Gatsby
Hugo Suivant
Jekyll Nuxt

Mon hypothèse

Appliquons la méthode scientifique à cette approche car la science est amusante (et utile)!

Mon hypothèse est que si un SSG est avancé, il fonctionnera plus lentement qu'un SSG de base. Je pense que les résultats refléteront cela parce que les SSG avancés ont plus de frais généraux que les SSG de base. Ainsi, il est probable que nous allons voir les deux groupes de générateurs – de base et avancés – combinés ensemble, dans les résultats avec les générateurs de base se déplaçant beaucoup plus rapidement.

Permettez-moi de développer un peu cette hypothèse.

Linéaire (ish) et rapide

Hugo et Eleventy voleront avec des ensembles de données plus petits. Ce sont des processus (relativement) simples dans Go et Node.js, respectivement, et leur sortie de construction reflétera cela. Bien que les deux SSG ralentissent à mesure que le nombre de fichiers augmente, je m'attends à ce qu'ils restent en tête de la classe, bien qu'Eleventy soit peut-être un peu moins linéaire à l'échelle, simplement parce que Go a tendance à être plus performant que Node.

Lent, puis rapide, mais toujours lent

Les SSG avancés, ou liés au framework, commenceront et apparaître lent. Je soupçonne un test sur un seul fichier de contenir une différence significative – des millisecondes pour les tests de base, par rapport à plusieurs secondes pour Gatsby, Next et Nuxt.

Les SSG basés sur le framework sont chacun construits à l'aide de Webpack, ce qui entraîne une surcharge importante, quelle que soit la quantité de contenu qu'ils traitent. C'est le bagage auquel nous nous inscrivons en utilisant ces outils (nous en reparlerons plus tard).

Mais, à mesure que nous ajoutons des milliers de fichiers, je soupçonne que nous verrons l’écart entre les compartiments se resserrer, même si le groupe SSG avancé restera plus loin derrière de manière significative.

Dans le groupe SSG avancé, je m'attends à ce que Gatsby soit le plus rapide, uniquement parce qu'il n'a pas de composant côté serveur à s'inquiéter – mais ce n'est qu'un instinct. Next et Nuxt ont peut-être optimisé cela au point que, si nous n'utilisons pas cette fonctionnalité, cela n'affectera pas les temps de construction. Et je soupçonne que Nuxt battra Next, uniquement parce qu'il y a un peu moins de frais généraux avec Vue, par rapport à React.

Jekyll: l'enfant étrange

Ruby est tristement lent. Il est devenu plus performant avec le temps, mais je ne m'attends pas à ce qu'il évolue avec Node, et certainement pas avec Go. Et pourtant, en même temps, il n’a pas le bagage d’un cadre.

Au début, je pense que nous verrons Jekyll comme assez rapide, peut-être même impossible à distinguer d'Eleventy. Mais au fur et à mesure que nous arrivons aux milliers de fichiers, la performance en prendra un coup. Mon instinct est qu'il peut exister un moment où Jekyll deviendra le plus lent des six. Nous allons franchir la barre des 100 000 pour voir avec certitude.

Un graphique linéaire dessiné à la main montrant le temps de construction sur l'axe y et le nombre de fichiers sur le x-asix, où Next est une ligne verte, puis nuxt est une ligne jaune, gatsby est une ligne rose jekyll est une ligne bleue, onze est une ligne turquoise et hugo est une ligne orange. Toutes les lignes montrent que le temps de construction augmente à mesure que le nombre de fichiers augmente, là où jekyll a la pente la plus forte.

Les résultats sont là!

Le code qui alimente ces tests se trouve sur GitHub. Il existe également un site qui affiche les résultats relatifs.

Après de nombreuses itérations de construction d'une base sur laquelle ces tests pourraient être exécutés, je me suis retrouvé avec une série de 10 exécutions dans trois ensembles de données différents:

  • Base: Un seul fichier, pour comparer les temps de construction de base
  • Petits sites: De 1 à 1024 fichiers, en doublant à chaque fois (pour faciliter la détermination de la mise à l'échelle linéaire des SSG)
  • Grands sites: De 1 000 à 64 000 fichiers, doublez à chaque exécution. Je voulais à l'origine aller jusqu'à 128 000 fichiers, mais j'ai rencontré des goulots d'étranglement avec quelques-uns des frameworks. 64000 ont fini par suffire à donner une idée de la façon dont les joueurs évolueraient avec des sites encore plus grands.

Cliquez ou appuyez sur les images pour les agrandir.

Résumer les résultats

Quelques résultats m'ont surpris, d'autres étaient attendus. Voici les points de haut niveau:

  • Comme prévu, Hugo était le plus rapide, quelle que soit leur taille. Ce à quoi je ne m'attendais pas, c'est qu'il n'était même pas proche d'un autre générateur, même aux versions de base (ni linéaire, mais plus à ce sujet ci-dessous).
  • Les groupes de base et avancés de SSG sont assez évidents lorsque l'on regarde les résultats pour les petits sites. C'était attendu, mais c'était surprenant de voir Next est plus rapide que Jekyll avec 32 000 fichiers, et plus rapide que Eleventy et Jekyll avec 64 000 fichiers. Également surprenant, Jekyll a été plus rapide que Eleventy avec 64 000 fichiers.
  • Aucune des SSG ne se met à l'échelle de manière linéaire. Le suivant était le plus proche. Hugo a l’apparence d’être linéaire, mais uniquement parce qu’il est beaucoup plus rapide que les autres.
  • Je pensais que Gatsby était le plus rapide parmi les frameworks avancés et je soupçonnais que ce serait celui qui se rapprocherait des bases. Mais Gatsby s'est avéré être le plus lent, produisant la courbe la plus dramatique.
  • Bien que cela n'ait pas été spécifiquement mentionné dans l'hypothèse, l'échelle des différences était plus grande que ce que j'aurais imaginé. Dans un dossier, Hugo était environ 170 fois plus rapide que Gatsby. Mais avec 64 000 fichiers, c'était plus proche – environ 25 fois plus rapide. Cela signifie que, même si Hugo reste le plus rapide, il a en fait la forme de croissance exponentielle la plus spectaculaire du lot. C'est juste regards linéaire en raison de l'échelle du graphique.

Qu'est-ce que tout cela veut dire?

Lorsque j'ai partagé mes résultats avec les créateurs et les responsables de ces SSG, j'ai généralement reçu le même message. Paraphraser:

Les générateurs qui prennent plus de temps à construire le font parce qu'ils en font plus. Ils apportent plus à la table pour que les développeurs travaillent avec, tandis que les sites plus rapides (c'est-à-dire les outils «de base») concentrent leurs efforts en grande partie sur la conversion de modèles en fichiers HTML.

Je suis d'accord.

Résumer: La mise à l'échelle des sites Jamstack est difficile.

Les défis qui se présenteront à vous, développeur, lors de la mise à l'échelle d'un site varieront en fonction du site que vous essayez de créer. Ces données ne sont pas capturées ici car elles ne peuvent pas l'être – chaque projet est unique d'une certaine manière.

Ce qui revient vraiment à votre niveau de tolérance à l'attente en échange d'une expérience de développeur.

Par exemple, si vous allez créer un grand site riche en images avec Gatsby, vous allez le payer avec des temps de construction, mais vous disposez également d'un immense réseau de plugins et d'une base sur laquelle construire un site Web solide, organisé et basé sur des composants. Faites de même avec Jekyll, et il faudra beaucoup plus d’efforts pour rester organisé et efficace tout au long du processus, même si vos builds peuvent s’exécuter plus rapidement.

Au travail, je construis généralement des sites avec Gatsby (ou Next, selon le niveau d'interactivité dynamique requis). Nous avons travaillé avec le framework Gatsby pour créer un noyau sur lequel nous pouvons rapidement créer des sites Web hautement personnalisés et riches en images, avec une multitude de composants. Nos créations deviennent plus lentes à mesure que les sites évoluent, mais c'est à ce moment-là que nous faisons preuve de créativité en mettant en œuvre des micro-frontaux, en déchargeant le traitement d'image, en mettant en œuvre des aperçus de contenu, ainsi que de nombreuses autres optimisations.

D'un autre côté, j'ai tendance à préférer travailler avec Eleventy. C'est généralement moi qui écris du code et mes besoins sont beaucoup plus simples. (J'aime me considérer comme un bon client pour moi.) Je sens que j'ai plus de contrôle sur les fichiers de sortie, ce qui me permet d'obtenir plus facilement des performances côté client, et c'est important pour moi.

En fin de compte, ce n’est pas seulement sur ce qui est rapide ou lent. Il s'agit de ce qui fonctionne le mieux pour vous et du temps que vous êtes prêt à attendre.

Emballer

Ce n'est que le début! Le but de cet effort était de créer une base sur laquelle nous pouvons, ensemble, relatif temps de construction sur les générateurs de sites statiques populaires.

Quelles idées as-tu? Quels trous pouvez-vous percer dans le processus? Que pouvons-nous faire pour renforcer ces tests? Comment pouvons-nous les faire ressembler davantage à des scénarios du monde réel? Doit-on décharger le traitement sur une machine dédiée?

Telles sont les questions que j'aimerais que vous m'aidiez à répondre. Parlons-en.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *