Der Jamstack erklärt - Die schnellste Website in deiner Branche

Vielleicht hast du es schon mitbekommen: Wir, das Team von der Flanke 7 Webentwicklung, haben uns im vergangenen Jahr immer mehr auf sogenannte Jamstack Websites spezialisiert. Damit entwickeln wir für unsere Kund*innen jetzt hochmoderne, modulare Websites, die klassischen Websites vor allem im Hinblick auf Geschwindigkeit, Sicherheit und Skalierbarkeit deutlich überlegen sind. Was sich hinter dem Begriff "Jamstack" verbirgt und warum er so wichtig für die Zukunft der Webentwicklung ist, erkläre ich in diesem Artikel.

Beispiele für Jamstack Websites

Hier kannst du dir einige Beispiele für Jamstack Websites anschauen:

• Mammut
• Klarna
• Pan Macmillan
• Taxi Bastone
• Heyflow
• COVID Tracking Project
• Die Mobile Version von Twitch.tv
• Netflix Jobs

Was ist der Jamstack?

Der Begriff Jamstack ist gar nicht mehr so neu: Bereits 2016 hat der CEO von Netlify, Mathias Biilmann, seine Idee für eine Jamstack Architektur auf der SmashingConf vorgestellt. Das "Jam" stand hier noch für JavaScript, APIs und Markup. Inzwischen ist der Begriff aber über die ursprüngliche Definition hinausgewachsen und beschränkt sich nicht mehr nur auf diese drei Technologien.

Im Grunde ist der Jamstack eine Lösung für verschiedene Probleme, die herkömmliche Websites haben. Die genaue Ausgestaltung ist dabei sehr unterschiedlich. Aber im Kern geht es darum, die vielen Vorteile von statischen Websites zu nutzen. Diese sind in der Regel schneller, sicherer und skalieren besser. Dabei greifen Entwickler*innen auf moderne (JavaScript)-Frameworks (in der Regel React, Angular, Vue oder Svelte) und andere state-of-the-art Tools, wie CDNs, Headless CMSs oder Static Site Generators, zurück (am Ende dieses Artikels findest du eine Begriffserklärung).

Wie sich der Jamstack von klassischen Websites unterscheidet

Aber wie funktioniert das genau? Dazu lohnt ein Blick auf die Unterschiede zu herkömmlichen Websites. Zu Beginn waren alle Websites statisch, das heißt, ihr Inhalt konnte sich nur ändern, wenn eine Webentwickler*in eine Änderung am Code vornahm. Erst Mitte der 90er-Jahre entwickelte Rasmus Lerdorf mit PHP eine Möglichkeit, dynamische Inhalte darzustellen. Damit war es möglich, eine Anfrage an einen Server bzw. eine Datenbank zu senden, wenn eine Nutzer*in eine Website aufruft. Der Inhalt der Website konnte jetzt also ohne direkte Änderungen am Code aktualisiert werden. Zum Beispiel können in einem Blog wie unserem immer die neuesten Blogartikel aus der Datenbank geholt und auf der Übersichtsseite sowie den einzelnen Detailseiten dargestellt werden. Damit legte Lerdorf auch den Grundstein für das Web 2.0. Plattformen wie Facebook, die für jede Nutzer*in einen individuell angepassten Feed darstellen, wären ohne dynamische Inhalte undenkbar. Meistens wurde damals der sogenannte LAMP-Stack genutzt: Linux, Apache, MySQl und PHP.

Dynamische LAMP-Stack Websites stoßen allerdings inzwischen an ihre Grenzen. Denn jeder dieser dynamischen Inhalte muss beim Besuch einer Nutzer*in erst generiert werden, indem eine Anfrage an einen Server geschickt wird. Je nach Server kann es dauern, bis diese Anfrage zurück kommt. Aus der Antwort und dem Markup der Website (also dem HTML) wird dann die fertige Seite gebaut und ausgeliefert.

Hierin unterscheidet sich der Jamstack: Die Websites werden bereits vorab gebaut (Build Time), und nicht erst, wenn eine Nutzer*in auf die Website klickt (Run Time). Ein Static Site Generator sammelt in regelmäßigen Abständen alle Inhalte (aus Datenbanken, CMSs, von APIs etc.) zusammen, kombiniert diese mit dem Markup und baut daraus eine statische Website. Diese Website wird dann über einen CDN ausgeliefert. Da zur Run Time jetzt keine Anfragen mehr an irgendwelche Server gesendet werden müssen, sind solche Jamstack Websites fast immer sehr viel schneller als klassische LAMP-Stack Seiten.

