Die eigene Webseite selbst in die Hand nehmen

Welcher Entwickler kennt es nicht – eigentlich möchte man nur eine einfache Webseite erstellen und steht plötzlich vor einer schier unendlichen Auswahl an Technologien, Anbietern und Lösungen. Und egal, für welche davon man sich entscheidet, kommen früher oder später erste Zweifel, ob nicht vielleicht die andere Lösung doch besser geeignet gewesen wäre

Das Problem mit der Technologie

WordPress ist bei der Erstellung einer Webseite zunächst immer eine naheliegende Wahl. Mit dem richtigen Template und ein paar Stunden Konfigurationsarbeit ist die erste Version der eigenen Seite schnell erstellt. Doch nachdem wir unsere Anforderungen diskutiert hatten, sahen wir bei WordPress Herausforderungen, die sich nur schwierig lösen lassen würden.

Zum einen sind WordPress-Webseiten ohne aufwändige Konfiguration selten besonders schnell. Geschwindigkeit ist jedoch heutzutage eine zentrale Anforderung an eine Webseite. Bereits eine Ladezeit von 4 Sekunden kann dafür sorgen, dass bis zu 25% aller Besucher das Laden der Webseite abbrechen. Gerade auf mobilen Geräten mit (leider) häufig langsameren Verbindungen muss die Seite deshalb klein und schnell sein.

Zum anderen stellen sich auch Herausforderungen wie das ständige Aktualisieren der verwendeten Software, häufigen Sicherheitsproblemen in verwendeten Plug-Ins oder die Vermischung von Code und Inhalt einer Seite. Aus diesen Gründen kam WordPress für uns nicht in Frage.

Eine statische Seite, komplett manuell mit HTML, CSS und JavaScript und ohne Framework gebaut, war jedoch auch keine praktikable Lösung. Zu groß sind die Herausforderungen, die mit der Erstellung einer schnellen und auf alle möglichen Endgeräte angepassten Seite kommen. Des Weiteren wäre es zu aufwendig Änderungen einzupflegen.

Da wir bisher gute Erfahrungen damit gemacht hatten, einigten wir uns nach einiger Diskussion darauf, React als grundlegendes Framework zu verwenden. Da Client-seitiges Rendering allerdings häufig zum Flaschenhals wird, insbesondere auf langsameren und mobilen Geräten, suchten wir nach einer Lösung, wie wir Server-Side-Rendering (SSR) anbieten könnten.

Nach etwas Recherche stießen wir auf Next.js, ein React-Framework, welches eine einfache Erstellung einer Seite erlaubt, die anschließend serverseitig gerendert und als fertiges HTML ausgeliefert wird. Der erste Entwurf unserer neuen Seite war schnell erstellt, doch vollständig zufrieden waren wir mit dem Technologie-Stack noch nicht.

Das Problem mit dem Markup

Es war von Anfang an klar, dass wir keine dynamische Seite erstellen wollten. Dennoch benötigten wir eine ganze Reihe einzelner Seiten, die zwar alle relativ ähnlich aufgebaut waren, allerdings eigene Inhalte besaßen. Das Kopieren des Markups mag zwar eine Möglichkeit sein, allerdings bereut man eine solche Entscheidung normalerweise spätestens bei der ersten größeren Änderung des Designs. Auch ein Blog sollte Teil der Seite sein, ohne dass wir für jeden Eintrag eine neue Seite erstellen wollten.

Wie konnten wir also unsere Inhalte vom Design bzw. vom Markup der eigentlichen Seiten trennen? Nach einiger Recherche stießen wir auf Gatsby, ein Open-Source-Framework, welches ebenfalls auf React basiert.

Bei Gatsby werden die Seiten zunächst im normalen React-Stil erstellt. Beim Build wird daraus dann eine statische HTML-Seite generiert, welche erst zur Laufzeit die benötigten Daten über GraphQL abfragt. Auf diese Weise ist kein clientseitiges Rendering mehr notwendig, und die Inhalte der Seite können separat vom eigentlichen Markup gehalten werden. Sie werden beispielsweise im Markdown-Format erstellt und ins System eingepflegt.

Das Problem mit dem Hosting

Wir hatten nun einen modernen und praktischen Technologie-Stack. Nun stellte sich die nächste Frage: Wo hosten wir unsere Seite? Es gibt zahllose Anbieter auf dem Markt, von den einfachen Angeboten bei 1&1 bis hin zu komplexen Angeboten bei AWS und Co. Doch keins davon schien für unsere Anforderungen perfekt geeignet zu sein.

