Jamstack Bastone Launch

Das ist die erste einer Reihe von Case Studies zu denen von uns entwickelten Jamstack Websites. Für Taxi Bastone aus Schorndorf haben wir eine Website entwickelt, die schnell, zuverlässig, barrierefrei und bilingual ist.

Lesedauer: Ca. 5 Minuten

 

Taxi Bastone erreicht bei Lighthouse in allen Bereichen eine sehr gute Punktzahl.

Seit Inhaber Domenico Bastone 2008 sein Taxiunternehmen in Schorndorf gegründet hat, steht Taxi Bastone für zuverlässigen Service bei der Personen- und Sachbeförderung. Mit mittlerweile 10 Fahrzeugen, einer Zweigstelle in Winterbach und 21 Mitarbeiter*innen bietet Taxi Bastone neben dem Taxiservice auch ein breites Spektrum an weiteren Leistungen an, von Fernfahrten bis hin zum Flughafentransport und vielem mehr.

Als Herr Bastone uns bat, ihm eine neue Website zu entwerfen, war für uns sofort klar: Das war ein Fall für den Jamstack. Für die Anforderungen, die wir in einem gemeinsamen Workshop mit Herrn Bastone erarbeiteten, war eine Website auf Basis des Jamstack wie geschaffen: Eine Taxi-Website sollte es Nutzer*innen ermöglichen, möglichst schnell, zuverlässig und ohne Hindernisse eine der Taxi-Leistungen zu buchen. Das ist das zentrale Ziel der Website und darauf sollte die Technik immer zugeschnitten sein.

Der Jamstack bot sich hier aus drei Gründen besonders an: Geschwindigkeit, Zuverlässigkeit und Barrierefreiheit (Accessibility). Allerdings gab es auch eine zusätzliche Herausforderung: Die Website sollte bilingual, also sowohl auf Deutsch als auch auf Englisch abrufbar sein.

Geschwindigkeit

Die sehr hohe Geschwindigkeit einer Jamstack Website erleichtert die Buchung enorm und gibt Nutzer*innen das Gefühl, sie würden eine App benutzen, statt einer Website. Und das auch unterwegs auf dem Smartphone, was für ein Taxiunternehmen natürlich von großer Bedeutung ist. Selbst bei sehr schlechter Internetverbindung zum Beispiel in ländlichen Regionen, dürfte eine Jamstack Website noch schneller sein, als die meisten klassischen Websites.

Abgesehen von der Entwicklung auf dem Jamstack gibt es noch einige kleinere Optimierungen, mit denen sich noch mehr Speed herausholen lässt. Zum Beispiel werden alle Bilder “below-the-fold” erst nachträglich geladen, um den initialen Seitenaufbau nicht zu verlangsamen (sogenanntes Lazy Loading). Auch werden alle Bilder in einem modernen Format wie WebP und immer in der passenden Größe, je nach Gerät, ausgeliefert. Eine Smartphone-Nutzer*in bekommt also keine Bilder in Desktop-Größe, die erst clientseitig geschrumpft werden müssten.

Lighthouse, ein Tool von Google zum Testen von Websites, vergibt für die neue Taxi Bastone Website im Bereich “Performance” einen Wert von 97 von 100 möglichen Punkten.

Zuverlässigkeit

Für ein Taxiunternehmen, auf das sich die Kund*innen verlassen, wäre es fatal, wenn die Website zu bestimmten Zeiten nicht mehr erreichbar oder überlastet wäre. Dank CDN kann das bei einer Jamstack Website nicht passieren. Egal wie hoch der Andrang ist. Selbst wenn einer der Edge Server im Netzwerk mal ausfallen sollte, existieren immer noch eine hohe Zahl an alternativen Servern, die jederzeit einspringen können (mehr dazu in diesem Artikel).

Außerdem erfüllt die Website auch alle Voraussetzungen für eine Progressive Web App. Nutzer*innen können die Website somit zu ihren Smartphone-Bildschirmen hinzufügen und dann wie eine Native App sogar offline benutzen. Zwar ist es damit logischerweise nicht möglich, ohne Internetverbindung eine Taxifahrt zu buchen. Es kann aber dennoch nützlich sein, da die Nutzer*innen so zum Beispiel Informationen wie die Telefonnummer von TAXI Bastone auch offline nachlesen können.