Dynamische Inhalte sind auch mit dem Jamstack möglich

Allerdings handelt es sich bei Jamstack Websites nicht einfach nur um die in ihren Möglichkeiten eingeschränkten, statischen Websites, wie sie in den 90ern üblich waren. Zum Einen kann der Build-Vorgang des Static Site Generators regelmäßig neu gestartet werden, wenn sich ein Inhalt verändert. Dieser Vorgang dauert in der Regel unter einer Minute. Für eine Plattform wie Facebook wäre das natürlich nicht geeignet. Aber für zum Beispiel einen Blog reicht es vollkommen aus, wenn der Build-Vorgang einfach jedes mal neu ausgelöst wird, sobald man einen neuen Blogartikel veröffentlicht oder jemand einen Kommentar hinterlässt. Durch Webhooks ist es außerdem problemlos möglich, den Build-Vorgang in solchen Fällen automatisiert auslösen zu lassen.

Zum Anderen bietet JavaScript auch die Möglichkeit, zur Run Time asynchrone Anfragen an externe APIs zu senden (AJAX) und deren Antworten direkt darzustellen. Viele dynamische Features lassen sich so nachliefern. Ermöglicht wird dies auch durch ein sehr reiches Ökosystem an sogenannten Microservices. Zum Beispiel kannst du mit Algolia eine Live-Suchfunktion per API in deine statische Website integrieren, mit Stripe eine Bezahlungsabwicklung. Bei spezielleren Anwendungsfällen kannst du einfach auf Serverless Functions zurück greifen, die z.B. AWS, Netlify oder Vercel anbieten. Damit kannst du deine eigenen Funktionen schreiben, in der Cloud speichern und anschließend per API auslösen.

Fassen wir also nochmal zusammen: Bei Jamstack Websites ist das Frontend vom Backend entkoppelt; das Betreiben eines klassischen Backends mit eigenem Server und Datenbank ist nicht mehr nötig. Stattdessen werden Inhalte aus einem nutzerfreundlichen Headless CMS, verschiedenen anderen Quellen und dem Markup bzw. dem Code auf GitHub (oder ähnlichen Plattformen) kombiniert. Daraus baut ein Static Site Generator eine fertige, statische Website, die dann über ein CDN ausgeliefert wird. Kommt dann eine Nutzer*in auf die Website, werden bei Bedarf noch einzelne dynamische Inhalte mit AJAX von einer API geholt und nachgeliefert.

Eine Besonderheit gibt es noch bei Next.js und seit Version 4 auch bei Gatsby.js: Mit diesen React-Frameworks ist eine Hybrid-Architektur möglich. Einzelne Unterseiten können komplett statisch sein, während andere Unterseiten oder Komponenten, die dynamisch sein sollen, serverseitig gerendert werden. So ist es möglich, das Beste aus beiden Welten zu erhalten.

Welche Vorteile bietet der Jamstack?

Der Jamstack bietet viele Vorteile im Vergleich zu herkömmlichen Websites.

Schnelligkeit

Nur mit dem Jamstack lässt sich die maximale Geschwindigkeit für deine Website herausholen. Nicht nur, dass der Ausflug zum Server und zurück zur Run Time komplett wegfällt. Auch kann die statische Jamstack Website über einen CDN ausgeliefert werden. Und ein plötzlicher Ansturm von Nutzer*innen hat kaum einen Effekt auf die Geschwindigkeit, da es keinen dedizierten Server gibt, der überlastet werden könnte.

Eine so schnelle Website zieht wiederum viele weitere Vorteile nach sich:

• Eine verbesserte User Experience durch kürzere Ladezeiten führt direkt und messbar zu einer höheren Conversion Rate und niedrigeren Absprungraten.
• Schnelle Websites werden von Nutzer*innen als moderner wahrgenommen. Ein Effekt, der sich auf deine Marke überträgt.
• Eine schnellere Ladezeit wirkt sich positiv auf die Core Web Vitals aus und hat dadurch einen direkten Einfluss auf das SEO-Ranking deiner Website.
• Eine schnellere Ladezeit wirkt sich positiv auf die "Nutzererfahrung mit der Landingpage" in Google Ads aus und erhöht so deinen Qualitätsfaktor. Ein höherer Qualitätsfaktor verbessert deinen Anzeigenrang bei niedrigeren Klickkosten.

Skalierbarkeit

