Vergleich der Build-Zeiten von Static Site Generatoren

Es gibt so viele Static Site Generatoren (SSGs). Es ist überwältigend, sich zu entscheiden, wo man anfangen soll. Während eine Fülle von hilfreichen Artikeln helfen mag, die (beliebten) Optionen zu durchforsten, machen sie die Entscheidung nicht magisch einfach.

Ich habe mich auf eine Suche begeben, um diese Entscheidung zu erleichtern. Ein Kollege von mir hat ein Spickzettel zur Bewertung von Static Site Generatoren erstellt. Es bietet einen wirklich schönen Überblick über zahlreiche beliebte SSG-Optionen. Was fehlt, ist, wie sie sich in der Praxis verhalten.

Eine Funktion, die alle Static Site Generatoren gemeinsam haben, ist, dass sie Eingabedaten entgegennehmen, sie durch eine Templating-Engine laufen lassen und HTML-Dateien ausgeben. Diesen Prozess bezeichnen wir typischerweise als Den Build.

Es gibt zu viel Nuance, Kontext und Variabilität, um zu vergleichen, wie verschiedene SSGs während des Build-Prozesses funktionieren, um sie in einer Tabelle darzustellen – und damit beginnt unser Test, die Build-Zeiten gegen beliebte Static Site Generatoren zu benchmarken.

Dies dient nicht nur dazu, festzustellen, welcher SSG der schnellste ist. Hugo hat diesen Ruf bereits. Ich meine, sie sagen es auf ihrer Website – Das weltweit schnellste Framework zum Erstellen von Websites – also muss es wahr sein!

Dies ist ein detaillierter Vergleich der Build-Zeiten über mehrere beliebte SSGs hinweg und, was noch wichtiger ist, eine Analyse, warum diese Build-Zeiten so aussehen, wie sie aussehen. Blind den schnellsten zu wählen oder den langsamsten zu diskreditieren, wäre ein Fehler. Finden wir heraus, warum.

Die Tests

Der Testprozess ist darauf ausgelegt, einfach zu beginnen – mit nur wenigen beliebten SSGs und einem einfachen Datenformat. Eine Grundlage, auf der auf mehr SSGs und nuanciertere Daten erweitert werden kann. Für heute umfasst der Test sechs beliebte SSG-Optionen

• Eleventy
• Gatsby
• Hugo
• Jekyll
• Next
• Nuxt

Jeder Test verwendete den folgenden Ansatz und die folgenden Bedingungen

• Die Datenquelle für jeden Build sind Markdown-Dateien mit einem zufällig generierten Titel (als Frontmatter) und Textkörper (enthält drei Absätze Inhalt).
• Der Inhalt enthält keine Bilder.
• Tests werden seriell auf einer einzelnen Maschine ausgeführt, wodurch die tatsächlichen Werte weniger relevant sind als der relative Vergleich untereinander.
• Die Ausgabe ist reiner Text auf einer HTML-Seite, die mit dem Standard-Starter ausgeführt wird, wobei den jeweiligen Anleitungen zur Inbetriebnahme jedes SSG gefolgt wird.
• Jeder Test ist ein Kaltstart. Caches werden gelöscht und Markdown-Dateien für jeden Test neu generiert.

Diese Tests gelten als Benchmark-Tests. Sie verwenden einfache Markdown-Dateien und geben ungestyltes HTML in die erzeugte Ausgabe aus.

Mit anderen Worten, die Ausgabe ist technisch eine Website, die produziert werden könnte, obwohl es sich nicht wirklich um ein Szenario aus der Praxis handelt. Stattdessen bietet dies einen grundlegenden Vergleich zwischen diesen Frameworks. Die Entscheidungen, die Sie als Entwickler bei der Verwendung eines dieser Frameworks treffen, wirken sich auf die Build-Zeiten auf verschiedene Weise aus (normalerweise durch Verlangsamung).

Ein Beispiel dafür, wie dies nicht die Praxis widerspiegelt, ist, dass wir Kaltstarts testen. In der Praxis, wenn Sie 10.000 Markdown-Dateien als Datenquelle haben und Gatsby verwenden, werden Sie den Cache von Gatsby nutzen, was die Build-Zeiten erheblich reduziert (bis zur Hälfte).

Dasselbe gilt für inkrementelle Builds, die mit Warm- und Kaltstarts zusammenhängen, da sie nur die geänderte Datei erstellen. Wir testen den inkrementellen Ansatz derzeit nicht in diesen Tests.

Die beiden Stufen von Static Site Generatoren

Bevor wir das tun, betrachten wir zunächst, dass es wirklich zwei Stufen von Static Site Generatoren gibt. Nennen wir sie einfach und fortgeschritten.

• Einfache Generatoren (die nicht im Kern einfach sind) sind im Wesentlichen eine Befehlszeilenschnittstelle (CLI), die Daten aufnimmt und HTML ausgibt und oft zur Verarbeitung von Assets erweitert werden kann (was wir hier nicht tun).
• Fortgeschrittene Generatoren bieten zusätzlich zur Ausgabe einer statischen Website etwas, wie z.B. serverseitiges Rendering, serverlose Funktionen und Framework-Integration. Sie sind in der Regel von Anfang an dynamischer konfiguriert.