Barrierefreiheit

Barrierefreiheit sollte heutzutage bei jeder Website eine Rolle spielen. Es geht dabei darum, die Website so zu entwickeln, dass sie für alle Nutzer*innen unabhängig von ihren Einschränkungen geeignet ist. Für ein Taxi-Unternehmen, das auch Leistungen wie Krankentransporte anbietet, ist dieser Punkt aber besonders wichtig. Hierbei gilt es zum Beispiel, darauf zu achten, dass die Website mit einem Screenreader (so werden Tools für Nutzer*innen mit Sehbehinderung genannt, die Websites vorlesen können) gut und verständlich wiedergegeben werden kann.

Das statische HTML, das beim Jamstack zur Runtime ausgeliefert wird, ist für Screenreader besonders gut lesbar. Es gibt aber noch einige Optimierungen, auf die bei der Webentwicklung generell geachtet werden sollte: Kontakt- oder Buchungsformulare sollten ausschließlich Labels verwenden und nicht nur Platzhalter. Alle Bilder und Icons sollten mit aussagekräftigen alt-Tags oder aria-Labels versehen sein. Auch sollte bei der Farbgebung darauf geachtet werden, dass die Kontraste stark genug sind, um alle wichtigen Elemente zu erkennen. Ein barrierefreies Routing muss dafür sorgen, dass die Navigation auf die Unterseiten von Screenreadern korrekt angekündigt wird. Darüber hinaus gibt es noch eine Vielzahl von kleineren Optimierungen, die Menschen mit Einschränkungen helfen können.

Die neue Website von Taxi Bastone erreicht bei Lighthouse im Bereich “Accessibility” 100 von 100 möglichen Punkten.

Bilingualität

Eine gewisse Herausforderung stellte die Mehrsprachigkeit dar. Unsere Lösung hierfür ist ein Language Switcher in der Navigation, die Library react-intl von format.js und das gatsby-plugin-i18n. Die tatsächliche Implementation war aber recht anspruchsvoll. Es galt darauf zu achten, dass auch dynamische, über das CMS Prismic generierte Seiten, wie die News und Stellenangebote, mit einem Klick übersetzbar sind. Darüber hinaus muss auch für Google jederzeit klar sein, welche Version einer Seite in welcher Sprache ist und dass es sich dabei nicht um ein Duplikat handelt. Wir konnten hier aber eine sehr gute Lösung erarbeiten, die auch bei künftigen mehrsprachigen Websites von uns zum Einsatz kommen wird.

Ein rundum gelungenes Projekt

Auch wenn der Fokus auf diesen vier Punkten lag, erfüllt die Website auch alle weiteren Anforderungen, die für uns selbstverständlich sind. Das Design ist modern und wird durch professionelles Fotomaterial ergänzt, das wir extra von unserem langjährigen Partner Ralf Klamann haben anfertigen lassen. Die Website ist komplett responsiv und wurde auf allen Kombinationen aus Bildschirmgröße, Betriebssystem und Browser getestet. Auch die Grundlagen der Suchmaschinenoptimierierung wie die Crawlbarkeit, Sitemap und robots.txt, optimierte H-Überschriften und Metadaten haben wir umgesetzt. Die seit Kurzem für das SEO-Ranking relevanten Core Web Vitals sind ebenfalls alle kerngesund, wie der Lighthouse-Report zeigt. Und das Wichtigste: Der Kunde ist happy.

Tech Stack: Gatsby.js, React, Prismic CMS, Netlify

In diesem Artikel beschreibe ich warum es wichtig ist, auf die Klimabilanz deiner Website zu achten, wie du sie messen kannst, welche Möglichkeiten zur CO2-Reduzierung es gibt und wie der Jamstack dir dabei helfen kann.

Lesedauer: Ca. 30 Minuten

Ein klimafreundliches Internet

