Comparaison des temps de construction du générateur de sites statiques

Le choix d'un générateur de sites statique (SSG) peut être intimidant, étant donné le nombre d'options. Alors que de nombreux articles comparent les choix populaires, une décision vraiment éclairée nécessite de comprendre les performances du monde réel. Cette étude de référence analyse les temps de construction à travers six SSG populaires pour révéler non seulement les différences de vitesse, mais aussi les raisons sous-jacentes de ces différences. Il ne s'agit pas simplement de trouver le plus rapide; Il s'agit de comprendre les compromis.

Chaque SSG partage un processus de base: prendre des données d'entrée, appliquer un moteur de modèles et générer du HTML. Ce processus de "build" est au centre de notre comparaison.

Ce n'est pas seulement une course de vitesse (bien que le titre autoproclamé d'Hugo de l'investigation de "World's Fast le plus rapide"!). L'objectif est une plongée plus profonde dans les variations de temps de construction et leurs causes. Rejeter les artistes lents ou favoriser aveuglément les champions de la vitesse serait une simplification excessive.

Les tests de référence

Nos tests initiaux ont utilisé une approche simplifiée: six SSG populaires et un format de données simple. Cela fournit une référence pour une expansion future à plus de SSG et de structures de données complexes. Les participants:

• Evercenty
• Gatsby
• Hugo
• Jekyll
• Suivant
• Nuxt

Méthodologie de test:

• Données: les fichiers de marque avec des titres générés au hasard (Frontmatter) et des corps à trois paragraphes. Aucune image n'a été incluse.
• Environnement: les tests ont été effectués séquentiellement sur une seule machine; Les comparaisons relatives sont plus significatives que les valeurs absolues.
• Sortie: Texte brut HTML, en utilisant la configuration de démarrage par défaut de chaque SSG.
• Type de construction: "Cold Runs", avec des caches effacées et des fichiers de démarque régénérés pour chaque test.

Ce sont des tests de référence utilisant la marque de base et la sortie HTML non style. Bien que techniquement déployables, ils ne représentent pas complètement les scénarios du monde réel. Cela fournit une comparaison fondamentale. Les temps de construction du monde réel varieront en fonction des choix des développeurs et de la complexité du projet (augmentant généralement le temps de construction). Par exemple, les «constructions à froid» diffèrent considérablement des scénarios du monde réel où la mise en cache (en particulier dans Gatsby) réduit considérablement les temps de construction, souvent de moitié ou plus. Les versions incrémentielles, se concentrant uniquement sur les fichiers modifiés, ne sont pas non plus incluses dans cette phase initiale.

Deux niveaux de SSG

Nous avons classé les générateurs en deux niveaux:

• Basique: Essentiellement des interfaces de ligne de commande (CLI) Traitement des données et sortie HTML. Les extensions de traitement des actifs sont possibles mais pas testées ici. (Eleventy, Hugo, Jekyll)
• Advanced: offrez des fonctionnalités supplémentaires au-delà de la génération de sites statiques, telles que le rendu côté serveur, les fonctions sans serveur et l'intégration de Framework. Plus dynamique prêt à l'emploi. (Gatsby, Next, Nuxt)

Trois SSG de chaque niveau ont été inclus.

Hypothèse

Notre hypothèse: les SSG avancés seront plus lents que les SSG de base en raison de l'augmentation des frais généraux.

Nous avons prévu:

• Linéaire (ish) et rapide: Hugo et Eleventy, tirant sur le go et Node.js respectivement, devraient présenter une vitesse élevée, en particulier avec des ensembles de données plus petits. La mise à l'échelle devrait les ralentir, mais ils devraient rester les plus performants.

• Lent, puis rapide (ER), mais toujours lent: SSGS basés sur le framework (Gatsby, Next, Nuxt) à l'aide de WebPack, apparaîtrait initialement lent en raison de la surcharge. Cependant, avec des ensembles de données plus importants, nous nous attendions à ce que l'écart étroite, bien qu'ils resteraient derrière les SSG de base. Gatsby devrait être le plus rapide parmi le groupe avancé en raison de son manque de composants côté serveur. Nuxt devait surpasser ensuite en raison de la surcharge potentiellement inférieure de Vue.js par rapport à React.

• Jekyll: The Wildcard: La performance de Ruby est un facteur. Tout en manquant de frais généraux de cadre, sa vitesse était incertaine, en particulier à grande échelle.

Résultats

Le code de test et les résultats sont disponibles sur GitHub [lien vers GitHub Repo]. Dix courses ont été effectuées sur trois ensembles de données:

• Base: fichier unique
• Petits sites: 1 à 1024 fichiers, doubler à chaque fois.
• Grands sites: 1000 à 64 000 fichiers, doubler à chaque fois. (128 000 ont été initialement planifiés mais ont frappé des goulots d'étranglement avec certains cadres.)

[Inclure des graphiques / graphiques ici]

Résumé des résultats

• Hugo's Dominance: Comme prévu, Hugo a été le plus rapide dans tous les ensembles de données, surpassant considérablement les autres, même dans les versions de base.

• Performances à plusieurs niveaux: La différence de performance entre les SSG de base et avancée était claire dans les petits tests de site. Étonnamment, Suivant et Eleventy ont montré des performances comparables à 64 000 fichiers. Jekyll a constamment surclassé Eleventy.

• La lenteur inattendue de Gatsby: Gatsby, contrairement à notre hypothèse, a été la plus lente, présentant la courbe de performance la plus dramatique.

• Échelle des différences: l'ampleur des différences de performance était supérieure à celle prévue. Hugo était environ 250 fois plus rapide que Gatsby dans un seul fichier et 40 fois plus rapide dans 64 000 fichiers. Alors que Hugo est resté considérablement plus rapide, l'écart s'est rétréci avec l'augmentation de la taille du site.

Interprétation

Les commentaires des mainteneurs SSG ont indiqué que les temps de construction plus lents reflètent souvent une fonctionnalité accrue et une expérience des développeurs. Les outils de base hiérarchisent la génération HTML, tandis que les outils avancés fournissent plus de fonctionnalités.

Takeaway clé: La mise à l'échelle des sites Jamstack présente des défis uniques. Le SSG optimal dépend des besoins spécifiques de votre projet et de votre tolérance au temps de construction par rapport à l'expérience du développeur. Les grands sites lourds de l'image utilisant GATSBY peuvent avoir des constructions plus lentes, mais offrent un support de plugin étendu et un environnement de développement structuré. Jekyll pourrait offrir des constructions plus rapides mais nécessite plus d'organisation manuelle.

Personnellement, Gatsby (ou Next) est préféré pour les grands projets clients en raison de ses fonctionnalités robustes et de son écosystème de plugin, bien que les stratégies d'optimisation soient cruciales à grande échelle. Eleventy est favorisé pour des projets personnels plus petits où le contrôle et les performances à grains fins sont prioritaires.

En fin de compte, le choix n'est pas uniquement une question de vitesse, mais le meilleur ajustement pour votre projet et votre flux de travail.

Étapes suivantes

Ce n'est que le début. Les améliorations futures incluent des scénarios plus réalistes, des ensembles de données plus importants, des machines de test dédiées et plus d'inclusion SSG. La collaboration est encouragée à affiner la méthodologie de test et à étendre la portée de la référence.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!