Ich habe absichtlich drei Generatoren jeder Art in diesem Test ausgewählt. In den einfachen Eimer fallen Eleventy, Hugo und Jekyll. Die anderen drei basieren auf einem Frontend-Framework und werden mit verschiedenen Werkzeugen geliefert. Gatsby und Next basieren auf React, während Nuxt auf Vue aufbaut.

Einfache Generatoren	Fortgeschrittene Generatoren
Eleventy	Gatsby
Hugo	Next
Jekyll	Nuxt

Meine Hypothese

Lassen Sie uns die wissenschaftliche Methode auf diesen Ansatz anwenden, denn Wissenschaft macht Spaß (und ist nützlich)!

Meine Hypothese ist, dass ein fortgeschrittener SSG langsamer sein wird als ein einfacher SSG. Ich glaube, die Ergebnisse werden dies widerspiegeln, da fortgeschrittene SSGs mehr Overhead haben als einfache SSGs. Daher werden wir wahrscheinlich sehen, dass beide Gruppen von Generatoren – einfach und fortgeschritten – in den Ergebnissen zusammengefasst sind, wobei die einfachen Generatoren deutlich schneller sind.

Lassen Sie mich diese Hypothese etwas erweitern.

Linear (ähnlich) und schnell

Hugo und Eleventy werden bei kleineren Datensätzen rasen. Sie sind (relativ) einfache Prozesse in Go und Node.js bzw. und ihr Build-Output wird dies widerspiegeln. Während beide SSGs bei wachsender Dateianzahl langsamer werden, erwarte ich, dass sie an der Spitze der Klasse bleiben, obwohl Eleventy bei Skalierung vielleicht etwas weniger linear ist, einfach weil Go tendenziell leistungsfähiger ist als Node.

Langsam, dann schnell, aber immer noch langsam

Die fortgeschrittenen oder framework-gebundenen SSGs werden anfangen und erscheinen langsam. Ich vermute, ein Test mit einer einzelnen Datei wird einen erheblichen Unterschied aufweisen – Millisekunden für die einfachen, verglichen mit mehreren Sekunden für Gatsby, Next und Nuxt.

Die Framework-basierten SSGs werden jeweils mit webpack erstellt, was einen erheblichen Overhead mit sich bringt, unabhängig von der Menge an verarbeitetem Inhalt. Das ist der Ballast, den wir beim Nutzen dieser Tools in Kauf nehmen (mehr dazu später).

Aber wenn wir Tausende von Dateien hinzufügen, vermute ich, dass die Lücke zwischen den Buckets kleiner wird, obwohl die Gruppe der fortgeschrittenen SSGs immer noch um einen erheblichen Betrag zurückbleibt.

In der fortgeschrittenen SSG-Gruppe erwarte ich, dass Gatsby der schnellste sein wird, nur weil es keine serverseitige Komponente hat, um die man sich Sorgen machen muss – aber das ist nur ein Bauchgefühl. Next und Nuxt haben dies möglicherweise bis zu einem Punkt optimiert, an dem es, wenn wir diese Funktion nicht nutzen, die Build-Zeiten nicht beeinträchtigt. Und ich vermute, Nuxt wird Next schlagen, nur weil Vue etwas weniger Overhead hat als React.

Jekyll: Das ungleiche Kind

Ruby ist berüchtigt langsam. Es ist im Laufe der Zeit leistungsfähiger geworden, aber ich erwarte nicht, dass es mit Node und schon gar nicht mit Go skaliert. Und doch hat es gleichzeitig nicht den Ballast eines Frameworks.

Zuerst denke ich, wir werden Jekyll als ziemlich flott erleben, vielleicht sogar nicht von Eleventy zu unterscheiden. Aber wenn wir zu Tausenden von Dateien kommen, wird die Leistung leiden. Mein Bauchgefühl ist, dass es einen Punkt geben könnte, an dem Jekyll zum langsamsten von allen sechs wird. Wir werden bis zur 100.000er Marke gehen, um das sicher zu wissen.

Die Ergebnisse sind da!

Der Code, der diese Tests antreibt, ist auf GitHub. Es gibt auch eine Seite, die die relativen Ergebnisse zeigt.

Nach vielen Iterationen beim Aufbau einer Grundlage, auf der diese Tests durchgeführt werden konnten, habe ich eine Reihe von 10 Läufen in drei verschiedenen Datensätzen erhalten

• Basis: Eine einzelne Datei, um die grundlegenden Build-Zeiten zu vergleichen
• Kleine Websites: Von 1 bis 1024 Dateien, jeweils verdoppelt, um die Skalierung zu messen (um festzustellen, ob die SSGs linear skalieren)
• Große Websites: Von 1.000 bis 64.000 Dateien, jeweils verdoppelt. Ursprünglich wollte ich bis zu 128.000 Dateien gehen, stieß aber bei einigen Frameworks auf Engpässe. 64.000 reichten aus, um eine Vorstellung davon zu geben, wie die Akteure mit noch größeren Websites skalieren würden.

