Ein Portal hinter der Anmeldung hat ein Messproblem, das mit seiner Technik wenig zu tun hat: Der öffentliche Felddatensatz, aus dem sich sonst fast jede Diskussion über Ladezeit speist, kennt diese Seiten nicht. Er nimmt nur auf, was auch eine Suchmaschine erreichen könnte. Alles, was erst nach dem Einloggen entsteht, fällt strukturell heraus. Gleichzeitig greift dort kein Vollseiten-Cache, weil jede Antwort an eine Sitzung gebunden ist. Wer Tempo in einem SaaS-Produkt oder einem Kundenportal steuern will, muss die Zahlen also selbst erzeugen. Dieser Beitrag zeigt, welche Kennzahlen im angemeldeten Bereich tragen, wie eine eigene Erhebung aufgesetzt wird und warum lange Tabellen und stundenlange Sitzungen andere Grenzwerte brauchen als eine Startseite.
Das Wichtigste in Kürze
- Der öffentliche Felddatensatz nimmt eine Seite nur auf, wenn sie öffentlich auffindbar ist und genug Besucher hat; für einen Ursprung nennt die Dokumentation zwei Voraussetzungen (Chrome UX Report). Hinter einer Anmeldung ist in der Regel keine davon erfüllt.
- Die Schwellen selbst bleiben gültig: 2,5 Sekunden für den größten Inhaltsaufbau, 200 Millisekunden für die Reaktionszeit auf Eingaben, 0,1 für die Layoutverschiebung, jeweils am 75. Perzentil (web.dev). Nur die Datenquelle fehlt.
- Der Ersatz ist eine eigene Erhebung im Produkt: Kennzahlen je Ansichtstyp erfassen statt je Adresse, weil Portal-Adressen Mandanten-, Vorgangs- und Datensatznummern enthalten.
- Lange Tabellen treffen die Knotenzahl: Der Prüfpunkt zur DOM-Größe warnte bis Lighthouse 12 ab rund 800 Knoten im Body und meldete ab rund 1.400 Knoten einen Fehler (Lighthouse). Seit Lighthouse 13 vom Oktober 2025 steht an seiner Stelle eine Einsicht zur DOM-Größe ohne veröffentlichte Knotenzahlen; als Größenordnung bleiben die beiden Werte brauchbar.
- Unterseiten tragen mehr JavaScript als Startseiten - im Median einer mobilen Messung 660 KB gegenüber 632 KB (Web Almanac 2025). Im angemeldeten Bereich liegt der Hebel deshalb bei der Laufzeit, nicht bei den Bildern.
- Ein Budget je Ansichtstyp macht die Messung abnahmefähig: Listenansicht, Detailansicht, Formular und Bericht bekommen eigene Grenzwerte statt eines Werts für das ganze Portal.
Warum hinter der Anmeldung keine Felddaten liegen
Der Felddatensatz, auf den sich Berichte und Werkzeuge stützen, sammelt Messwerte aus echten Browsersitzungen. Aufgenommen wird ein Ursprung aber nur, wenn er zwei Voraussetzungen erfüllt (Chrome UX Report): Er muss öffentlich auffindbar sein und genügend Besucher haben. Für die Auffindbarkeit gelten dabei dieselben Kriterien wie bei einer Suchmaschine. Eine Ansicht, die erst nach dem Einloggen entsteht, erfüllt das nicht - unabhängig davon, wie viele Menschen sie täglich benutzen. Der Unterschied zwischen Felddaten und eigener Messung entscheidet im Portal deshalb nicht über die Genauigkeit, sondern darüber, ob überhaupt Zahlen vorliegen.
Die Dokumentation nennt drei Zustände, in denen eine Seite als nicht öffentlich auffindbar gilt: eine Antwort mit einem anderen Status als 200 nach allen Weiterleitungen, ein Robots-Kopf mit dem Wert noindex oder ein Robots-Meta-Tag mit demselben Wert im Dokument. Genau diese drei Zustände sind in einem Portal die Regel: Der Aufruf ohne Sitzung endet auf der Anmeldemaske, und der angemeldete Bereich trägt aus gutem Grund ein noindex. Für SaaS-Anwendungen heißt das, dass der öffentliche Teil - Startseite, Preise, Dokumentation - im Datensatz auftaucht, während das Produkt selbst leer bleibt.
Was das für die Priorisierung bedeutet
Welche Schwellen trotzdem gelten
Dass die Datenquelle fehlt, ändert an den Zielwerten nichts. Für einen guten Eindruck soll der größte Inhaltsaufbau innerhalb von 2,5 Sekunden nach dem Ladebeginn stattfinden, die Reaktionszeit auf Eingaben bei 200 Millisekunden oder darunter liegen und die Layoutverschiebung 0,1 oder weniger betragen (web.dev). Das sind Schwellen für die Bewertung, keine Messwerte - sie gelten unabhängig davon, wer misst.
Wichtiger als die Schwelle ist die Regel dahinter: Empfohlen wird, das 75. Perzentil der Seitenaufrufe zu betrachten, getrennt nach mobilen und stationären Geräten (web.dev). Ein Mittelwert verdeckt genau die Sitzungen, um die es geht - das Konto mit 4.000 Positionen in der Liste, das Tablet im Lager, die Verbindung im Außendienst. Wer die Core Web Vitals ins Portal übernimmt, übernimmt also nicht nur die Zahlen, sondern auch die Art der Auswertung.
Der Unterschied zwischen einer öffentlichen Seite und einem angemeldeten Bereich betrifft weniger die Kennzahl selbst als ihre Bezugsgröße. Die folgende Gegenüberstellung zeigt, was sich verschiebt.
| Kennzahl oder Größe | Öffentliche Seite | Angemeldeter Bereich |
|---|---|---|
| Datenquelle | aggregierter Felddatensatz des Browsers | eigene Erhebung im Produkt |
| Bezugsgröße | Ursprung und einzelne Adresse | Ansichtstyp, Rolle und Größenklasse |
| Seitenaufbau | erste Auslieferung, oft aus dem Cache | Antwort je Sitzung, kein Vollseiten-Cache |
| Reaktionszeit | wenige Interaktionen je Aufruf | hunderte Interaktionen je Sitzung |
| Layoutstabilität | Bilder, Banner, Einwilligungsschicht | nachgeladene Tabellenzeilen und Filter |
| Zeitraum | rollierendes Fenster des Anbieters | eigenes Fenster, an Releases ausgerichtet |
Eine Besonderheit kommt hinzu: Viele Portale wechseln die Ansicht ohne vollständigen Seitenaufbau. Die Dokumentation des Datensatzes beschreibt das ausdrücklich - solche Routenwechsel wirken für den Anwender wie neue Seitenaufrufe, für den Browser und die zugrunde liegenden Schnittstellen gehört die gesamte Nutzung zum ersten Aufruf (Chrome UX Report). Wie sich Soft Navigations messen lassen, ist im Portal deshalb keine Feinheit, sondern die Voraussetzung dafür, dass die zweite und dritte Ansicht überhaupt Werte bekommen.
Die eigene Erhebung im angemeldeten Bereich
Die Erhebung beginnt mit einer Entscheidung, die sich später kaum korrigieren lässt: Wonach wird gruppiert? Portal-Adressen enthalten Mandanten-, Vorgangs- und Datensatznummern; wer nach Adresse gruppiert, bekommt tausende Gruppen mit je einem Messwert. Tragfähig ist die Gruppierung nach Ansichtstyp - Listenansicht, Detailansicht, Formular, Bericht -, ergänzt um die Rolle und, wo relevant, die Größenklasse des Mandanten. Das ist zugleich der datensparsame Weg: Was die Messung ohne Einwilligung zulässt, hängt maßgeblich davon ab, wie wenig eine Erhebung über die einzelne Person aussagt.
// Messwerte je Ansichtstyp erfassen, nicht je Adresse
const ansicht = () => ({
typ: document.body.dataset.ansichtstyp, // liste | detail | formular | bericht
rolle: document.body.dataset.rolle,
zeilen: Number(document.body.dataset.zeilen || 0)
});
const puffer = [];
const merken = (name, wert) =>
puffer.push({ name, wert: Math.round(wert), ...ansicht() });
function auswerten(typ, eintrag) {
if (typ === 'largest-contentful-paint') merken('lcp', eintrag.startTime);
if (typ === 'event' && eintrag.interactionId) merken('inp', eintrag.duration);
if (typ === 'long-animation-frame') merken('laf', eintrag.duration);
}
const beobachten = (typ, zusatz = {}) => {
new PerformanceObserver((liste) => {
for (const eintrag of liste.getEntries()) auswerten(typ, eintrag);
}).observe({ type: typ, buffered: true, ...zusatz });
};
beobachten('largest-contentful-paint');
beobachten('event', { durationThreshold: 40 });
beobachten('long-animation-frame');
// Beim Verlassen der Ansicht gebündelt senden
addEventListener('visibilitychange', () => {
if (document.visibilityState !== 'hidden' || puffer.length === 0) return;
navigator.sendBeacon('/api/rum', JSON.stringify(puffer.splice(0)));
});Der Versand gehört an das Ende einer Ansicht, nicht in ihre Mitte. sendBeacon liefert beim Verlassen, ohne den Wechsel aufzuhalten; für regelmäßige Zwischenstände gibt es inzwischen einen Weg, Messdaten verzögert zu senden, der ohne eigenen Zeitgeber auskommt. In beiden Fällen gilt derselbe Grundsatz: Die Erhebung darf die Kennzahl, die sie erhebt, nicht selbst verschlechtern.
Ansichtstyp statt Adresse
Listenansicht, Detailansicht, Formular und Bericht verhalten sich technisch verschieden. Erst diese Gruppierung macht aus tausenden Einzelwerten eine Verteilung, die sich lesen lässt.
Datenmenge je Aufruf
Zeilenzahl, Spaltenzahl und Filterstand gehören zu jedem Messwert. Ohne sie lässt sich später nicht unterscheiden, ob eine Ansicht langsam ist oder nur ein Mandant groß.
Alter der Sitzung
Wie lange der Tab bereits offen ist, erklärt einen Teil der Reaktionszeiten. Der Wert kostet nichts und trennt den frischen Aufruf von der Ansicht, die seit Stunden im selben Tab lebt.
Reaktionszeit je Bedienung
Sortieren, Filtern, Aufklappen: Im Portal entstehen hunderte Interaktionen je Sitzung. Erst ihre Verteilung zeigt, welche Bedienung teuer ist und wie oft sie vorkommt.
Anteil des Servers
Ein Zeitstempel aus der Anwendung im Antwortkopf trennt Wartezeit im Backend von Arbeit im Browser. Ohne diese Trennung wird erfahrungsgemäß an der falschen Stelle optimiert.
Knoten und Speicher
Knotenzahl im Body und belegter Speicher gehören mitgeschrieben. Beide wachsen im Betrieb, ohne dass sich eine Zeile Code ändert.
Die Reihenfolge, die sich bewährt hat
Lange Tabellen und die Knotenzahl
Portale zeigen Listen, und Listen wachsen mit dem Konto. Der Prüfpunkt zur DOM-Größe warnte bis Lighthouse 12, wenn das Body-Element mehr als rund 800 Knoten enthielt, und meldete ab mehr als rund 1.400 Knoten einen Fehler (Lighthouse); seit Lighthouse 13 vom Oktober 2025 ist er durch eine Einsicht zur DOM-Größe ersetzt, für die keine Knotenzahlen veröffentlicht sind. Als Größenordnung bleiben die Werte brauchbar: Eine Tabelle mit 200 Zeilen und zwölf Spalten liegt bei 2.400 Zellen, bevor Kopfzeile, Bedienelemente und Umrandung dazukommen. Diese Größenordnung ist damit in der Regel schon auf der ersten Ergebnisseite überschritten.
Zum Vergleich: Über die mobil gemessenen Seiten hinweg ist die mittlere Zahl der Elemente je Seite von 653 im Jahr 2022 auf 594 im Jahr 2024 gesunken, das 90. Perzentil von 1.832 auf 1.716 (Web Almanac 2024). Eine Portalansicht mit 2.400 Zellen liegt also deutlich über dem, was auf öffentlichen Seiten im 90. Perzentil gemessen wird. Wie sich die DOM-Größe reduzieren lässt, ist im Portal deshalb kein Randthema - und weil viele Zeilen erst aus angebundenen Fremdsystemen entstehen, entscheidet sich die Knotenzahl oft schon im Backend.
- Nur den sichtbaren Ausschnitt in den Baum hängen und beim Scrollen austauschen; die Zeilenhöhe vorher festlegen, damit die Bildlaufleiste ruhig bleibt.
- Zellen ohne eigenes Verhalten als Text ausgeben statt als verschachtelte Elemente mit Symbol, Hinweisfeld und Menü.
- Aktionen je Zeile über einen gemeinsamen Zuhörer an der Tabelle abwickeln statt über einen Zuhörer je Zeile.
- Ausklappbare Bereiche erst beim Öffnen füllen; ein zugeklappter Bereich mit 40 Feldern zählt sonst voll mit.
- Bei sehr langen Listen
content-visibilityprüfen, damit der Browser Bereiche außerhalb des Sichtfelds überspringen darf.
Die Zahl, die im Test fehlt
Dauerlaufsitzungen brauchen andere Grenzwerte
Eine öffentliche Seite wird aufgerufen, gelesen und verlassen. Ein Portal bleibt geöffnet - über den Vormittag, oft über den ganzen Arbeitstag. Damit verschiebt sich das Gewicht: Der erste Seitenaufbau geschieht einmal, die Reaktionszeit hunderte Male. Speicher, der bei einem einzelnen Aufruf unbemerkt bleibt, summiert sich über Stunden; wie Speicherlecks im Frontend entstehen, ist im angemeldeten Bereich deshalb eine Betriebsfrage und keine Randnotiz.
Auch die Zusammensetzung der übertragenen Daten verschiebt sich. Im Median einer mobilen Messung entfielen auf Unterseiten 660 KB JavaScript gegenüber 632 KB auf Startseiten, während Startseiten im Mittel rund 45,8 Prozent mehr Bytes anfordern als Unterseiten (Web Almanac 2025). Für ein Portal heißt das: Das Gesamtgewicht sinkt, die Skriptmenge nicht - der Hebel liegt bei der Laufzeit des Codes. Und weil jede Antwort an eine Sitzung gebunden ist, greift kein Vollseiten-Cache; welche Ebenen dann noch übrig bleiben, zeigt der Blick darauf, wie sich Cache-Schichten in einem redaktionellen System staffeln lassen.
{
"budget_je_ansichtstyp": [
{ "ansicht": "liste", "zeilen_bis": 200, "ttfb_ms": 400, "inp_ms": 200, "knoten_max": 1400 },
{ "ansicht": "liste", "zeilen_bis": 2000, "ttfb_ms": 600, "inp_ms": 200, "knoten_max": 1400 },
{ "ansicht": "detail", "zeilen_bis": 0, "ttfb_ms": 400, "inp_ms": 200, "knoten_max": 800 },
{ "ansicht": "formular", "zeilen_bis": 0, "ttfb_ms": 400, "inp_ms": 150, "knoten_max": 800 },
{ "ansicht": "bericht", "zeilen_bis": 0, "ttfb_ms": 900, "inp_ms": 200, "knoten_max": 800 }
],
"perzentil": 75,
"fenster_tage": 30,
"getrennt_nach": ["geraeteklasse", "rolle", "groessenklasse"],
"sitzung": { "speicher_mb_max": 250, "laufzeit_stunden": 8 }
}Vom Messwert zur Abnahme
Eine Messung wird erst dann zum Werkzeug, wenn jemand daran etwas ablesen kann, das eine Entscheidung trägt. Für B2B-Portale heißt das in der Regel: ein Budget je Ansichtstyp, ein Perzentil statt eines Mittelwerts und eine Größenklasse, für die der Wert gilt. Liegt der Schwerpunkt im Backend, führt der Weg über die Server-Optimierung; liegt er im Browser, über die Laufzeit des Codes. Welcher Fall vorliegt, entscheidet die Aufteilung zwischen Wartezeit und Arbeit - und die steht in den Daten, sobald der Serveranteil mitgeschrieben wird.
- Ansichtstypen benennen und im Markup kennzeichnen, damit jeder Messwert eine Gruppe hat.
- Erhebung ausrollen und zwei Wochen laufen lassen, bevor etwas geändert wird - ohne Ausgangswert gibt es später keinen Nachweis.
- Je Ansichtstyp das 75. Perzentil bilden, getrennt nach mobilen und stationären Geräten.
- Budgets festlegen, die zur Größenklasse des Kontos passen, und sie in die Abnahme schreiben statt in ein Protokoll.
- Bei jeder Auslieferung gegen das Budget prüfen und den Vergleich zum Vorlauf mitschreiben.
Der häufigste Befund in solchen Erhebungen ist keine einzelne langsame Seite, sondern eine Bedienung, die oft benutzt wird und knapp über der Schwelle liegt. Wie sich die Reaktionszeit auf Eingaben verbessern lässt, ist im Portal deshalb meist der Punkt mit dem größten Ertrag je Aufwand - deutlich vor dem ersten Seitenaufbau, den ein Anwender einmal am Tag erlebt.
Hinter der Anmeldung gibt es keine fremde Zahl, gegen die man sich vergleichen könnte. Es gibt nur die eigene Messung - und die ist so viel wert wie die Gruppierung, mit der sie erhoben wurde.
Der Aufwand für den Aufbau ist überschaubar: Ansichtstypen kennzeichnen, drei Beobachter registrieren, einen eigenen Endpunkt bereitstellen. Der eigentliche Teil ist die Auswertung - und sie lohnt sich dort, wo hunderte Menschen täglich mit derselben Liste arbeiten. Wenn Sie den Einstieg abkürzen möchten: In einer Performance-Analyse nehmen wir die Ansichten einzeln auf und legen die Budgets gemeinsam mit Ihrem Team fest.
noindex trägt, erfüllt das nicht - unabhängig davon, wie oft sie benutzt wird.Verwandte Artikel
Vorlage statt Startseite: wo die Ladezeit wirklich entsteht
Optimiert wird die Startseite, angesteuert werden Kategorie-, Produkt- und Artikelseiten. Wie Sie nach Vorlagen messen und die Reihenfolge belegen.
Performance-Messung ohne Einwilligung: was zulässig ist
§ 25 TDDDG greift vor der DSGVO: wann eine Vitals-Messung als Zugriff auf das Endgerät gilt, wie eng die Ausnahme ist und was ohne Einwilligung messbar bleibt.
Speicherlecks im Frontend: wenn die Seite träge wird
Die Oberfläche startet schnell und wird nach zwanzig Minuten zäh: wie Speicherlecks im Frontend entstehen, wie man sie im Verlauf misst und wieder loswird.