Klimaschutz ist die Jahrhundertaufgabe. Nicht erst seit dem neuesten IPCC-Report ist klar geworden, dass wir unsere Gesellschaft deutlich umkrempeln müssen, um das 1,5-Grad-Ziel noch zu erreichen: Nur, wenn die Welt bis 2050 klimaneutral wird, wird es noch möglich sein, die globale Erwärmung durch CO2-Entnahme aus der Atmosphäre auf 1,4 °C zu senken.

Klimaneutralität bis 2050 ist kein einfaches Ziel. Der Verzicht auf Emissionen kann an manchen Stellen weitreichende Konsequenzen haben: In Entwicklungsländern stammen ein Großteil der Treibhausgas-Emissionen aus der Landwirtschaft, auf die natürlich nicht verzichtet werden kann. Umso wichtiger ist es deshalb, die Emissionen überall dort rigoros zu reduzieren, wo sie eben nicht notwendig sind. Jede*r von uns sollte sich der Verantwortung bewusst sein und die eigene Lebensweise kritisch hinterfragen: Wo produziere ich mit meinen Handlungen Emissionen? Worauf kann ich eventuell verzichten?

Als Webentwickler fällt mein Blick dabei unweigerlich auf das Internet. The Shift Project, ein Pariser Think Tank mit Fokus auf die Energiewende, hat den Einfluss des Internets auf das Klima untersucht und die Ergebnisse im März 2019 in dem Report „Lean ICT“ – Towards Digital Sobriety veröffentlicht. Darin wird geschätzt, dass das Internet für 3,7 % der gesamten Treibhausgas-Emissionen verantwortlich ist. Das ist vergleichbar mit dem weltweiten Flugverkehr. Und es ist davon auszugehen, dass dieser Anteil durch die Digitalisierung in den nächsten 20 Jahren noch deutlich steigen wird. Der Report geht von einem jährlichen Anstieg um 9% aus. Umso wichtiger ist es, dass wir auch das Internet möglichst klimafreundlich gestalten. Im Gegensatz zum Flugverkehr wird dieses Thema in der Öffentlichkeit aber relativ selten wahrgenommen.

Wir von Flanke 7 möchten unseren Teil dazu beitragen, indem wir bei unserer Arbeit auch auf die Klimabilanzen der von uns entwickelten Websites achten. Wie ich bereits geschrieben hatte, ist das auch einer der Gründe, warum wir den meisten unserer Kund*innen den Jamstack empfehlen. Aber warum ist eine Jamstack Website in der Regel klimafreundlicher als eine klassische Website? Dazu ist es wichtig zuerst zu verstehen, wie sich die Klimabilanz deiner Website generell messen und verbessern lässt.

Wie lässt sich die Klimabilanz deiner Website messen?

Die Klimabilanz deiner Website kann streng genommen nicht gemessen, aber relativ gut geschätzt werden. Es gibt verschiedene Tools, die so eine Schätzung vornehmen können, wie z.B. den Website Carbon Calculator oder EcoPing. Aber wie funktionieren diese Tools?

Der Website Carbon Calculator schätzt die Klimabilanz deiner Website auf Grundlage von fünf Kennzahlen ein:

  1. Wieviele Daten werden übertragen, wenn deine Website lädt?
  2. Wieviel Energie verbrauchen diese Daten? Sowohl die Rechenzentren, das Telekommunikationsnetzwerk als auch die Endgeräte der User verbrauchen eine bestimmte Menge an Energie pro übertragenem Byte. Der Calculator greift hier auf einen Durchschnittswert von 1,8 kWh pro Gigabyte zurück.
  3. Welche Energiequellen nutzen die Rechenzentren? Wenn ein Rechenzentrum einen Teil seines Stromes aus erneuerbarer Energie bezieht, reduziert der Calculator die CO2-Emissionen entsprechend. Da der Calculator natürlich nicht in der Lage ist, die Energiequelle des Telekommunikationsnetzwerkes und der Endgeräte zu kennen, geht er hier vom Standard-Stromnetz aus.
  4. Wie hoch ist die CO2-Intensität der verbrauchten Energie? Hier rechnet der Calculator mit dem internationalen Durchschnitt: 475 Gramm CO2 pro kWh für herkömmliche Energie und 33 Gramm CO2 pro kWH für erneuerbare Energie.
  5. Wieviele User besuchen deine Website? Aus den vorigen Kennzahlen lässt sich die Klimabilanz eines einzelnen Pageviews schätzen. Multipliziert mit der Anzahl der jährlichen Pageviews ergibt sich so die Klimabilanz deiner Website.

