Spotlight: Wissenswertes zum Thema statische Webseiten

In diesem neuen Beitrag unserer Spotlight-Serie erfährst du, was statische Webseiten ausmacht, wann sie sinnvoll sind und welche Vorteile wie u.a. Geschwindigkeit, Sicherheit und Kosteneffizienz sie bieten. Zudem werden Einsatzmöglichkeiten und Alternativen beleuchtet, falls dynamische Inhalte erforderlich sind.

Was sind statische Webseiten?

Statische Webseiten bestehen aus vorab generierten HTML-Dateien, die direkt auf z. B. einem Webserver gespeichert sind und unverändert an den Benutzer ausgeliefert werden, sobald eine Anfrage eingeht.

Wo kann man statische Webseiten besonders gut einsetzen?

Statische Webseiten eignen sich besonders für Inhalte, die sich selten ändern, wie beispielsweise Portfolioseiten, Informationsseiten, Landingpages, Unternehmenspräsentationen, Blogs und Dokumentationen.
Um einschätzen zu können, ob statische Seiten ideal für ein Webprojekt sind, ist zu prüfen, wie viele Seiten die Webseite in allen Sprachen hat, wie häufig sich der Content auf diesen Seiten ändert und wie viele der Seiten im Durchschnitt aufgerufen werden. Statische Seiten sind besonders sinnvoll, wenn die Gesamtanzahl der Seiten überschaubar ist und ein großer Teil dieser Seiten regelmäßig aufgerufen wird, da sonst der Aufwand für die Erstellung und Aktualisierung der statischen Seiten nicht mehr im Verhältnis steht.

Welche Vorteile haben statische Webseiten?

Die Hauptvorteile sind hohe Geschwindigkeit, hohe Sicherheit, niedrige Kosten und einfache Wartung. Zudem sind statische Seiten sehr gut von Suchmaschinen-Crawlern zu indizieren.

Warum haben statische Webseiten eine hohe Performance? 

Statische Webseiten müssen nicht bei jeder Anfrage neu generiert werden und benötigen daher zur Laufzeit keine serverseitige Verarbeitung durch PHP, ASP, JAVA, Node.js oder Datenbankabfragen. Dies verkürzt die Ladezeiten und schont die Server-Ressourcen. Darüber hinaus sind statische Webseiten sehr cache-freundlich, sodass sie problemlos in verschiedenen Caches (z.B. CDNs) gespeichert werden können, was zu extrem schnellen Ladezeiten führt.

Wie kann ich statische Seiten global verfügbar machen?

Der einfachste Weg der globalen Verfügbarkeit, ist der CDN-Ansatz. Dazu wählt man einen Hosting-Dienst mit vielen global verteilten CDN-Knoten (PoP – Point-of-Presence), der eine weltweit niedrige Latenz gewährleistet. Wenn man so ein CDN verwendet, können die HTML-Dateien vom zum Benutzer nächstgelegenen Server an diesen in kürzester Zeit ausgeliefert werden, was die Ladezeit der Seite erheblich verkürzt. Durch eine globale Verteilung der Daten auf sinnvoll gelegenen CDN Point-of-Presence, kann zudem die Latenz stark reduziert werden, wodurch eine schnellere und reaktionsfähigere Benutzung ermöglicht wird.

Warum haben statische Webseiten eine hohe Kosteneffizienz?

Da statische Webseiten bei der Auslieferung im Vergleich zu klassischen dynamischen Webseiten keine komplexe Infrastruktur benötigen, reduzieren sich in der Regel die Hosting-Kosten.

Es gibt theoretisch zwei benötigte Infrastrukturen.

Die Infrastruktur A, die für die Auslieferung der Webseiten an die Besucher zuständig ist und die Infrastruktur B, die eingesetzt wird, um die statischen Seiten zu generieren. 

Die Infrastruktur A, die für das Ausliefern der Seiten zuständig ist, kann technisch sehr simpel sein, da theoretisch nur ein schlanker Webserver nötig ist und Drittsysteme wegfallen. Selbst mit kleine VMs und einem schnellen Webserver (z.B. Nginx) können leicht viele Millionen von Anfragen pro Minuten bearbeitet werden.

