Single-Page-App oder mehrseitige Website.
Einmal navigiert die Anwendung, einmal der Browser; seit dokumentübergreifenden Übergängen stimmt „für weiche Übergänge braucht es eine App“ nicht mehr.
Ein Jahrzehnt lang hatte dieser Vergleich eine klare Antwort: wer weiche Übergänge, erhaltenen Zustand und schnelle Seitenwechsel wollte, schrieb eine Anwendung. Die technische Annahme hinter dieser Antwort hat sich geändert. Der Browser kann inzwischen zwischen zwei getrennten Dokumenten animieren, und eine Zeile CSS genügt, um es zu verlangen. Der Vergleich ist damit wieder offen.
Was die Anwendung übernimmt
Eine Single-Page-App übernimmt eine Aufgabe des Browsers: die Navigation. Übernommen wird mehr als der Inhaltswechsel — wohin geht der Fokus, wie lautet der Seitentitel, was wird einem Screenreader angekündigt, was tut die Zurück-Taste, wird die Scrollposition wiederhergestellt? All das wird geschrieben und geprüft. Dafür gibt es einen echten Gewinn: der Zustand bleibt im Speicher. Ein halb ausgefülltes Formular, ein laufender Player oder eine geöffnete Karte überleben die Navigation.
Wo die mehrseitige Seite heute steht
Auf einer mehrseitigen Website ist jede Adresse ein eigenes Dokument, und es navigiert der Browser. Neu ist, dass diese Navigation auch visuell durchgehend sein kann: ein dokumentübergreifender Übergang animiert zwischen dem letzten Bild der alten und dem ersten Bild der neuen Seite. Der Übergang steht in CSS, JavaScript ist nicht nötig, und in einer Engine ohne Unterstützung verläuft die Navigation einfach ohne Animation.
Der zweite Unterschied liegt in der Messung: auf einer mehrseitigen Website ist jede Navigation ein eigener Seitenaufruf, Felddaten werden also je Adresse gesammelt. In einer Single-Page-App fallen weiche Navigationen aus den heutigen Metriken heraus; gemessen wird meist das erste Laden.
Eine Messfalle: der Laborbrowser ist nicht der echte
Beim Messen einer Seite mit dokumentübergreifenden Übergängen ist Vorsicht geboten: der Browser, den ein Laborwerkzeug startet, läuft nicht mit denselben Flags wie der einer Besucherin, und dieser Unterschied kann das erste Bild um Sekunden verzögern. Genau das haben wir auf dieser Website gemessen; die Einzelheiten stehen in einem eigenen Beitrag: warum Lighthouse 87 sagt und echtes Chrome 98. Bei der Entscheidung sollte ein Laborwert nicht der einzige Beleg sein — Felddaten und eine Messung im echten Browser gehören dazu.
Wie man entscheidet
Die Frage lautet nicht „was ist modern“, sondern „wo lebt der Zustand“. Trägt eine Besucherin Zustand durch die Sitzung — ein Dokument in Bearbeitung, ein langes Formular, einen offenen Player —, erleichtert die Anwendungsseite die Arbeit. Werden Seiten unabhängig voneinander gelesen, schenkt die mehrseitige Seite weniger Code, eine engere Fehlerfläche und das eingebaute Verhalten des Browsers. Diese Website gehört zur zweiten Gruppe und richtet ihren Übergang ohne Anwendung ein.
Kriterium
- Erster Bildschirm — Single-Page-App: Nichts erscheint, bevor das App-Bundle geladen und ausgeführt ist (außer bei Server-Vorab-Rendering) · Mehrseitige Website (+ dokumentübergreifender Übergang): Das HTML vom Server ist im ersten Bild sichtbar
- Kosten einer Navigation — Single-Page-App: Nach dem ersten Laden nur noch Daten · Mehrseitige Website (+ dokumentübergreifender Übergang): Ein Dokument je Navigation; Cache und Prefetch entscheiden
- Navigationsanimation — Single-Page-App: Im Anwendungscode, über Router und Animationsschicht · Mehrseitige Website (+ dokumentübergreifender Übergang): In CSS mit `@view-transition`; kein Anwendungscode nötig
- Zustand — Single-Page-App: Bleibt im Speicher: Formulare, Player, Scrollposition · Mehrseitige Website (+ dokumentübergreifender Übergang): Das Dokument wechselt; Zustand wird bewusst mitgenommen (URL, Speicher, Server)
- Fokus, Titel, Vor/Zurück — Single-Page-App: Von Hand geführt: Fokus setzen, Titel schreiben, Wechsel ankündigen · Mehrseitige Website (+ dokumentübergreifender Übergang): Übernimmt der Browser; Anker und Vor/Zurück sind eingebaut
- Suchmaschinen und Agenten — Single-Page-App: Wird der Inhalt im Client erzeugt, ist ein zusätzlicher Crawling-Schritt nötig · Mehrseitige Website (+ dokumentübergreifender Übergang): Jede Adresse trägt ihr eigenes HTML
- Fehlerfläche — Single-Page-App: Ein einziger JavaScript-Fehler kann die gesamte Navigation anhalten · Mehrseitige Website (+ dokumentübergreifender Übergang): Ein Fehler bleibt auf der Seite; die Navigation gehört dem Browser
- Messung — Single-Page-App: Weiche Navigationen fallen aus den heutigen Felddaten heraus; gemessen wird das erste Laden · Mehrseitige Website (+ dokumentübergreifender Übergang): Jede Navigation ist ein eigener Seitenaufruf; Laborwerkzeuge messen dokumentübergreifende Übergänge womöglich anders als ein echter Browser
- Wo es passt — Single-Page-App: Oberflächen, die Zustand durch eine Sitzung tragen: Dashboards, Editoren, Karten, Spiele · Mehrseitige Website (+ dokumentübergreifender Übergang): Inhaltsflächen: Publikationen, Dokumentation, Portfolios, Firmenwebsites
HÄUFIGE FRAGEN
Gibt es dokumentübergreifende Übergänge in jedem Browser?
Nein, und wo es sie nicht gibt, bricht nichts: die Regel ist Opt-in, und in einer Engine ohne Unterstützung verläuft die Navigation nur ohne Animation. Inhalt, Adressen sowie Vor und Zurück verhalten sich gleich.
Ist die Navigation auf einer mehrseitigen Website nicht langsam?
Das hängt von der Messung ab. Kommt das HTML aus einem Edge-Cache oder aus einem Prefetch, kostet eine Navigation einen Dokument-Download; auf dieser Website liegt der schlechteste gemessene echte LCP bei 476 Millisekunden. Langsamkeit entsteht durch verfehlten Cache und schwere Seiten, nicht durch die Architektur.
Ist eine Single-Page-App schlecht für die Suche?
Nicht schlecht, sondern teuer: wird der Inhalt im Client erzeugt, muss die lesende Seite einen zusätzlichen Schritt gehen, und dass dieser Schritt in jeder Engine gleich ausfällt, lässt sich nicht voraussetzen. Eine serverseitig vorgerenderte Anwendung schließt die Lücke weitgehend — doch dann ist die Architektur bereits eine Mischung aus beiden.