Die Jamstack Website tinyml.org produziert nur 0.47g CO2 pro Pageview.

Aber was kannst du jetzt tun, wenn der Website Carbon Calculator deiner Website einen relativ großen CO2-Fußabdruck bescheinigt? Zum Einen kannst du das CO2 kompensieren. Der Calculator selbst gibt dir hier ein paar Vorschläge und sagt dir auch, wieviele Bäume du pflanzen müsstest, um deine Website auszugleichen. Aber auch Anbieter wie zum Beispiel ClimatePartner können dir dabei helfen, die genauen CO2-Emissionen deines gesamten Unternehmens (und nicht nur der Website) zu berechnen und auszugleichen.

Wie lässt sich die Klimabilanz deiner Website verbessern?

Zum Anderen solltest du aber auch versuchen, die Klimabilanz deiner Website zu verbessern. Das geht vor allem, indem du die Menge der übertragenen Daten verringerst. Hierbei gibt es verschiedene Stellschrauben:

  1. Die Menge an Daten, die deine Website pro Pageload bzw. pro Sekunde übertragt.
  2. Die Dauer, die User im Durchschnitt brauchen, um ihr Ziel auf deiner Website zu erreichen.
  3. Die Anzahl an User, für die deine Website nicht relevant ist.

Die letzten beiden Punkte habe ich bewusst so formuliert. Natürlich sollst du nicht versuchen, die Sitzungsdauer deiner User oder die Anzahl deiner User einfach nur zu reduzieren. Das würde die Klimabilanz zwar schon verbessern, aber vor allem deinem Unternehmen schaden.

Stattdessen geht es darum, die User möglichst schnell an ihr Ziel zu führen. Und User, für die deine Website nicht relevant ist, sollten das möglichst früh merken. Am besten natürlich, bevor sie überhaupt auf deine Website gehen. Das ist nicht nur in dem Interesse der User, sondern auch in dem von Google.

Konkret können dabei Optimierungen in diesen Bereichen helfen:

  1. SEO: Je besser deine Website für Suchmaschinen optimiert ist, desto genauer können Google und co. deine Website an die richtige Zielgruppe ausspielen. Dadurch sinkt die Anzahl an irrelevanten Usern auf deiner Website.
  2. User Experience: Eine gute UX sorgt dafür, dass es möglichst wenige Hindernisse auf deiner Website gibt und deine User schnell an ihr Ziel kommen. Wenn ein User sich erst durch viele unübersichtliche Unterseiten klicken muss um das zu tun, was er/sie vorhat, dann steigt die Sitzungsdauer unnötig. Zu guter UX zähle ich hier auch gute Inhalte, die den Usern die gesuchten Informationen bereitstellen, ohne, dass sie dafür lange, unstrukturierte Artikel lesen müssten.
  3. Design: Der Großteil der Datenmenge einer Website besteht nicht selten aus Bildern, Fonts und Videos. Natürlich sollte deine Website noch gut aussehen und nicht komplett auf solche Elemente verzichten. Aber es kann helfen, einige Bilder, Videos und Fonts einmal zu hinterfragen: Bietet jedes Bild, Video und Font wirklich einen Mehrwert für das Design? Könnten einzelne Bilder vielleicht durch Vektorgrafiken oder CSS ersetzt werden? Sind die Bilder richtig optimiert, komprimiert und in einem effizienten Format (WebP)? Und werden alle importierten Fonts auch wirklich genutzt? Werden moderne Web Font Formate wie WOFF genutzt?
  4. Clean Code, Plugins und Skripte: Die Entwickler deiner Website sollten darauf achten, effizienten Code zu schreiben und nur Plugins zu installieren, die wirklich notwendig sind. Gibt es vielleicht noch alte Trackingskripte auf deiner Website, die nicht mehr benötigt werden? Nutzt deine Website Optimierungen wie Tree-Shaking, Lazy Loading oder Deferring von non-critical CSS?
  5. Caching: Caching sorgt dafür, dass deine Website nicht jedes mal komplett neu geladen wird, wenn ein wiederkehrender User deine Website erneut besucht.
  6. Performance Marketing: Wenn du Anzeigen schaltest, sei es bei Google, auf Social Media oder in Display-Netzwerken, solltest du dein Targeting natürlich immer so einstellen, dass möglichst nur relevante Klicks generiert werden.