Möchte man global verteilt sein, kann man den Einsatz eines CDN in Erwägung ziehen. Am einfachsten geht dies über einen Static Site Hosting Service, wie z.B. , Netlify, Azure Static Web Apps, AWS Amplify, Cloudflare Pages oder Vercel, bei welchen ab dem Deployment die komplette Bereitstellung und der Betrieb übernommen wird.

Die Infrastruktur B wird meistens schon vom CMS vorgegeben. Eine Skalierung dieser Infrastruktur ist vom CMS abhängig, aber auch davon, welche Menge an statischen Seiten, wie häufig und in welchem Zeitfenster generiert werden muss. Je weniger Seiten es sind und je seltener generiert werden muss und je mehr Zeit man dafür verwenden darf, umso schmalspuriger kann diese Infrastruktur aufgebaut sein.

Hat man es z.B. mit vielen zigtausend Seiten pro Tag zu tun, die innerhalb von 60 Minuten generiert werden müssen, dann muss dieses Infrastruktur entsprechend performant aufgestellt sei. Hier sollte man prüfen, ob sich eine automatisch skalierbare Serverless-Architektur (serverless functions & computing) bezahlt macht, da diese Architekturen in der Regel nach einem nutzungsbasierten Preismodell abgerechnet werden. Bei solch extremen Szenarien ist jedoch auch eine genaue Prüfung des Sinns eines voll-statischen Ansatzes angebracht.

Warum benötigen statische Webseiten wenig Wartung?

Da statische Webseiten bei der Auslieferung im Vergleich zu klassischen dynamischen Webseiten keine komplexe Infrastruktur benötigen, reduzieren sich in der Regel die Wartungskosten. Es sind weniger Systeme und Software nötig, was dadurch auch die Aufwände und Fachkompetenz bei der Wartung reduziert.

Im Fall der Auslagerung in ein CDN per Static Site Hoster, ist der eigene Wartungsaufwand minimal, da der Dienstleister den technischen Betrieb betreut. Hier entstehen natürlich externe Kosten, die sich meistens am reichen Traffik orientieren, aber auch stark abhängig davon sind, welche speziellen Features und Zusatzdienste (z.B. Firewall, DDoS-Schutz) man in Anspruch nimmt.

Wann macht Static Site Generation keinen Sinn mehr?

Müssen zum Beispiel jeden Tag hunderttausende von Seiten neu generiert werden, obwohl nur ein sehr kleiner Teil davon überhaupt von Besuchern aufgerufen wird, dann ist dieser Ansatz zu überdenken. Man sollte hier aber ins Detail gehen und schauen, warum sich auf so vielen Seiten jeden Tag Content ändert.

Wenn sich z.B. ein auf allen Seiten vorhandener, sich täglich ändernder News-Teaser für eine Neu-Generierung Ursache ist, dann wäre hier ggf. einen teildynamischen Ansatz vorzuziehen, bei dem sich der News-Teaser erst im Browser zur Laufzeit über eine API die Daten holt und per clientseitigem Rendering (CSR) darstellt.

Ob statisch Seiten oder dynamisch API-Driven WebApps (SPA, MPA, PWA) oder eine Kombination die sinnvollste Wahl ist, sollte man generell vor jedem Webprojekt grundlegend mit seinem technischen Dienstleister evaluieren.

Wie bekomme ich interaktive Element auf meine statische Webseite?

Auch statische Webseiten können JavaScript enthalten und auf JavaScript basierende Module / Elemente beherbergen. Diese kommunizieren dann mit APIs oder Serverless Function (z.B. Netlify Functions, Azure Functions, AWS Lambda, Cloudflare Worker) um Daten zu laden oder Daten zu speichern.

Wie bekommt man Formulare auf eine statische Website?