Klicken oder tippen Sie auf die Bilder, um sie größer anzuzeigen.

Zusammenfassung der Ergebnisse

Einige Ergebnisse waren für mich überraschend, andere erwartet. Hier sind die wichtigsten Punkte:

• Wie erwartet, war Hugo der Schnellste, unabhängig von der Größe. Was ich nicht erwartet hatte, war, dass er selbst bei den grundlegenden Builds nicht annähernd an andere Generatoren herankam.
• Die Gruppen der einfachen und fortgeschrittenen SSGs sind bei den Ergebnissen für kleine Websites sehr deutlich. Das war erwartet, aber es war überraschend zu sehen, wie Next und Eleventy bei 64.000 Dateien knapp beieinander lagen. Überraschend ist auch, dass Jekyll bei jedem Durchlauf schneller als Eleventy war.
• Ich dachte, Gatsby wäre der schnellste unter den fortgeschrittenen Frameworks und vermutete, er würde den Basics näher kommen. Aber Gatsby war letztendlich der langsamste und zeigte die dramatischste Kurve.
• Obwohl es in der Hypothese nicht ausdrücklich erwähnt wurde, war die Größenordnung der Unterschiede größer als ich erwartet hätte. Bei einer Datei war Hugo etwa 250 Mal schneller als Gatsby. Aber bei 64.000 Dateien war es näher – etwa 40 Mal schneller. Das bedeutet, dass Hugo, obwohl er der (signifikant) schnellste bleibt, mit zunehmender Größe der Websites näher an den anderen Generatoren liegt.

Was bedeutet das alles?

Als ich meine Ergebnisse mit den Erstellern und Betreuern dieser SSGs teilte, erhielt ich im Allgemeinen die gleiche Botschaft. Um es zu paraphrasieren:

Die Generatoren, die länger zum Erstellen brauchen, tun dies, weil sie mehr leisten. Sie bieten Entwicklern mehr Möglichkeiten, während die schnelleren Websites (d.h. die „einfachen“ Tools) ihre Anstrengungen hauptsächlich auf die Konvertierung von Vorlagen in HTML-Dateien konzentrieren.

Ich stimme zu.

Zusammenfassend lässt sich sagen: Die Skalierung von Jamstack-Websites ist schwierig.

Die Herausforderungen, denen Sie als Entwickler bei der Skalierung einer Website gegenüberstehen, variieren je nach der zu erstellenden Website. Diese Daten werden hier nicht erfasst, da sie nicht erfasst werden können – jedes Projekt ist auf seine Weise einzigartig.

Worauf es wirklich ankommt, ist Ihr Toleranzniveau für Wartezeiten im Austausch für die Entwicklererfahrung.

Wenn Sie beispielsweise eine große, bildintensive Website mit Gatsby erstellen, zahlen Sie dafür mit Build-Zeiten, aber Sie erhalten auch ein immenses Plugin-Netzwerk und eine Grundlage für den Aufbau einer soliden, organisierten, komponentenbasierte Website. Machen Sie dasselbe mit Jekyll, und es wird viel mehr Aufwand erfordern, organisiert und effizient zu bleiben, obwohl Ihre Builds schneller ablaufen mögen.

Bei der Arbeit baue ich normalerweise Websites mit Gatsby (oder Next, je nach erforderlichem Grad der dynamischen Interaktivität). Wir haben mit dem Gatsby-Framework an einem Kern gearbeitet, auf dem wir schnell hochgradig angepasste, bildreiche Websites mit einer Fülle von Komponenten erstellen können. Unsere Builds werden mit zunehmender Skalierung der Websites langsamer, aber dann werden wir kreativ, indem wir Micro Frontends implementieren, die Bildverarbeitung auslagern, Inhaltsvorschau implementieren und viele andere Optimierungen vornehmen.

Nebenbei bevorzuge ich es, mit Eleventy zu arbeiten. Normalerweise schreibe ich Code und meine Bedürfnisse sind viel einfacher. (Ich betrachte mich gerne als guten Kunden für mich selbst.) Ich habe das Gefühl, mehr Kontrolle über die Ausgabedateien zu haben, was es mir erleichtert, 💯s bei der clientseitigen Leistung zu erzielen, und das ist mir wichtig.

Letztendlich geht es hier nicht nur darum, was schnell oder langsam ist. Es geht darum, was für Sie am besten funktioniert und wie lange Sie zu warten bereit sind.

Zusammenfassung

Dies ist nur der Anfang! Das Ziel dieser Bemühung war es, eine Grundlage zu schaffen, auf der wir gemeinsam relative Build-Zeiten über beliebte Static Site Generatoren hinweg benchmarken können.

Welche Ideen haben Sie? Welche Lücken können Sie im Prozess finden? Was können wir tun, um diese Tests zu verbessern? Wie können wir sie realitätsnäher gestalten? Sollen wir die Verarbeitung an eine dedizierte Maschine auslagern?

Das sind die Fragen, bei deren Beantwortung Sie mir gerne helfen würden. Lassen Sie uns darüber sprechen.