WPDUS #67 – Headless in die Zukunft mit WordPress

Vielen Dank auch für dein Interesse an diesem Thema.

Heute sprechen wir über WordPress als Headless CMS. Mal sehen, was es ist, wie es funktioniert und warum es interessant sein kann, es zu verwenden.

Einführung

Früher dachte ich, dass Headless bedeutet, dass man keinen Server mehr braucht, um eine Website zu berechnen und zu verteilen.

Aber die Terminologie ist etwas anders.

Das Wort Headless beschreibt ein Setup, bei dem das Backend oder CMS mit allen gespeicherten Inhaltselementen, der Body, von der Darstellungsebene, dem Head, getrennt ist. Bei einem Headless-Ansatz wird WordPress nur zum Erstellen und Verwalten von Inhalten und Strukturen verwendet, nicht jedoch zum Erstellen des Frontends, aller HTML-, CSS- und Javascript-Elemente, die eine Website im Browser zum Laufen bringen.

Schauen wir uns einen Moment im Detail an, wie es traditionell in einem monolithischen Ansatz funktioniert…

In einem traditionellen WordPress-Setup ist WordPress für alle Website-Funktionen verantwortlich. Ein Publisher verwaltet die Inhalte im Backend und lädt so viele Dateien, wie zum Beispiel Bilder hoch wie nötig.

Die Funktionalität stammt aus dem Kern und den Plugins, während das Erscheinungsbild der Website durch das Design, den Customizer usw. gesteuert wird. Letztendlich wird alles in der WordPress-Datenbank und im Dateisystem gespeichert.

Infolgedessen muss jede Anfrage von Benutzern, die die Website besuchen, alle oben genannten Phasen durchlaufen, bevor eine einzelne Website an den Browser geliefert wird. Ein Prozess, der für die meisten kleinen bis mittelgroßen Webprojekte funktioniert, aber bei komplexeren Projekten schnell ineffizient wird.

Die Abhängigkeiten all dieser gut funktionierenden Systeme, einschließlich externer Infrastruktur wie Hosting, können dein Projekt weiter behindern.

Was ist Headless?

In einer Headless-Konfiguration ändern sich die Dinge ein wenig. WordPress wird jetzt nur noch verwendet, um die Inhalte und Strukturen wie Taxonomien zu pflegen und zu organisieren. Die eigentliche Website wird nicht mehr von WordPress an den Browser geliefert und somit vom Rest entkoppelt.

Alle Inhalte werden nun über APIs wie REST oder GraphQL und das Dateisystem an das Frontend geliefert. Stell dir jede einzelne Site als ein Paket vor, das ihre Struktur beschreibt und alle notwendigen Inhalte enthält. Diese Pakete werden durch diese APIs beschleunigt ausgeliefert oder angeboten.

Dies gibt dir die Möglichkeit, alle deine Inhalte über eine Vielzahl verschiedener Frontends zu nutzen, die auf die jeweilige Benutzererfahrung zugeschnitten sind.

Okay, dafür gibt es tatsächlich viele verschiedene Lösungen. Wir wollen keine davon besonders ans Herz legen, da der Einsatz jeweils von den Anforderungen des Projekts oder deinem Geschmack abhängig sind möchte.

Einige von euch verwenden möglicherweise bereits eine Form der Entkopplung, wenn du Caching auf einem CDN verwendest zum Beispiel. Teile deiner Website werden also nicht mehr von deinem Hosting oder deinem WordPress bedient. Das hat schon für diese Teile den Vorteil, dass sie nicht mehr von WordPress berechnet werden müssen und direkt zum Nutzer gehen.

Aber die einfachste kopflose Möglichkeit, deine Website den BenutzerInnen bereitzustellen, ist die Verwendung eines statischen Ansatzes. Dies ist, wenn im Grunde jeder einzelne mögliche Aufruf der Website in eines der zuvor genannten Pakete wie HTML, CSS, Javascript und notwendige Dateien gerendert wird. Die gesamte Website existiert jetzt also als statische Website und muss nicht bei Bedarf gerendert werden, da alles vorberechnet und einsatzbereit ist.

Auf diese Weise benötigst du keine komplexen Server mit PHP- und SQL-Datenbanken, um deine Website bereitzustellen, und du kannst deine kompilierte statische Website auf jedem Edge-CDN-Hosting hosten. Was viel effizienter ist.

Ein im WordPress-Plugin-Repository erhältliches Plugin um seine eigene Website als statischen Paket zu erstellen ist Simply Static von Patrick Posner.

Simply Static

Dies alles kann bei verschiedenen Javascript-basierten Headless-Ansätzen komplizierter werden. In einem solchen Szenario zieht ein Build-Skript, genau wie beim statischen Ansatz, alle notwendigen Dinge aus der WordPress-API und erstellt eine Javascript-basierte Darstellung der Website, die auf ähnliche Weise bedient werden kann.

Auf diese Weise können mehr Funktionen genutzt werden, die du möglicherweise von der Arbeit mit Javascript gewohnt bist, was für die meisten Frontend-Entwickler unerlässlich ist.

Warum Headless?

