Die Texte in diesem Artikel wurden teilweise mit Hilfe künstlicher Intelligenz erarbeitet und von uns korrigiert und überarbeitet. Für die Generierung wurden folgende Dienste verwendet:
Content Management Systeme (CMS) und Frameworks (CMF) sind bei der Umsetzung von Webprojekten weit verbreitet und hoch angesehen. Sie dienen hauptsächlich der Vermittlung von Informationen und Medien.
Sie können selbst gehostete oder von Drittanbietern betriebene Anwendungen einsetzen, um generische Inhalte bereitzustellen. Es gibt grundsätzlich zwei bevorzugte Lösungen, um Inhalte aus einem CMS oder CMF im Web darzustellen:
Bekannte Strategien
Server Side Rendering (SSR)
Der traditionelle Ansatz sieht vor, dass ein CMS wie Wordpress oder CMF wie ProcessWire die Inhalte einer Seite verwaltet, ein Redaktionssystem bereitstellt und gegebenenfalls die Darstellung der Inhalte über Templates übernimmt.
Moderne Tech Stacks verwenden Full-Stack-Frameworks wie Next.js, die unter anderem das Templating übernehmen und Inhalte über eine Schnittstelle aus dem CMS beziehen, wie zum Beispiel Strapi.
Der Server ist für die Aufbereitung der Inhalte in Form einer Seite verantwortlich. Je nach gewähltem Ansatz stellt er auch das Redaktionssystem zur Verfügung.
Client Side Rendering (CSR)
Im Gegensatz zum traditionellen Ansatz wird beim Client Side Rendering der Browser der Nutzer:innen für die Aufbereitung der Inhalte verantwortlich. Die Inhalte werden dabei ausschließlich statisch oder über Schnittstellen vom CMS bezogen.
Static Site Generation (SSG)
Die Inhalte werden bei der Generierung der statischen Dateien aufbereitet. Dafür wird eine Schnittstelle benötigt, entweder vom Dateisystem oder von einem CMS.
In kleineren Projekten kann es sinnvoll sein, die Inhalte über das Dateisystem zu verwalten. Astro ist ein Tool, das diesen Ansatz nutzt, um Inhalte in Formaten wie Markdown zu verwalten und über Templates aufzubereiten. Markdown ist ein Format, das auch in einem Texteditor lesbar bleibt.
Für die Bereitstellung der Inhalte von Aggregata nutzen wir ebendiesen Anstatz.
Für größere Projekte empfiehlt es sich, CMS mit Schnittstellen zu nutzen. Dabei werden die Inhalte während der Generierung über die Schnittstelle bezogen und entsprechend aufbereitet.
Im Gegensatz zur client-seitigen und server-seitigen Darstellung hat die statische Seitengenerierung den Nachteil, dass die Inhalte erst bei der erneuten Generierung der statischen Seiten aktualisiert werden.
Limitierungen umgehen
Da statische Seiten nur die zum Zeitpunkt der Generierung verfügbaren Inhalte enthalten können, muss eine Lösung entwickelt werden, die eine erneute Generierung auslöst, wenn die Inhalte im CMS aktualisiert werden.
Webhooks sind eine Lösung für diese Limitierung. Sie ermöglichen es, Events von einer Plattform auf eine andere zu übertragen. Eine Veränderung der Inhalte im CMS kann so ein erneutes Deployment des Projekts beim Anbieter veranlassen.
Anwendungsfall mit Hypgraph und Cloudflare
In den nächsten Abschnitten werde ich ein Szenario vorstellen. Dieses illustriert den oben beschriebenen Ansatz mit den Anbietern Hypgraph als CMS und Cloudflare Pages für das Hosting.
Um einen Webhook als Deploy Hook anzulegen, navigieren wir zuerst zu den Einstellungen unseres Projekts auf Cloudflare Pages. Dort fügen wir unter dem Menüpunkt Builds & deployments einen Deploy Hook hinzu.
Wir geben lediglich einen Namen für den Deploy Hook an und wählen den Branch unseres Projekts aus, der für das Deployment aus einem SCM wie GitHub verwendet werden soll.
Anschließend stellt Cloudflare eine URL bereit, um das Deployment auszulösen. Diese URL kann nun in Hygraph übertragen werden.
Wir navigieren in der Hygraph-Oberfläche zum Menüpunkt Webhooks und erstellen einen neuen Webhook. Dieser greift auf die URL des Deploy Hooks von Cloudflare Pages zurück. Falls erforderlich, können auch verschiedene Auslöser aus dem CMS konfiguriert werden.
Wenn die Nutzung von Hygraph auf veröffentlichte Inhalte beschränkt ist, sollte die Option Stage auf Published gesetzt werden. Dadurch werden Anpassungen an unveröffentlichten Entwürfen vermieden, die weitere Deployments auslösen könnten.
Nach erfolgreicher Konfiguration des Webhooks in Hygraph wird der Seite ein neuer Eintrag hinzugefügt. Dieser enthält die entsprechende URL des Deploy Hooks und den Status Active.
Wenn wir Änderungen an den veröffentlichten Inhalten vornehmen, überträgt Hypgraph diese Informationen an Cloudflare Pages. Dadurch wird das Projekt erneut bereitgestellt, um sicherzustellen, dass die Inhalte der Website mit denen des CMS übereinstimmen.
Vor- & Nachteil dieses Anwendungsfalls
In diesem Anwendungsfall ist die Performance der Website vorteilhaft. Sie wird mit statischem HTML ausgeliefert und verzichtet auf serverseitige Vorverarbeitung. Dadurch kann die Antwortzeit einer einzelnen Seite drastisch reduziert werden.
Allerdings kann eine hohe Anzahl von inhaltlichen Änderungen dazu führen, dass diese erst mit Verzögerung auf der Website sichtbar werden. Deployments können gruppiert werden, um die Anzahl der erforderlichen Deployments zu reduzieren.
Je nach Anbieter und gewähltem Plan können Einschränkungen auftreten. Zum Beispiel sind bei Vercel die Deployments im Hobby Plan auf 100 und im Pro Plan auf 600 pro Tag begrenzt.
Grundsätzlich empfiehlt sich dieser Anwendungsfall für Seiten mit geringer Frequenz an inhaltlichen Änderungen, die nicht zwingend vollständig auf Echtzeitdaten für ihre Inhalte angewiesen sind.
Beispiele für diesen Anwendungsfall sind persönliche Websites wie Blogs und Portfolios sowie kleinere Informations- und Unternehmenswebsites.
So können wir Webseiten mit dynamischen Inhalten at the speed of static ausliefern, ohne auf die modernen Funktionen eines Redaktionssystems zu verzichten.
TL;DR
Mit der statischen Seitengenerierung kannst du Websites mit optimaler Performance ausspielen. Kombiniere dies mit Webhooks und automatisierten Deployments, um dynamische Inhalte at the speed of static auszuspielen.