Abgesehen von diesen Punkten kannst du übrigens auch darauf achten, einen möglichst energieeffizienten Hoster zu wählen. Entscheidend ist hierbei der sogenannte PUE-Wert (Power Usage Effectiveness). Dieser bildet sich aus dem gesamten Energieverbrauch eines Rechenzentrums geteilt durch den Energieverbrauch der dort betriebenen Computer. Je weiter der PUE-Wert über 1 ist, desto mehr Energie wird für externe Aufgaben wie die Kühlung benötigt. Der Durchschnitt liegt hier bei einem PUE von 1,67. Die besonders effizienten Rechenzentren von Google haben dagegen einen PUE-Wert von nur 1,11.

Das Problem mit den eben beschriebenen Optimierungsmaßnahmen wird schnell deutlich: Es scheint extrem aufwendig zu sein, eine klassische Website im Hinblick auf Klimafreundlichkeit zu optimieren. Genau hier kann eine Jamstack Website helfen.

Warum der Jamstack die beste Möglichkeit ist, die Klimabilanz deiner Website zu verbessern

Jamstack Websites sind generell klimafreundlicher als klassische Websites.

Was genau der Jamstack ist, kannst du hier nachlesen. Zusammengefasst werden Websites beim Jamstack-Ansatz vorab mit einem Static Site Generator (SSG) gebaut und dann zur Run Time (wenn ein User die Seite besucht) als fertige statische Website über ein Content Delivery Network (CDN) ausgeliefert. Das bedeutet, dass jedem User nur noch „fertiges“ HTML, CSS und JavaScript übertragen wird.

Herkömmliche Websites dagegen werden erst zur Run Time fertig gebaut, indem sie jedesmal, wenn ein User die Website besucht, mehrere Anfragen an den Backend-Server schicken. Das ist äußerst ineffizient und heutzutage nur bei wenigen, sehr dynamischen Websites noch notwendig. Jede dieser Anfragen an den Server verursacht zusätzliche CO2-Emissionen, die in den allermeisten Fällen vermeidbar wären.

Außerdem macht der Jamstack es eben auch möglich, die gesamte Website über ein CDN auszuliefern. Ein CDN ist ein Netzwerk aus Servern, die Edge Computing nutzen um Inhalte auf der ganzen Welt und besonders schnell zu verteilen. Diese Inhalte werden auf einem zentralen Origin Server gehostet und von dort auf einer Vielzahl von Edge Nodes, die auf der ganzen Welt verteilt stehen, gecached. Jede User*in bekommt die Inhalte dann von der nächstgelegenen Edge Node ausgeliefert. So wird die Entfernung, die die Daten zurücklegen müssen, so gut wie möglich reduziert. Dadurch sinkt auch der Energieverbrauch und damit die CO2-Emissionen. Zwar können (und sollten) klassische Websites CDNs auch nutzen. Allerdings nur um größere Inhalte wie Bilder und Fonts auszuliefern. Statische Jamstack Websites können dagegen komplett auf diese Weise verteilt werden.

