Statischer Output
Jede veröffentlichte Seite liegt als vollständige HTML-Datei vor und kann direkt vom Webserver ausgeliefert werden.
Performance als Architekturentscheidung
Gute Performance ist keine nachträgliche Reparatur. Sie beginnt bei der Architektur.
Viele Websites werden zunächst mit einem umfangreichen Theme, einem CMS und zahlreichen Erweiterungen aufgebaut. Anschließend versucht man, die entstandene Komplexität mit Caching-, Minifizierungs- und Optimierungslösungen wieder auszugleichen.
Webruhe beginnt auf der anderen Seite: mit einer möglichst schlanken Architektur, wenigen begründeten Abhängigkeiten, optimierten Bildern und nur dem Code, der tatsächlich benötigt wird.
Technische Grundlage
Der kürzeste Weg vom Server zum sichtbaren Inhalt
Eine schnelle Website liefert nur aus, was die jeweilige Seite tatsächlich benötigt. Jede zusätzliche Laufzeitschicht und jede externe Verbindung braucht einen begründeten Nutzen.
Keine Datenbank im normalen Seitenaufruf
Der sichtbare Inhalt muss nicht bei jedem Besuch aus Datenbank, CMS, Theme und Erweiterungen zusammengesetzt werden.
Minimales CSS und JavaScript
Gestaltung nutzt native Webtechniken. JavaScript wird nur eingesetzt, wenn eine Funktion es wirklich benötigt.
Systemschriften oder lokal bereitgestellte Webfonts
Schriften werden ohne unnötige externe Verbindung gewählt und ausgeliefert. Das reduziert Abhängigkeiten und zusätzliche Datenschutzfragen.
Bilder ohne unnötige Last
Passende Datei, passende Größe, reservierter Platz
Bilder sind häufig die größten sichtbaren Dateien. Format, Abmessung und Ladezeitpunkt werden deshalb für den jeweiligen Einsatz festgelegt.
AVIF und WebP
Geeignete Fotos und Grafiken werden in modernen Formaten und mit einer sinnvollen Fallback-Strategie ausgeliefert.
Responsive Bildgrößen
Kleine Bildschirme laden nicht automatisch dieselbe große Datei wie breite Desktopansichten.
Feste Abmessungen
Breite und Höhe oder ein stabiles Seitenverhältnis reservieren den Platz, bevor die Bilddatei geladen ist.
Lazy Loading unterhalb des sichtbaren Bereichs
Später sichtbare Medien können verzögert laden; wichtige Hero-Inhalte erhalten dagegen die richtige Priorität.
CLS vermeiden
Bilder, Schriften, Banner und dynamische Inhalte dürfen die bereits sichtbare Seite nicht unnötig verschieben.
Optimierte SVG-Grafiken
Logos und einfache Illustrationen bleiben skalierbar und werden ohne unnötige Metadaten oder komplexe Pfade ausgeliefert.
Technischer Vergleich
Weniger Laufzeit, weniger Übertragung, weniger Fehlerquellen
Der Vergleich beschreibt typische Architekturunterschiede. Er enthält keine erfundenen Messwerte für konkrete Fremdprojekte.
| Kriterium | Klassische überladene Website | Schlanke Webruhe-Website |
|---|---|---|
| Seitenaufbau | CMS, Theme und Erweiterungen erzeugen die Seite zur Laufzeit | Fertiges HTML wird direkt ausgeliefert |
| Datenbank | Kann für jeden normalen Seitenaufruf benötigt werden | Für den normalen Seitenaufruf nicht erforderlich |
| CSS und JavaScript | Häufig mehrere globale Dateien aus Theme und Erweiterungen | Auf notwendige Gestaltung und Funktionen begrenzt |
| Schriftarten | Möglicherweise externe Anbieter und zusätzliche Verbindungen | Systemschriften oder lokal bereitgestellte Webfonts |
| Bilder | Oft eine große Datei für alle Bildschirmgrößen | Passende Formate, Größen und feste Abmessungen |
| Caching | Kompensiert teilweise eine komplexe Laufzeit | Unterstützt die bereits direkte statische Auslieferung |
Messen und einordnen
Core Web Vitals und reale Seitennutzung gehören zusammen
Lighthouse und PageSpeed Insights helfen bei der technischen Diagnose. Entscheidend bleibt, wie zuverlässig der wichtigste Inhalt unter realistischen Bedingungen sichtbar und bedienbar wird.
- Cache-Header für statische Dateien
- Largest Contentful Paint und sichtbarer Hauptinhalt
- Interaction to Next Paint bei interaktiven Funktionen
- Cumulative Layout Shift und stabile Flächen
- mobile Lighthouse-Prüfung
- PageSpeed Insights und vorhandene Felddaten
- Netzwerkanfragen und Dateigrößen
- Tastaturbedienung und mobile Nutzbarkeit
Externe Dienste
Jede Einbindung hat einen Preis
Karten, Videos, Terminbuchungen, Chats, Analyse- oder Marketingdienste können zusätzliche Verbindungen, Skripte und Datenschutzanforderungen verursachen. Ihr geschäftlicher Nutzen wird gegen Ladezeit und Komplexität abgewogen.
Realistisches Ziel
Hohe mobile Performance als Entwicklungsziel
Die Architektur wird von Beginn an auf hohe mobile Performance ausgelegt. Testumgebung, Hosting, externe Dienste und später hinzugefügte Inhalte können Messwerte beeinflussen; eine feste Dauer-Garantie wäre deshalb nicht seriös.
Codequalität und Abhängigkeiten prüfenNächster Schritt
Soll Performance Teil der neuen Website sein?
Ich kläre mit Ihnen früh, welche Funktionen und Dienste wirklich benötigt werden und welche technische Last dadurch gar nicht erst entsteht.