Wie bereits erwähnt, kann eine Jamstack Website nicht unter plötzlichen, sehr hohen Besucheranstürmen zusammenbrechen wie eine klassische Seite. Ein CDN besteht immer aus einer Vielzahl von Edge Servern. Ist einer mal offline, wird einfach der nächste eingesetzt. So eignet sich der Jamstack auch für Websites, die in Zukunft stark wachsen wollen und eventuell mit temporären Trafficsprüngen rechnen müssen. Dein Startup hat einen Auftritt im Fernsehen? Mit einer Jamstack Website kannst du dich entspannt im Sessel zurücklehnen.

Klimafreundlichkeit

Das Internet ist für ungefähr 3,7% der weltweiten Treibhausgasemissionen verantwortlich (Quelle). Eine sehr gute Möglichkeit den Anteil deines Unternehmens hieran zu reduzieren ist der Umstieg auf eine statische Jamstack Website. Zum Einen reduziert eine schnellere Website die Zeit, die eine Nutzer*in auf deiner Website verbringt. Zum Anderen kommen statische Seiten komplett ohne Server oder Datenbanken aus, die bei klassischen Websites bei jedem Pageview angesprochen werden. Mehr zu diesem Thema kannst du in diesem Artikel lesen.

Den ungefähren Impact deiner Website kannst du zum Beispiel mit dem Website Carbon Calculator schätzen lassen.

Sicherheit

Ohne eine eigene Datenbank oder einen Server, auf die deine Website direkt zugreift, entfallen gleich mehrere Angriffsvektoren, wie z.B. SQL Injection oder DDoS Attacks.

Nachteile

Natürlich hat der Jamstack auch einige Nachteile. Für manche, sehr dynamische Web Apps war der Jamstack lange schlichtweg nicht sinnvoll. Wenn zuviele Inhalte asynchron nachgeliefert werden mussten, schwindet der Vorteil bei der Performance schnell dahin. Eine Lösung hierfür bietet Next.js mit der Hybrid-Architektur.

Darüber hinaus muss die Build Time, die je nach Größe auch schon mal über eine Minute dauern kann, immer bedacht werden. So kann es manchmal ein wenig dauern, bis z.B. ein veröffentlichter Blogartikel auf deiner Website zu sehen ist. Zwar verfügen die meisten Headless CMSs über Preview-Funktionen, die das zu umgehen versuchen. Diese bringen aber gewisse Einschränkungen mit sich. Auch gibt es noch keine wirklichen WYSIWYG-Editoren für Jamstack Websites.

Solltest du jetzt schon auf den Jamstack wechseln?

Angesichts der vielen Vorteile lässt sich meiner Meinung nach sagen, dass der Jamstack, oder zumindest eine Hybridarchitektur mit Next.js, heutzutage für einen Großteil der Websites Pflicht sein sollte. Und je früher du umsteigst, desto besser: 2020 nutzten erst ca. 1% aller Websites den Jamstack (siehe Grafik). Der Anteil verdoppelte sich aber im Vergleich zum Vorjahr. Früher oder später werden sich die Nutzer*innen an die Geschwindigkeit einer Jamstack Website gewöhnt haben und diese voraussetzen.

Wahrscheinlich kennst du das Gefühl, wenn du nach einer längeren Fahrt auf der Autobahn wieder in ein Stadtgebiet fährst, und sich 50 km/h wie Schritttempo anfühlen. Diesen Effekt nennt man "Adaption". Deine Wahrnehmung von Geschwindigkeit hat sich an das Tempo auf der Autobahn gewöhnt und es dauert eine gewisse Zeit, bis du dich wieder an das Tempo in der Stadt gewöhnst.

Genau diesen Effekt habe ich immer, wenn ich länger auf einer Jamstack Website unterwegs war, und dann wieder auf eine herkömmliche Website wechsel. Eigentlich normale Ladezeiten fühlen sich auf einmal furchtbar langsam an.

Und hier liegt für mich das große Potenzial für deine Website: Stell dir mal vor, deine potenziellen Kund*innen vergleichen gerade mehrere Anbieter miteinander. Nachdem sie länger auf deiner Jamstack Website unterwegs waren und sich an die Geschwindigkeit gewöhnt haben, wechseln sie zum Vergleich zur Seite deiner Konkurrenz, die noch eine klassische Website haben. Dank Adaption wird sich die Website deiner Konkurrenz extrem langsam und veraltet anfühlen. Der Vorteil liegt auf der Hand. Wenn du jetzt Teil der 1% wirst, die den Jamstack schon nutzen, ist es gut möglich, dass du zu den Einzigen in deiner Branche gehören wirst, die dieses Gefühl mit ihrer Website hervorrufen können.

Der Anteil an Jamstack Websites nimmt jährlich zu, betrug 2020 aber erst ca. 0,9%.[/caption]

Begriffserklärung

