Um die Performance einer Single Page Application zu bewerten, messen Sie den ersten Dokumentaufruf, spätere Routenwechsel und die Interaktionen dazwischen. Diese Nutzungserlebnisse hängen zusammen, besitzen aber unterschiedliche Grenzen. Eine schnelle Reaktion auf einen Klick beweist nicht, dass das Ziel geladen ist. Ebenso beschreibt eine gute Bewertung der Einstiegsseite nicht jede später besuchte Route.
Festlegen, was der Bericht tatsächlich misst
Eine vollständige Navigation erzeugt ein neues Dokument. Ein typischer Routenwechsel in einer SPA verändert dagegen das bestehende Dokument. Eine geänderte Adresse über die History API definiert für sich genommen nicht in jedem Browser und Berichtssystem eine neue Performancemessung.
Unterscheiden Sie dokumentbezogene Erfassung von Verfahren, die Soft Navigations ausdrücklich unterstützen. Die Unterstützung hängt von Browser, Erfassungswerkzeug und Berichtsart ab. Kennzeichnen Sie verfügbare Messwerte für Soft Navigations entsprechend, statt sie unbemerkt mit herkömmlichen Seitenaufrufen zu vermischen. Ein eigener Routentimer ist ebenfalls hilfreich, wird dadurch aber nicht automatisch zu LCP, INP oder CLS.
Googles Hinweise zur Messung von SPAs erläutern die Bedeutung des Navigationsmodells. Lesen Sie die Definition des Datensatzes Ihres Werkzeugs, bevor Sie Ergebnisse vergleichen. Eine fehlende Routenmessung bedeutet fehlende Abdeckung, nicht eine augenblicklich fertige Route.
Die Einstiegsroute gesondert untersuchen
Öffnen Sie ein wichtiges Ziel direkt in einer frischen Sitzung. Beobachten Sie, wie der Browser den Hauptinhalt entdeckt, Ressourcen lädt und den für die Darstellung benötigten Code ausführt. Serverseitig gerenderte oder vorab erzeugte Inhalte können früher entdeckt werden. Die Hydrierung kann trotzdem weitere Arbeit für die Interaktivität verursachen.
Trennen Sie Netzwerkwartezeit, Ausführung und Rendering. Eine Route kann wenig herunterladen und dennoch während der JavaScriptausführung stocken. Umgekehrt hilft weniger Skriptausführung nicht gegen eine API Anfrage, die erst nach vermeidbaren Abhängigkeiten startet. Nutzen Sie die LCP Anleitung, um den Weg zum sichtbaren Inhalt zu untersuchen, statt das Ergebnis allein dem Framework zuzuschreiben.
Nutzbarkeit einer Route sinnvoll definieren
Bei einer Produktansicht könnte Bereitschaft bedeuten, dass Produktidentität, aktueller Preis und Hauptaktion verfügbar sind. Bei einem Artikel könnten Überschrift und Haupttext im Dokument ausreichen. Wählen Sie eine Definition, die zur Aufgabe der Besucher passt, und wenden Sie sie konsistent an. Ein verschwundener Ladeindikator genügt nicht, wenn die nächste Aktion weiterhin gesperrt ist.
Erfassen Sie den Start an dem Routerereignis, das die Navigationsabsicht des Nutzers repräsentiert. Beenden Sie die Messung erst, wenn die gewählte Bedingung erfüllt ist. Unterscheiden Sie Abbrüche, Fehler und Weiterleitungen von erfolgreichen Übergängen. Ersetzt eine spätere Navigation eine frühere, darf deren verspäteter Abschluss nicht als Ergebnis der neuen Route erscheinen.
Ein Zeitsignal der Anwendung ergänzen
Dieses Beispiel erzeugt einen Timer für einen abgeschlossenen Routenwechsel. Rufen Sie beginRouteTiming() beim Navigationsbeginn auf und führen Sie die zurückgegebene Funktion aus, sobald Ihre Bereitschaftsbedingung erfüllt ist. Nutzen Sie einen normalisierten Routennamen wie article statt einer URL mit personenbezogenen Informationen.
function beginRouteTiming(routeName) {
const id = crypto.randomUUID();
const start = `route:${id}:start`;
const end = `route:${id}:end`;
const name = `route:${id}:ready`;
performance.mark(start);
return function finishRouteTiming() {
performance.mark(end);
const result = performance.measure(name, {
start,
end,
detail: { route: routeName }
});
performance.clearMarks(start);
performance.clearMarks(end);
performance.clearMeasures(name);
return result.duration;
};
}Die zurückgegebene Dauer ist in Millisekunden angegeben. Die Hilfsfunktion misst den Abstand zwischen Anwendungssignalen. Sie prüft weder die tatsächliche Bildausgabe noch das Einhalten eines Core Web Vitals Grenzwerts. Verbinden Sie sie mit dem verwendeten Router und Renderingzyklus. Ergänzen Sie dabei die Bereinigung bei Abbrüchen und die Fehlererfassung. Eindeutige Namen trennen gleichzeitig laufende erfolgreiche Messungen; die anschließende Bereinigung verhindert, dass deren Einträge in der Zeitleiste verbleiben.
Ein Commit des Frameworks oder ein requestAnimationFrame Callback beweist nicht, dass alle nützlichen Inhalte erschienen sind. Vergleichen Sie die Signale mit einer Browseraufzeichnung und dem sichtbaren Verhalten, bevor Sie die Bedeutung der Messung festlegen.
Reaktionsfähigkeit vom Laden des Ziels trennen
INP betrachtet die Reaktion auf Nutzereingaben bis zur nächsten Bildausgabe. Ein Klick kann sofort einen Ladezustand anzeigen, obwohl das Ziel noch nicht verfügbar ist. Die Interaktion kann also schnell reagieren, während die Route langsam lädt. Bewahren Sie beide Beobachtungen, statt die gesamte Routendauer INP zu nennen.
Prüfen Sie aufwendige Ereignisbehandlung, synchrones Rendering und wiederholte Layoutberechnungen. Verschieben Sie Arbeit, die nicht zur unmittelbaren Reaktion beiträgt, und zeigen Sie einen ehrlichen Fortschrittszustand. Ist der Hauptthread nach dem Klick beschäftigt, untersuchen Sie die Aufzeichnung vor Änderungen an Netzwerkeinstellungen. Die INP Anleitung hilft, die Ursache einzugrenzen.
Benötigte Inhalte laden und die Ansicht stabil halten
Eine Aufteilung des Codes nach Routen kann unnötige Arbeit beim Einstieg reduzieren. Zusätzliche voneinander abhängige Anfragen können das Ziel jedoch verzögern. Starten Sie unabhängige Aufgaben für Code und Daten gemeinsam, wenn die Architektur dies erlaubt. Laden Sie nur gezielt vor. Spekulative Arbeit kann mit der gerade verwendeten Route konkurrieren.
Reservieren Sie Platz für Bilder und asynchron geladene Bereiche. Halten Sie die Navigation stabil und fügen Sie verspätete Inhalte nicht oberhalb des gerade gelesenen Texts ein. Ein Übergang kann störende Bewegungen enthalten, obwohl eine bestimmte Verschiebung wegen einer kürzlich erfolgten Eingabe nicht in CLS eingeht. Beurteilen Sie daher auch das sichtbare Erlebnis.
Vergleichbare Abläufe und Datensätze gegenüberstellen
Testen Sie Direkteinstieg, interne Navigation, wiederholte Navigation, Zurück und Vorwärts sowie einen Übergang mit langsamer Datenlieferung. Berücksichtigen Sie fehlgeschlagene Anfragen und abgebrochene Übergänge. Halten Sie Cachezustand und Gerätebedingungen bei Vergleichen gleich. Sonst scheint eine bereits vorbereitete Route eine Verbesserung zu belegen, die lediglich aus früherer Arbeit stammt.
Die Grenzen für eine gute Bewertung sind LCP bis einschließlich 2.5 s, INP bis einschließlich 200 ms und CLS bis einschließlich 0.1, jeweils am 75. Perzentil und getrennt nach Mobilgeräten und Desktop. Sie gelten für die definierten Core Web Vitals Messungen, nicht für beliebige Anwendungstimer. Prüfen Sie, ob ein Bericht eine URL, einen Origin, Dokumentaufrufe oder identifizierte Soft Navigations abbildet.
Ordnen Sie den Routenkontext der verursachenden Interaktion oder Navigation zu. Verwenden Sie nicht einfach die beim Telemetrieversand aktuelle URL. Beachten Sie den Unterschied zwischen Feld und Labordaten, bevor Sie eine erfolgreiche lokale Aufzeichnung auf alle Besucher übertragen. Ein nützlicher Bericht macht langsame Abläufe erkennbar und Verbesserungen überprüfbar.