Im Sinne des composable Ansatzes nutzt man für Formulare bevorzugt entsprechende Formular-Dienste wie Jotform, Formstack, Formspree oder andere.
Falls Sie bereits einen Marketing Cloud einsetzen, bietet diese ggf. bereits einen Formulardienst, den man in Webseiten einbinden kann.
Auch im Bereich der Static Site Hoster werden teilweise schon vom Anbieter eigene Formulardienste angeboten (z.B. Netlify Forms) oder Integrationen für die gängigen Dienste.
Alternativ kann man auf JavaScript basierende interaktive Formulare entwicklen und einsetzen, die mit einer Serverless Function kommunizieren.

Wie bekomme ich eine Suche auf meine statische Webseite?

Ein gängiger Ansatz um eine Suche auf die Webseite zu bekommen, ist die Einbindung von entsprechenden Such-Diensten wie Algolia oder Elastic. Interaktive Elemente wie z.B. der On-Site-Search-Slot werden meistens bereits vom Dienst mitgeliefert.

Warum sind statische Webseiten sicherer?

Da statische Webseiten keine serverseitige Logik enthalten, bieten sie weniger Angriffsflächen für typische Sicherheitslücken, die dynamische Webseiten betreffen. (Typische Sicherheitslücken sind z.B. Cross-Site-Scripting, Remote Code Execution, SQL-Injection, etc.).

Warum sind statische Webseiten zuverlässiger und weniger ausfallgefährdet?

Durch die wenig komplexe Infrastruktur kann weniger kaputt gehen und auch weniger aktiv “böswillig” beeinträchtigt werden (z.B. DDoS-Angriffe).
Setzt man bei Hosting auf den Ansatz alles über ein CDN auszuliefern, dann ist dieses System quasi “unkaputtbar”, denn in einem CDN wird der Verkehr auf verschiedene Server verteilen, um eine bessere Lastverteilung und Skalierbarkeit zu gewährleisten. Wenn ein Server ausfällt, können andere Server im Netzwerk den Datenverkehr übernehmen, was zudem zu einer hohen Ausfallsicherheit führt. Die Webseite ist so, im Gegensatz zum klassischen Ansatz mit einem zentralen Webserver, nicht mehr von der Serverkapazität, der aktuellen Serverbelastung und aktuellen Uptime des Servers abhängig.

Hat man beim klassischen Ansatz Sorgen, dass der Webserver mal ausfällt, was dann bevorzugt nachts oder an Wochenenden passiert, sinkt dieses Risiko mit dem statischen Ansatz und dem CDN quasi gegen Null, womit auch “nächtliche” Wiederherstellungsaktionen durch 24/7-Bereitschaftsdienste zur Seltenheit werden.

Wie kann ich statische Seiten skalieren?

Das oben beschriebene Prinzip der Ausfallsicherheit durch die Verteilung auf verschiedene Server greift auch bei der Skalierung. Ist eine hohe Last auf einem Pop (CDN-Knoten), wird der Verkehr auf naheligende Server geroutet, um eine bessere Lastverteilung und Skalierbarkeit zu gewährleisten. So gesehen muss man nicht mehr aktiv eingreifen um eine Seite zu skalieren, da dies durch das CDN automatisch passiert.

Warum helfen static Sites gegen DDoS Angriffe?

Durch die weniger komplexe Infrastruktur kann auch weniger kaputt gehen oder auch weniger aktiv “böswillig” beeinträchtigt werden (z.B. DDoS-Angriffe).

Setzt man auf ein CDN, dann sind DDoS-Angriffe schwerer, als wenn es um einen einzelnen Server ginge. Aber Obacht, auch wenn das Netz zum Großteil verhindert, dass die Webseite bei einem DDoS nicht mehr erreichbar ist, können hier trotzdem hohe Kosten durch den Traffic etc. entstehen. Die meisten CDN-Dienstleister bieten dafür jedoch auch Abwehrmechanismen an, die das CDN und die Webseiten schützen.

Welche Nachteile haben statische Webseiten?

Statische Seiten sind nicht dynamisch bzw. nur durch Einbettung von dynamischen Elemente und Modulen dynamisierbar.

