Beim Planen oder Erweitern einer Website umfasst die Architektur Layout, Inhaltsordnung, HTML-Aufbau und den Weg der Daten vom Abruf bis zur Anzeige im Browser. Diese Bereiche hängen zusammen: Eine neue Navigationskategorie kann Änderungen am Inhaltsmodell und an den Seitenvorlagen erfordern.
Planen Sie, wie Besucherinnen und Besucher Inhalte finden, wann und wo Seiten zusammengesetzt werden und wie aktuelle, sichere Daten in den Browser gelangen. Die passende Architektur hängt davon ab, wie aktuell und persönlich die Inhalte sein müssen und welche Anforderungen an Bedienbarkeit und Ladezeit gelten.
Inhalte vor Vorlagen ordnen
Beginnen Sie bei den Aufgaben Ihrer Besucherinnen und Besucher und den Inhalten, die sie dafür benötigen. Die Informationsarchitektur beschreibt, wie Sie diese Inhalte gruppieren, benennen und miteinander verknüpfen. Aus verständlichen Kategorien entsteht eine Navigation, die Menschen bei der Orientierung unterstützt.
Eine Website für einen Fachverlag könnte Bücher, Autorinnen und Autoren sowie Themen als eigene Bereiche führen. Wenn dieselbe Autorin auf mehreren Buchseiten erscheint, sollte das Inhaltsmodell, also die festgelegte Struktur der Inhalte und ihrer Beziehungen, diese Verbindung abbilden. Eine Seitenvorlage kann daraus die passenden Verknüpfungen erzeugen. Werden die Bereiche erst beim Gestalten einzelner Seiten festgelegt, entstehen leicht uneinheitliche Bezeichnungen und Inhalte, die mehrfach gepflegt werden müssen.
Prüfen Sie Kategorien anhand konkreter Nutzungssituationen: Welche Information sucht jemand, und über welchen Weg soll sie erreichbar sein? Die W3C-Initiative WAI empfiehlt, die Hauptnavigation aus nachvollziehbar geordneten Inhaltsbereichen abzuleiten und verständliche Namen zu verwenden. Eine Navigation, deren Unterschiede nur durch Farbe oder Position erkennbar sind, erschwert manchen Menschen die Orientierung.
Website-Struktur und HTML trennen
Die Gliederung einer Website und die Struktur eines einzelnen HTML-Dokuments erfüllen verschiedene Aufgaben. Die Website-Struktur ordnet Seiten und Bereiche zueinander. Das HTML-Dokument ordnet Inhalte innerhalb einer Seite, etwa durch Überschriften und semantische Bereiche.
Eine Seite kann ein optisch großes Thema zeigen, dessen HTML-Überschrift jedoch auf der falschen Ebene steht. Die visuelle Größe legt die semantische Rangfolge nicht fest. Überschriften sollen die tatsächliche Gliederung abbilden, damit Browser und assistive Technologien die Abschnitte erkennen und zur Navigation nutzen können.
Legen Sie für wiederkehrende Seitentypen fest, welche Bereiche sie enthalten und wie die Überschriften aufeinander folgen. Prüfen Sie anschließend die Gliederung unabhängig vom visuellen Design. So erkennen Sie, ob die Seite auch dann verständlich bleibt, wenn jemand sie über Überschriften oder andere unterstützende Funktionen erkundet.
HTTP-Anfragen und Datenfluss verstehen
Beim Aufruf einer URL sendet der Browser eine HTTP-Anfrage an einen Server. HTTP ist das Protokoll, nach dessen Regeln Clients wie Browser und Server Informationen anfordern und austauschen. Ein Cache, also ein Zwischenspeicher, kann eine gespeicherte Antwort zurückgeben. Andernfalls verarbeitet der Server die Anfrage weiter. Er kann Inhalte aus Datenquellen abrufen und daraus eine Antwort erstellen.
Die Antwort enthält häufig HTML, das der Browser zusammen mit weiteren Ressourcen verarbeitet. CSS-Dateien legen die Gestaltung fest, und Bilder gehören ebenfalls zu diesen Ressourcen. JavaScript ermöglicht interaktive Funktionen. Der Browser wandelt HTML in eine Dokumentstruktur um, das DOM, und erstellt aus CSS das CSSOM mit den Formatierungsregeln. Auf dieser Grundlage berechnet er die Darstellung. Dann ordnet er die Elemente auf der Seite an und zeigt die sichtbaren Inhalte. JavaScript kann die Dokumentstruktur ändern oder zusätzliche Daten anfordern.
Diese Schritte laufen teilweise parallel ab und unterscheiden sich je nach Architektur. Das allgemeine Ablaufmodell hilft dennoch bei der Fehlersuche. Wenn Inhalte spät erscheinen, prüfen Sie den Server und die Datenbankzugriffe. Untersuchen Sie auch Antwortgrößen und weitere Anfragen sowie die Verarbeitung im Browser. Eine schnelle Serverantwort führt nicht automatisch dazu, dass die Seite schnell sichtbar wird.
Rendering für Seiten wählen
Beim statischen Rendering entstehen HTML-Dateien vor dem Seitenaufruf, etwa während eines Veröffentlichungsvorgangs. Der Server liefert diese Dateien aus. Das passt gut zu Inhalten, die sich nicht für jede Anfrage unterscheiden. Änderungen werden erst sichtbar, wenn die erzeugten Dateien aktualisiert und ausgeliefert werden.
Beim serverseitigen Rendering erzeugt der Server HTML, wenn eine Anfrage eingeht. Der Browser erhält dadurch fertige Inhalte. Der Server verarbeitet dafür die Anfrage, ruft Daten ab und erzeugt die Seite. Beim clientseitigen Rendering lädt der Browser mehr JavaScript und setzt die Ansicht dort zusammen. Das eignet sich für Oberflächen mit umfangreicher Interaktion, belastet aber Geräte mit viel JavaScript-Arbeit.
Hybride Ansätze kombinieren diese Verfahren, zum Beispiel indem ein Teil der Seiten statisch entsteht und ein anderer Teil auf Anfrage gerendert wird. Bei der Hydrierung verbindet JavaScript serverseitig erzeugtes HTML mit clientseitigem Verhalten. Sichtbare Inhalte können dann schon vorhanden sein, bevor alle Interaktionen funktionieren. Streaming, bei dem der Server die Antwort schrittweise sendet, und eine schrittweise Aktivierung interaktiver Bereiche helfen, die Arbeit zu verteilen.
Wählen Sie die Rendering-Art nach Inhalt und Nutzung. Öffentliche, häufig gleiche Seiten lassen sich oft gut vorab erzeugen. Inhalte, die pro Person oder Anfrage variieren, brauchen dagegen einen passenden dynamischen Weg. Messen Sie nach der Umsetzung, ob Inhalte früh sichtbar und Interaktionen rechtzeitig bedienbar sind. Keine Rendering-Variante ist für jede Website die beste.
Sitzungen und API-Anfragen planen
HTTP führt von sich aus keinen dauerhaften Zustand zwischen zwei Anfragen. Eine Website, die einen Anmeldezustand über mehrere Seitenaufrufe hinweg erhalten soll, ergänzt deshalb Sitzungsmechanismen. Cookies können einen Wert zwischen Anfragen übertragen; der Server ordnet damit beispielsweise eine Anfrage einer Sitzung zu.
Sitzungscookies sollten mit passenden Sicherheitsmerkmalen wie Secure und HttpOnly konfiguriert werden. SameSite kann Risiken bei seitenübergreifenden Anfragen begrenzen, ersetzt aber keinen vollständigen Schutz vor Anfragen, die ungewollt im Namen einer angemeldeten Person ausgelöst werden. Planen Sie daher fest, welche Daten ein Cookie enthält und welche Prüfungen der Server zusätzlich ausführt.
Liegen Website und API auf verschiedenen Ursprüngen, zum Beispiel auf unterschiedlichen Hostnamen, greift die Same-Origin Policy des Browsers. Diese Regel begrenzt, welche Antworten JavaScript lesen darf. CORS ist ein Verfahren, mit dem ein Server den Zugriff für bestimmte Ursprünge freigibt. Bei manchen Anfragen prüft der Browser die Freigabe zuerst mit einer zusätzlichen Anfrage. CORS regelt den Zugriff über den Browser, ersetzt aber keine Berechtigungsprüfung auf dem Server.
Halten Sie für jede Datenverbindung fest, wer die Anfrage stellt, welcher Server antwortet und welche Informationen übertragen werden. Diese Skizze macht sichtbar, wo Sitzungsdaten, Zugriffskontrollen und CORS-Regeln hingehören.
HTTP-Caches und Ladezeit abstimmen
Ein HTTP-Cache speichert Antworten und gibt sie bei passenden späteren Anfragen erneut aus. Das verkürzt die Wartezeit und erspart dem Server, jede Anfrage erneut weiterzuleiten, Datenbankzugriffe auszuführen und eine Seite zu erstellen. HTTP-Header legen fest, ob und wie eine Antwort zwischengespeichert wird.
Richten Sie die Cache-Regeln nach Aktualität und Personalisierung aus. Ein öffentlicher Artikel, der sich selten ändert, eignet sich eher für eine wiederverwendbare Antwort als ein persönlicher Kontostand. Bei nutzerspezifischen Daten müssen Sie sorgfältig verhindern, dass eine gespeicherte Antwort an eine andere Person ausgeliefert wird. Entscheidend ist, welche Antwort für welche Anfrage sicher wiederverwendbar ist.
Die Core Web Vitals messen verschiedene Aspekte der Darstellung und Bedienung einer Website. Für die Bewertung zählt jeweils das 75. Perzentil, also der Wert, den 75 Prozent der Seitenaufrufe nicht überschreiten:
| Kennzahl | Gute Schwelle | Schlechte Schwelle | Erfasst |
|---|---|---|---|
| INP | höchstens 200 ms | über 500 ms | Wie schnell die Seite auf Interaktionen reagiert |
| CLS | höchstens 0,1 | über 0,25 | Wie stark sich sichtbare Inhalte unerwartet verschieben |
Diese Werte helfen, konkrete Folgen von Rendering-, Skript- und Layoutentscheidungen zu prüfen. Sie sagen allein nichts darüber aus, ob Inhalte verständlich, sicher oder leicht zu pflegen sind. Verbinden Sie Messungen deshalb mit der Untersuchung des tatsächlichen Daten- und Ressourcenflusses.
Website-Architektur planen und prüfen
Erstellen Sie zuerst eine Übersicht der Inhalte, ihrer Beziehungen und der wichtigsten Wege, auf denen Besucherinnen und Besucher die Website nutzen. Legen Sie dann fest, welche Daten öffentlich sind, welche sich je nach Person unterscheiden und wie oft sie sich ändern. Daraus ergeben sich Anforderungen an Rendering, Cache und Sitzungen. Planen Sie auch die HTML-Gliederung und Navigation, bevor Sie wiederkehrende Vorlagen und technische Bausteine festlegen.
Prüfen Sie die Architektur nach der Veröffentlichung anhand echter Seitenaufrufe und Nutzungssituationen. Ist eine Seite früh sichtbar, reagieren ihre Schaltflächen aber zunächst nicht, prüfen Sie, wann der Code im Browser aktiv wird. Erscheinen Daten veraltet, kontrollieren Sie die Cache-Regeln und den Zeitpunkt der Aktualisierung. So können Sie jede Beobachtung in eine konkrete technische Frage übersetzen.