Darüber hinaus sind viele der im vorigen Kapitel beschriebenen Optimierungen bei unseren Jamstack Websites schon von Haus aus enthalten:

  1. SEO: Im Gegensatz zu Single Page Applications sind Jamstack Websites auch für SEO-Crawler gut lesbar.
  2. User Experience: Die Ladezeiten einer Jamstack Website sind kaum wahrnehmbar. Diese Schnelligkeit verringert logischerweise die Zeit, die User brauchen, um an ihr Ziel zu gelangen.
  3. Design: Wir nutzen für unsere Jamstack Websites den SSG (Static Site Generator) Gatsby.js. Um viele der Optimierungen an Bildern, Videos und Fonts kümmert sich Gatsby schon direkt beim Bauen der Website. Zum Beispiel generiert Gatsby automatisch kleinere Versionen aller Bilder, damit Smartphone- und Tablet-User nicht Bilder in Desktop-Größe herunterladen müssen.
  4. Clean Code, Plugins und Skripte: Um Lazy Loading und Tree Shaking kümmert Gatsby sich. Und um effizienten Code und überflüssige Plugins und Skripte kümmern wir uns gerne.
  5. Caching: Das Caching übernimmt bei uns Netlify.

Einzig auf das Targeting deines Performance Marketings hat der Jamstack keinen Einfluss. Wir helfen dir hier aber auch gerne weiter.

Die Low-Hanging-Fruit in Kampf gegen die Klimakrise

The Shift Project fordert Unternehmen in ihrem Report zur „Digital Sobriety“ auf – also zu digitaler Abstinenz. Sowohl auf individueller als auch auf kollektiver Ebene sollte jede*r ihr Kauf- und Konsumverhalten von digitalen Produkten und Dienstleistungen im Hinblick auf die CO2-Bilanz hinterfragen. Wenn Unternehmen eine neue Website bauen lassen möchten, sollten sie sich deshalb fragen: Welche Features helfen meinen Nutzer*innen, schneller an ihr Ziel zu kommen? Und brauche ich dafür wirklich einen Server und eine Datenbank, oder erfüllt eine statische Jamstack Website eigentlich auch alle meine Anforderungen? Meiner Erfahrung nach sind die meisten dynamischen Inhalte mit statischen Jamstack Websites genau so gut umsetzbar.

Beispiel Unternehmensnews: Der Großteil der Unternehmen, die ich kenne, hat zwar eine News-Unterseite, veröffentlich dort aber nur relativ selten neue Artikel. Macht es da wirklich Sinn, dass bei jedem Pageview eine neue Anfrage an den Server geschickt wird, um die aktuellen Artikel abzurufen? Eine Jamstack Website wird dagegen neu gebaut, sobald das Unternehmen einen neuen Artikel veröffentlicht (dank Webhooks vollautomatisch). Danach wird bei jedem Pageview nur noch statisches HTML, CSS und JavaScript ausgeliefert, ohne weitere Anfragen an einen Server.

Klassische Websites sind also oft ineffizient und produzieren CO2-Emissionen für Features, die kaum einen Mehrwert bieten gegenüber der Jamstack-Variante. Und 2020 nutzten erst ca. 1% aller Websites den Jamstack!

Nein, nicht für alle Websites macht der Jamstack Sinn. Aber für einen großen Teil der 99% an Websites, die noch nicht den Jamstack nutzen, eben schon. Deshalb ist der Jamstack meiner Meinung nach die absolute Low-Hanging-Fruit im Kampf gegen die CO2-Emissionen von Websites.

Und das Beste daran ist: Während Klimaschutz in anderen Bereichen oft mit Verzicht einhergeht, ist das bei einem Wechsel zum Jamstack überhaupt nicht der Fall! Deine Website wird auch deutlich schneller, skalierbarer und sicherer. Du bekommst also eine rundum bessere und schnellere Website, die alle deine Anforderungen erfüllt und darüber hinaus auch besser für das Klima ist.

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.

100 Points in Page Speed Insights for a Jamstack Website

 

Beispiele für Jamstack Websites

Dies ist der erste Artikel einer Reihe zum Thema Jamstack. Demnächst werde ich in einigen Case Studies zeigen, welche Jamstack Projekte wir bereits für unsere Kund*innen umgesetzt haben. Folge uns am besten auf Instagram, LinkedIn oder Facebook, wenn du keinen der Artikel verpassen möchtest.

Bis dahin kannst du hier einige Beispiele für Jamstack Websites anschauen, die aber nicht von uns stammen:

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.

Darstellung des Jamstack Workflows

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: Mit diesem React-Framework 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.

Chart of Jamstack Adoption

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

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.