Wir haben bereits ein wenig über die Vorteile von Headless gesprochen. Lass uns nun ein wenig mehr ins Detail gehen.

Vorteile

Einer der größten Fortschritte ist, dass Website-Manager einfach das Tool verwenden können, an das sie am meisten gewöhnt sind – das WordPress-Backend.

Außerdem hast du die Möglichkeit, viele verschiedene Tools von der Website zu kombinieren, die die Inhalte liefert, und wie du deine Inhalte an alle Arten von Endpunkten lieferst.

Einer der überzeugendsten Punkte unserer Arbeit ist die Leistung oder Performance. Mit Headless bist du unabhängig von der oben beschriebenen, herkömmlichen Serverinfrastruktur und kannst deutlich besser geeignete Auslieferungsmethoden voll ausschöpfen.

Wenn zur Auslieferung deiner Website nicht mehr auf die WordPress-Instanz zugegriffen werden muss, sind die meisten deiner Sicherheitsprobleme verschwunden, da die meisten Zugriffspunkte nicht mehr für die Öffentlichkeit zugänglich sind.

Und dann kannst du moderne Frontend-Frameworks voll ausnutzen, die in traditionellem WordPress noch nicht verfügbar sind.

Nachteile

Natürlich gibt es auch eine Reihe Nachteile, hier ein Einblick.

Funktionen, die zuvor einfach über Plugins verfügbar waren, sind nicht mehr verfügbar. Ihre Funktionalität muss nun in das separate Frontend integriert werden. Aber die gute Nachricht ist, dass viele Funktionen bereits unterstützt werden. Und es soll noch mehr kommen.

Im Moment sind weniger Themes verfügbar, aber auch das ändert sich ständig.

Die Anforderungen an die Umsetzung erfordert größere technische Fähigkeiten.

Die Verwaltung mehrerer Systeme kann eine Herausforderung darstellen, und die Wissensbasis eines Teams muss alle Systeme abdecken.

Die Komplexität nimmt zu. Zum Beispiel muss man sich ein wenig Gedanken über SEO und ähnliche Themen machen.

Pflege mehrerer Systeme.

Weniger Unterstützung und Dokumentation der möglichen Lösungen.

Häufige Änderungen mit Frameworks.

Lange Antwortzeiten bei Verwendung der Standard-REST-API

Mangel an kanalspezifischer Unterstützung. Da sich reine Headless-CMS nicht mit der Präsentationsschicht befassen, müssen Entwickler möglicherweise einige Funktionen selbst erstellen, z. B. die Website-Navigation.

Inhaltliche Organisation. Da reine Headless-CMS normalerweise nicht das Konzept von Seiten und Website-Sitemaps bieten, müssen sich Content-Redakteure darauf einstellen, dass Inhalte in ihrer reinen Form unabhängig auf der Website oder einem anderen Kanal organisiert werden.

Headless WordPress gibt dir mehr Gestaltungs- und Entwicklungsfreiheit. Diese Flexibilität hat jedoch ihren Preis.

Der Aufbau eines eigenen Frontends kann ein zeitaufwändiger und frustrierender Prozess sein. Es erfordert auch eine erhebliche Menge an technischem Know-how und kann das Schreiben von umfangreichem Code beinhalten.

Themes und Plugins sind ein großer Teil der WordPress-Erfahrung. Wenn du diese Plattform Headless ausführst, verlierst du sofort den Zugriff auf all diese zusätzliche Software. Wenn du eine neue Funktion hinzufügen oder dein Design ändern möchtest, muss es manuell in dem Projekt programmiert werden.

Schnellere Leistung

WordPress-Websites, die von Javascript-basierten Frontends betrieben werden, sind in der Regel unglaublich flüssig und reaktionsschnell, mit Millisekunden-Ladezeiten und vorab abgerufener Bereitstellung am Rand.

Verbesserte Sicherheit

Static-Site-Generatoren, die als Frontend für WordPress fungieren, haben keine aktiven Webserver und keine erreichbare Datenbank und bieten daher eine kleinere Angriffsfläche. Dieser Ansatz schützt besser vor böswillige Anfragen, DDoS-Angriffen und versehentliche Offenlegung.

Größere Flexibilität

Javascript-basierte Frontends können WordPress-Inhalte in komplexe, unternehmensweite Websites integrieren, die WordPress-Inhalte können mit Inhalten anderer CMS und Webdienste kombiniert werden.

Wann nutzt man Headless?

• Deine Website ändert sich nicht viel
• Websites, die sehr schnell geladen werden müssen
• Websites, die außergewöhnliche Sicherheit erfordern oder besonders von Hackern angegriffen werden
• Javascript-Experte
• Performance-Probleme
• Rein informative Seiten
• Unternehmensbroschüren online
• Landingpages, Kampagnen
• Perfekt für Blogs, Webmagazine
• z.B. politische Websites, Websites von Prominenten usw.
• SPA (Singe Page Applications)
• PWA (Progressive Web Applications)

Diese Einführung soll nur das Thema umreißen und eine Idee des Konzepts geben.

Im Einzelfall ist die jeweilige Lösung sehr von den vorher definierten Anforderungen abhängig.

Wir freuen uns auf dein Feedback, Fragen und Kommentare.