Einige für den Jamstack wichtige Begriffe erkläre ich hier kurz. Falls du einen Begriff nicht kennst, kannst du ihn hier nachlesen.

AJAX

Diese Abkürzung steht für Asynchronous JavaScript and XML. Dabei handelt es sich um eine Technologie, mit der es möglich ist, Daten zur Run Time asynchron zu senden und zu empfängen. Hierbei handelt es sich heutzutage in der Regel um Daten im JSON-Format, die von einer externen API angefordert werden. Asynchron bedeutet, dass diese Daten im Hintergrund angefragt werden, ohne den Aufbau der eigentlichen Website zu verzögern und ohne die Website neu laden zu müssen.

API

Ein Application Programming Interface ist eine Schnittstelle einer Software, die es anderer Software ermöglicht, mit ihr zu kommunizieren und Daten auszutauschen. Eine API ist also sozusagen ein User Interface, nur nicht für User, sondern für andere Programme. Die geläufigsten modernen APIs basieren auf den Architekturen SOAP, REST und GraphQL. Heutzutage gibt es eine sehr große Auswahl an APIs, die du nutzen kannst, um externe Daten oder Inhalte abzufragen und auf deiner Website darzustellen. Dies reicht von der Dog API, die zufällige Bilder von Hunden ausliefert, und Weather APIs, die das aktuelle Wetter für eine Region anbieten, bis hin zu komplexen APIs für ECommerce-Lösungen oder Bezahldiensten wie PayPal oder Stripe.

CDN

Ein Content Delivery Network ist ein Netzwerk aus Servern, das besonders schnelles Ausliefern von Inhalten (wie z.B. statischen Websites) ermöglicht. CDNs nutzen Edge Computing, das heißt, dass Dateien zentral auf einem Origin Server gehostet, aber von dort auf lokale Servern, sogenannten Edge Nodes, verteilt und gecached werden. Diese Edge Nodes stehen optimalerweise auf der ganzen Welt verteilt. Wenn eine Nutzer*in jetzt diese Inhalte anfordert, liefert eine Edge Node in der Nähe der Nutzer*in sie aus. Dadurch ist eine statische Website in einem CDN nahezu überall auf der Welt mit sehr guten Ladezeiten zu erreichen. Auch ist ein Ausfall eines einzelnen Servers kein Problem mehr, da in dem Fall einfach eine andere Edge Node aushelfen kann. Zu den bekanntesten CDNs zählen Cloudflare oder Fastly. Aber auch AWS, Google Cloud, Microsoft Azure, Netlify und Vercel haben eigene CDNs in ihrem Repertoire.

Headless CMS

Ein CMS (Content Management System) bietet vor allem ein nutzerfreundliches Interface für Autor*innen, um Inhalte zu einer Website hinzuzufügen, ohne dafür Coding-Kenntnisse zu benötigen. So kann eine Unternehmer*in auf ihrer Website problemlos Bilder hochladen oder eine News veröffentlichen, ohne dafür jedes mal eine Entwickler*in zu kontaktieren. Zu den bekanntesten klassischen CMSs zählen unter anderem WordPress, Drupal, Contao, TYPO3 oder im Shopbereich zum Beispiel shopify, shopware oder Magento. Diese bieten neben der Verwaltung von Inhalten aber auch ein komplettes Frontend, auf dem die Inhalte dargestellt werden. Wie hier beschrieben hat so eine monolithische Website aber viele Nachteile. Deshalb setzen viele Entwickler*innen heutzutage auf sogenannte Headless CMSs, die sich nur auf die Organisation von Inhalten konzentrieren. Statt diese Inhalte in einem Frontend darzustellen, werden sie nur über eine API erreichbar gemacht. Einige Beispiele für solche Headless CMSs sind Contentful, Prismic, Sanity, Forestry, Strapi oder Ghost. Aber auch viele klassische CMSs können inzwischen auch alternativ Headless eingesetzt werden. Zum Beispiel haben wir bereits eine größere Gatsby-Website mit Headless WordPress umgesetzt. Eine Übersicht über alle Möglichkeiten findest du hier.

SSG

Ein Static Site Generator ist das wohl wichtigste Tool für den Jamstack. Oft (aber nicht immer) handelt es sich dabei um einen JavaScript-Framework, der Inhalte für eine Website aus verschiedenen Quellen sammelt, mit Markup kombiniert, und daraus eine statische Website baut. Es gibt viele verschiedene SSGs mit unterschiedlichen Vor- und Nachteilen. Wir bei Flanke 7 benutzen Gatsby.js und Next.js. Eine Übersicht über alle Möglichkeiten findest du hier.