Nach einigen Stunden Recherche stießen wir auf Netlify, ein Startup aus den USA, welches sich genau auf solche Problemstellungen spezialisiert hat. Neben einem einfachen Hosting der Webseite bieten sie noch viele weitere praktische Tools an. Somit lief nach kurzer Zeit auch unsere Build-Pipeline für die Webseite komplett bei Netlify. Wir mussten gar nicht viel konfigurieren, da es bereits vorgefertigte Templates für Gatsby gibt.

In dem Moment, in dem wir einen neuen Blog-Beitrag in unser GitHub-Repository pushten, startete der Build und die neue Seite wurde vollautomatisch ausgeliefert, sofern keine Tests fehlschlugen. Auch die Domain wurde bereits dort verwaltet und automatisch ein passendes SSL-Zertifikat mithilfe von Let’s Encrypt bereitgestellt.

Auch für das Kontaktformular auf unserer Seite gab es eine praktische Lösung: Indem wir das Formular mit einem speziellen Netlify-Tag versehen, werden die Daten beim Absenden automatisch an das Netlify-Backend übermittelt, von wo aus eine große Auswahl an weiteren Anbietern angesprochen werden kann. Für den Anfang genügt vielleicht eine simple E-Mail-Benachrichtigung, während man die Anfragen später mithilfe einer REST-API in ein CRM einspeisen möchte. Das alles ist mit dieser Lösung problemlos möglich.

Das Problem mit den Inhalten

Das Problem mit der Trennung des Webseiten-Markups von den Seiten-Inhalten hatten wir bereits durch Gatsby gelöst. Nun stellte sich jedoch eine weitere Frage: Wie kann man die Inhalte anpassen, ohne das Repository auszuchecken, Änderungen vorzunehmen und diese zu pushen? Während das für einen Entwickler ganz alltäglich ist, kann das für Produktmanager und andere Nicht-Entwickler ein ernsthaftes Problem darstellen.

Wir benötigten also ein CMS. Da wir die Seite selbst bereits erstellt hatten, war ein reines Headless-CMS notwendig, welches nur die Inhalte verwaltete, ohne in das Rendering einzugreifen. Zu unserer Überraschung hatte Netlify auch hier eine Lösung im Angebot.

Das Netlify-CMS erlaubt es, Markdown-Dateien zu generieren, statt sie manuell zu erstellen. Hierzu werden zunächst die einzelnen Bereiche der Seite, die im CMS angepasst werden sollen, in einer YAML-Datei konfiguriert. Daraus wird in der Oberfläche dann eine Maske generiert, welche nur noch die tatsächlich relevanten Daten abfragt.

Nach dem Speichern werden diese automatisch in eine korrekte Markdown-Datei umgewandelt und ins GitHub-Repository gepusht. Dadurch wird dann wiederum die Build-Pipeline gestartet und das Deployment der neuen Inhalte ausgelöst. Wer sich selbst einmal an Gatsby und Netlify ausprobieren möchte, dem legen wir diesen Starter ans Herz: https://github.com/netlify-templates/gatsby-starter-netlify-cms

Was hat uns am meisten überrascht?

Zu Beginn waren wir der Meinung, dass das Erstellen der eigenen Webseite eine Sache von einigen Tagen oder maximal Wochen sei. React kannten wir ja bereits, mit GitHub und Markdown hatten wir auch bereits gearbeitet, wo sollte also das große Problem liegen?

Wie sich herausstellte, lagen wir erstmal auch nicht falsch. Die technische Entwicklung der Seite war tatsächlich innerhalb weniger Tage großteils abgeschlossen. Was wir jedoch ein wenig unterschätzt hatten, war die Erstellung der Seiteninhalte. Das Feilen an den Formulierungen, die Auswahl geeigneter Grafiken und Anpassungen am Design sorgten regelmäßig für Diskussionen und kosteten mit Abstand am meisten Zeit.

Aber zurück zur Technologie: Rückblickend war es die korrekte Entscheidung, die Seite selbst zu bauen und auf fertige Software wie WordPress und Co. zu verzichten. Wir haben jetzt eine schlanke, schnelle Webseite, an der Änderungen trotzdem auch ohne tiefergehende technologische Kenntnisse umgesetzt werden können. Zudem können wir auf die Einschränkungen, die viele fertige Systeme mit sich bringen, verzichten.

Unser Fazit: Wer einigermaßen gute Kenntnisse in React hat und eine statische, schnelle Webseite benötigt, macht mit Gatsby und Netlify sicher nichts verkehrt. Viel Spaß beim Ausprobieren!