Ich habe mich entschlossen, denen zu helfen, die mit der Wahl von SSG beschäftigt sind. Ein Kollege von mir hat eine Liste mit Fragen zusammengestellt , die Ihnen bei der Suche nach einem statischen Site-Generator helfen sollen. Dieser Liste ist eine Zusammenfassung der gängigen SSGs beigefügt. Es fehlt nur eine Einschätzung der Leistung verschiedener SSGs in Aktion.
Allen SSGs ist gemeinsam, wie sie funktionieren. Sie akzeptieren nämlich einige Daten als Eingabe und leiten diese Daten durch die Template-Engine. Die Ausgabe sind HTML-Dateien. Dieser Prozess wird allgemein als Erstellen des Projekts bezeichnet.
Um vergleichbare Leistungsdaten für verschiedene SSGs zu erhalten, müssen viele Nuancen berücksichtigt werden. Es ist notwendig, auf die Merkmale der Projekte zu achten, auf die Faktoren, die die Montage verlangsamen oder beschleunigen. Hier beginnt unsere Untersuchung der Leistung beliebter SSGs.
Unser Ziel ist es jedoch nicht nur, die schnellste SSG zu finden. Der Ruf, "der Schnellste" zu sein, hat Hugo bereits erfasst . Ich meine, auf der Website des Projekts heißt es, dass Hugo das weltweit schnellste Framework für die Erstellung von Websites ist. Und das heißt - so wie es ist.
Dieser Artikel vergleicht die Leistung beliebter SSGs. Wir sprechen nämlich über die Bauzeit von Projekten. Das Wichtigste dabei ist jedoch eine gründliche Analyse, warum bestimmte Instrumente bestimmte Ergebnisse zeigen. Es wird ein Fehler sein, unabhängig von irgendetwas außer dem Zeitpunkt der Projektzusammenstellung, die "schnellste SSG" zu wählen oder die "langsamste" sofort aufzugeben. Sprechen wir darüber, warum das so ist.
Tests
Der SSG-Testprozess soll zunächst einige beliebte Projekte untersuchen und die Verarbeitung einfacher Datenformate untersuchen. Auf dieser Grundlage können Sie eine Studie mit statischeren Site-Generatoren erstellen und diese Studie um komplexere Datenformate erweitern. Die Studie umfasst jetzt sechs beliebte SSGs:
Bei der Untersuchung jedes einzelnen von ihnen werden der folgende Ansatz und die folgenden Bedingungen angewendet:
- Die Datenquelle für jeden Test (Projekterstellungsprozess) sind Markdown-Dateien, die einen zufällig generierten Header (was als "vordere Angelegenheit" bezeichnet wird) und den Dokumententext (drei Textabschnitte) enthalten.
- Die Dokumente enthalten keine Bilder.
- Die Tests werden mehrmals auf demselben Computer ausgeführt. Dies macht die aus dem Test erhaltenen spezifischen Werte weniger wichtig als den Vergleich der relativen Ergebnisse.
- Die Ausgabe wird im Klartext auf einer HTML-Seite dargestellt. Die Datenverarbeitung erfolgt mit Standardeinstellungen, die in den Kurzanleitungen für jede der untersuchten SSGs beschrieben sind.
- « ». Markdown-.
Diese Tests gelten als Leistungstests (Benchmarks). Sie verwenden einfache Markdown-Dateien, was zu nicht formatiertem HTML-Code führt.
Mit anderen Worten, die Ausgabe ist aus technischer Sicht eine Website, die in der Produktion bereitgestellt werden könnte. Dies ist jedoch keine Implementierung eines echten SSG-Szenarios. Anstatt zu versuchen, eine reale Situation zu reproduzieren, möchten wir eine Grundlage für den Vergleich der untersuchten Frameworks erhalten. Wenn Sie die oben genannten Tools zum Erstellen realer Websites verwenden, arbeitet SSG mit komplexeren Daten und mit unterschiedlichen Einstellungen, was sich auf die Erstellungszeit von Projekten auswirkt (dies verlangsamt normalerweise die Erstellung).
Einer der Unterschiede zwischen unseren Test- und realen SSG-Anwendungsfällen ist beispielsweise die Tatsache, dass wir Cold-Build-Prozesse untersuchen. In Wirklichkeit sieht es etwas anders aus. Wenn ein Projekt beispielsweise 10.000 Markdown-Dateien enthält, die die Datenquelle für SSG sind, und wenn Gatsby zum Erstellen des Projekts verwendet wird, wird der Gatsby-Cache verwendet. Und dies reduziert die Montagezeit erheblich (um fast die Hälfte).
Gleiches gilt für inkrementelle Builds. Dies hat mit dem Vergleich von Hot- und Cold-Builds in dem Sinne zu tun, dass nur geänderte Dateien verarbeitet werden, wenn ein inkrementeller Build ausgeführt wird. In diesen Tests werden keine inkrementellen Builds untersucht. In Zukunft ist es durchaus möglich, dass diese Studie in diese Richtung erweitert wird.
SSG auf verschiedenen Ebenen
Bevor wir beginnen, schauen wir uns die Tatsache an, dass es tatsächlich zwei Varianten von SSG gibt, zwei Ebenen von statischen Site-Generatoren. Nennen wir sie "Basic" und "Advanced".
- Grundlegende Generatoren (obwohl sie nicht so einfach sind) sind in der Tat Befehlszeilentools (Command-Line Interface, CLI), die Daten akzeptieren und HTML ausgeben. Oft eignen sich ihre Fähigkeiten zur Erweiterung in Richtung der Verarbeitung zusätzlicher Ressourcen (wir tun dies hier nicht).
- Erweiterte Generatoren bieten neben der Erstellung statischer Sites einige zusätzliche Funktionen. Dies sind beispielsweise serverseitiges Rendern von Seiten, Funktionen ohne Server und die Integration in verschiedene Webframeworks. Sie werden normalerweise unmittelbar nach der Installation so konfiguriert, dass der Benutzer dynamischere Funktionen als die Basisgeneratoren erhält.
Für diesen Test habe ich speziell drei Generatoren für jedes Level ausgewählt. Die grundlegenden sind Eleventy, Hugo und Jekyll. Die anderen drei Generatoren basieren auf Frontend-Frameworks. Diese SSGs enthalten verschiedene zusätzliche Tools. Gatsby und Next basieren auf React, während Nuxt auf Vue basiert.
| Grundgeneratoren | Erweiterte Generatoren |
| Elf | Gatsby |
| Hugo | Nächster |
| Jekyll | Nuxt |
Hypothesen und Annahmen
Ich schlage vor, die wissenschaftliche Methode in unserer Forschung anzuwenden . Die Wissenschaft ist sehr aufregend (und kann von großem Nutzen sein).
Meine Hypothese ist, dass SSG, wenn es weiterentwickelt wird, langsamer läuft als Basisgeneratoren. Ich bin sicher, dass sich dies in den Ergebnissen der Studie widerspiegeln wird, da mehr Mechanismen an der Arbeit fortgeschrittener SSGs beteiligt sind als an der Arbeit grundlegender. Infolgedessen ist es sehr wahrscheinlich, dass Basis- und fortgeschrittene Generatoren auf der Grundlage der Forschung klar in zwei Gruppen unterteilt werden können. Gleichzeitig arbeiten Basisgeneratoren schneller als fortgeschrittene.
▍Basic SSG: Hohe Geschwindigkeit und lineare Abhängigkeit der Erstellungsgeschwindigkeit von der Anzahl der Dateien
Hugo und Eleventy werden kleine Datensätze sehr schnell verarbeiten. Dies sind (relativ) einfache Prozesse, die von Go bzw. Node.js erstellt wurden. Ihre Testergebnisse sollten dies widerspiegeln. Obwohl diese beiden SSGs mit zunehmender Anzahl von Dateien langsamer werden, erwarte ich, dass sie weiterhin führend sind. Gleichzeitig ist es möglich, dass Eleventy mit zunehmender Last die Dynamik der Änderung der Montagezeit demonstriert, die stärker von linear abweicht als Hugo. Dies könnte eine einfache Folge der Tatsache sein, dass die Leistung von Go im Allgemeinen besser ist als die von Node.js.
▍Erweiterte SSG: Langsamer Build-Start und anschließende Geschwindigkeitssteigerung, aber nicht zu schwerwiegend
Fortgeschrittene SSGs oder solche, die an ein Webframework gebunden sind, werden langsam gestartet, was sich bemerkbar macht. Ich vermute, dass in einem einzelnen Dateitest der Unterschied zwischen grundlegenden und erweiterten Frameworks erheblich sein wird. Für einfache werden es einige Millisekunden sein, und für fortgeschrittene werden es für Gatsby, Next und Nuxt Sekunden sein.
SSGs, die auf Webframeworks basieren, verwenden Webpack, wodurch das System während der Ausführung zusätzlich belastet wird. Gleichzeitig hängt diese zusätzliche Belastung nicht von der Menge der verarbeiteten Daten ab. Aber wir selbst stimmen dem zu, indem wir fortgeschrittenere Tools verwenden (wir werden weiter unten mehr darüber sprechen).
Und wenn es um die Verarbeitung von Tausenden von Dateien geht, vermute ich, dass sich die Lücke zwischen den Gruppen der Basisgeneratoren und der erweiterten Generatorengruppen verringern wird. Gleichzeitig werden fortgeschrittene SSGs jedoch immer noch ernsthaft hinter den grundlegenden zurückbleiben.
Wenn wir über eine Gruppe fortschrittlicher Generatoren sprechen, erwarte ich, dass der schnellste von ihnen Gatsby ist. Ich denke nur, weil es keine serverseitige Rendering-Komponente gibt, die die Dinge verlangsamen kann. Dies ist jedoch nur ein Spiegelbild meiner inneren Gefühle. Möglicherweise wird das Rendern von Servern in Next und Nuxt so optimiert, dass es die Erstellungszeit von Projekten in keiner Weise beeinflusst, wenn es nicht verwendet wird. Ich vermute, Nuxt wird schneller als Next sein. Ich gehe davon aus, dass Vue "leichter" als React ist.
▍Jekyll ist ein ungewöhnlicher Vertreter der grundlegenden SSG
Die Ruby-Plattform ist bekannt für ihre schlechte Leistung. Es wird mit der Zeit optimiert, es wird schneller, aber ich erwarte nicht, dass es so schnell ist wie Node.js, geschweige denn Go. Gleichzeitig trägt Jekyll jedoch nicht die zusätzliche Belastung, die mit einem Webframework verbunden ist.
Ich denke, dass Jekyll zu Beginn des Tests bei der Verarbeitung einer kleinen Anzahl von Dateien eine hohe Geschwindigkeit zeigt. Möglicherweise so groß wie Elfzig. Wenn wir jedoch die Verarbeitung von Tausenden von Dateien untersuchen, wird die Leistung beeinträchtigt. Es scheint mir, dass es andere Gründe gibt, warum Jekyll die langsamste der sechs untersuchten SSGs ist. Um dies zu testen, untersuchen wir die Leistung unserer Generatoren an Dateigruppen unterschiedlicher Größe - bis zu 100.000.
Unten ist eine Grafik, die meine Annahmen zeigt.
Annahmen bezüglich der Abhängigkeit der Arbeitsgeschwindigkeit verschiedener SSGs
Die Y-Achse repräsentiert die Erstellungszeit von Projekten, die X-Achse repräsentiert die Anzahl der Dateien. Weiter ist in grün, Nuxt in gelb, Gatsby in pink, Jekyll in blau, Eleventy in türkis, Hugo in orange dargestellt. Alle Zeilen spiegeln die Zunahme der Projekterstellungszeit wider, wenn die Anzahl der Dateien zunimmt. Gleichzeitig hat die Jekyll entsprechende Linie den größten Neigungswinkel.
Ergebnisse
Hier ist der Code, der die Ergebnisse erzeugt, die ich jetzt diskutieren werde. Ich habe auch eine Seite erstellt, die die relativen Testergebnisse zusammenstellt.
Nach vielen Versuchen, Bedingungen für das Ausführen von Tests zu finden, entschied ich mich für 10 Durchläufe jedes Tests mit drei verschiedenen Datensätzen.
- Basisdatensatz (Basis). Dies ist eine Datei. Durch die Verarbeitung können Sie die Zeit abschätzen, die SSG benötigt, um sich auf die Arbeit vorzubereiten. Dies ist die Zeit, die SSG für den Start benötigt. Es kann als einfach bezeichnet werden, unabhängig von der Anzahl der verarbeiteten Dateien.
- Eine Reihe von "kleinen Websites" (Small Sites). Es wird die Zusammenstellung von Dateigruppen von 1 bis 1024 untersucht. Jeder neue Testdurchlauf wird mit einer doppelten Anzahl von Dateien durchgeführt (um leichter herauszufinden, ob die Verarbeitungszeit von Dateien linear mit dem Wachstum ihrer Anzahl wächst).
- Eine Reihe von "großen Sites" (Large Sites). Hier ändert sich die Anzahl der Dateien von 1000 auf 64000 und verdoppelt sich mit jedem neuen Testlauf. Anfangs wollte ich auf 128000 Dateien zugreifen, stieß aber in einigen Frameworks auf Engpässe. Als Ergebnis stellte sich heraus, dass 64.000 Dateien ausreichen, um herauszufinden, wie sich die untersuchten SSGs bei der Verarbeitung umfangreicher Websites verhalten.
Hier sind die Ergebnisse, die ich erhalten habe.
Basisdatensatz
Datensatz für kleine Websites
Datensatz für große Websites
Zusammenfassung der Ergebnisse
Einige der Ergebnisse überraschten mich, andere erwiesen sich als genau so, wie ich es erwartet hatte. Hier einige allgemeine Ergebnisse:
- Wie erwartet war Hugo die schnellste SSG. Es funktioniert hervorragend bei Dateigruppen aller Größen. Ich hatte jedoch nicht erwartet, dass sich andere Generatoren zumindest im Basisdatensatz dem nähern würden (ich hatte nicht erwartet, dass es lineares Verhalten zeigt, aber mehr dazu weiter unten).
- Beide SSGs, Basic und Advanced, unterscheiden sich in den Diagrammen, die die Verarbeitung von Dateien aus dem Satz "Kleine Sites" zeigen. Dies war zu erwarten. Es war jedoch unerwartet, dass Next bei 32000 Dateien schneller als Jekyll ist und bei 64000 Dateien sowohl Jekyll als auch Eleventy umgeht. Überraschenderweise ist Jekyll 64.000 Dateien schneller als Eleventy.
- SSG . Next, , , . Hugo , — - .
- , Gatsby , , . , .
- , , , . , , Hugo 170 , Gatsby. 64000 Hugo 25 . , Hugo, SSG, . , - .
Was bedeutet das alles?
Als ich meine Erkenntnisse mit den Machern dieser SSGs und mit denen, die sie unterstützen, teilte, erhielt ich von ihnen, ohne auf Details einzugehen, dieselben Nachrichten. Wenn diese Nachrichten auf eine Art "durchschnittliche" Nachricht reduziert werden, erhalten Sie Folgendes:
Generatoren, die mehr Zeit mit dem Erstellen eines Projekts verbringen, arbeiten auf diese Weise, weil sie mehr Probleme lösen müssen. Sie bieten Entwicklern mehr Optionen, während sich die schnelleren Tools (dh "Basic") hauptsächlich mit der Konvertierung von Vorlagen in HTML-Dateien befassen.
Ich stimme dem zu.
Wenn man alles auf den Punkt bringt, stellt sich heraus, dass das Skalieren von Jamstack-Sites sehr schwierig ist.
Die Schwierigkeiten, mit denen ein Entwickler konfrontiert ist, dessen Projekt wächst und sich entwickelt, hängen von den Merkmalen jedes einzelnen Projekts ab. Es gibt keine Daten, die dies unterstützen. Ja, sie können nicht hier sein, da jedes Projekt auf die eine oder andere Weise einzigartig ist.
Aber alles hängt von den persönlichen Vorlieben des Entwicklers ab, von diesem Kompromiss zwischen dem Zeitpunkt der Erstellung der Website und der Bequemlichkeit der Arbeit mit SSG, zu der er bereit ist.
Wenn Sie beispielsweise eine große Site voller Bilder erstellen und Gatsby verwenden möchten, müssen Sie darauf vorbereitet sein, dass die Erstellung dieser Site lange dauern wird. Im Gegenzug erhalten Sie ein riesiges Ökosystem an Plugins und eine Grundlage für den Aufbau einer robusten, gut organisierten, komponentenbasierten Website. Wenn Sie Jekyll im selben Projekt verwenden, müssen Sie viel mehr Anstrengungen unternehmen, um das Projekt in einem gut organisierten Zustand zu halten und die Effektivität der Arbeit am Projekt sicherzustellen. Und die Montage vor Ort wird schneller sein.
Bei der Arbeit baue ich normalerweise Websites mit Gatsby(oder mit Next, abhängig von der erforderlichen dynamischen Interaktivität des Projekts). Wir haben mit Gatsby zusammengearbeitet, um ein Framework zu erstellen, mit dem schnell hochgradig anpassbare Websites mit vielen Bildern erstellt werden können, die auf einer Vielzahl von Komponenten basieren. Mit zunehmender Größe dieser Websites dauerte es immer länger, sie zu erstellen, und wir wurden kreativ. Es geht um die Implementierung von Mikrofront-Enden , die Bildverarbeitung außerhalb des Haupt-Build-Systems, die Inhaltsvorschau und viele andere Optimierungen.
In eigenen ProjektenNormalerweise benutze ich Eleventy. Normalerweise schreibe nur ich den Code solcher Projekte, meine Bedürfnisse sind eher bescheiden (ich sehe mich als meinen eigenen guten Kunden). Ich habe eine bessere Kontrolle über die Build-Ergebnisse, wodurch ich eine hohe clientseitige Produktivität erzielen kann. Und das ist mir wichtig.
Folglich ist die Wahl von SSG nicht nur eine Wahl zwischen "schnell" und "langsam". Es ist die Auswahl des Tools, das für ein bestimmtes Projekt am besten geeignet ist und dessen Arbeitsergebnisse die Zeit rechtfertigen, die für das Warten auf diese Ergebnisse vergeht.
Ergebnis
In der Tat ist das, was ich gesagt habe, nur der Anfang. Das Ziel meiner Arbeit ist es, eine Basis zu schaffen, auf der wir alle die relativen Bauzeiten von Projekten messen können, die von der beliebten SSG erstellt wurden.
Haben Sie Inkonsistenzen in meinem vorgeschlagenen Testprozess für statische Site-Generatoren festgestellt? Wie kann das Testverfahren verbessert werden? Wie können Versuche der Realität näher gebracht werden? Muss ich die Bildverarbeitung auf einen separaten Computer übertragen? Ich lade alle, die sich für SSG interessieren, ein, sich mir anzuschließen und mir zu helfen, Antworten auf diese und viele andere Fragen zu finden.
Welche statischen Site-Generatoren verwenden Sie?