Braucht man hochdynamische und personalisierte Web-Apps, wie z.B. beim geschützten Login-Bereich (z.B. Onlinebanking, Web-Mail, Spotify im Browser, etc.), dann macht ein statischer Ansatz keinen Sinn.
Bei solchen Szenarien würde man voraussichtlich auf Single-Page-Applications oder Progressive Web Apps setzen, die gegen APIs gehen und die Seiten clientseitig rendern (CSR).

Es gibt jedoch auch Anwendungsfälle, in denen man hybride und kombinierte Modelle fahren kann. Man sollte deshalb vor der Umsetzung eines Webprojektes ins Detail gehen und prüfen, welcher Aufbau für das Projekt die sinnvollste Wahl ist.

Wie erzeuge ich statische Seiten und was ist SSG?

Statische Seiten werden durch ein Framework oder eine CMS-Komponente erstellt. Dieser Prozess, bekannt als Static Site Generation (SSG), generiert und speichert HTML-Dateien im Voraus, anstatt sie bei jeder Anfrage dynamisch zu erstellen. Dabei werden die Seiteninhalte während der Build-Zeit gerendert, typischerweise mit Tools wie Gatsby oder Hugo, die im JAMStack-Kontext weit verbreitet sind. Einige CMS, wie z.B. FirstSpirit von Crownpeak, können statische Seiten direkt generieren.

Was bedeutet CSR und SSR?

CSR (Client-Side Rendering) und SSR (Server-Side Rendering) sind zwei weitere Ansätze, wie man Webseiten aufbauen und ausliefern kann.

CSR ist ein Rendering-Ansatz, bei dem der Großteil der Verarbeitung und das Rendern von Webseiteninhalten im Browser des Nutzers erfolgt. Bei CSR wird zunächst eine minimalistische HTML-Seite mit eingebundenen JavaScript-Dateien vom Server an den Client gesendet. Diese JavaScript-Dateien, oft in Form von Frameworks wie React, Angular oder Vue.js, sind dafür verantwortlich, zusätzliche Daten vom Server zu holen, den DOM zu manipulieren und die endgültigen Inhalte der Seite zu rendern. Während der initiale Seitenaufbau bei CSR möglicherweise länger dauert, weil JavaScript und weitere Ressourcen erst geladen und ausgeführt werden müssen, bietet dieses Modell eine hohe Flexibilität und Interaktivität, sobald die Seite einmal im Browser gerendert ist. Inhalte können dynamisch aktualisiert werden, ohne die gesamte Seite neu zu laden. CSR ist besonders geeignet für Single-Page-Applications (SPAs), bei denen schnelle und reaktionsfähige Benutzerschnittstellen erforderlich sind. Jedoch können initiale Ladezeiten und SEO-Nachteile gegenüber Server-Side Rendering (SSR) oder SSG bestehen.

SSR ist ein Rendering-Ansatz, bei dem eine Webseite auf dem Server generiert und als vollständig gerenderte HTML-Seite an den Client (Browser) gesendet wird. Im Gegensatz zu clientseitigem Rendering, bei dem JavaScript im Browser die Inhalte dynamisch lädt und rendert, verarbeitet SSR alle notwendigen Datenabrufe, Template-Renderings und weitere serverseitige Logiken, bevor die Seite an den Client gesendet wird. Das bedeutet, dass der Nutzer bereits bei der ersten Anfrage eine vollständig gerenderte Seite erhält, was die initiale Ladezeit und die Suchmaschinenoptimierung (SEO) verbessert. Frameworks wie Next.js für React oder Nuxt.js für Vue.js bieten integrierte Unterstützung für SSR, indem sie es ermöglichen, dass bestimmte Komponenten oder ganze Seiten auf dem Server gerendert werden. SSR eignet sich besonders für interaktive Webseiten und Webanwendungen, bei denen der Inhalt dynamisch ist und zusätzlich eine gute Suchmaschinentauglichkeit (SEO) erforderlich ist.