Schnell geladen, langsam bedient
Die Startseite öffnet schnell. Doch sobald man einen Auftrag sucht, einen Filter setzt oder eine Detailansicht öffnet, beginnt das Warten. Wer täglich damit arbeitet, wird sich kaum mit einem grünen Messwert für den ersten Seitenaufruf zufriedengeben.
Für mich ist das ein häufiger Denkfehler bei der Abnahme: Wir prüfen den Eingang zur Anwendung, aber nicht den Weg durch die eigentliche Arbeit. Das folgende Kundenportal ist ein fiktives Beispiel, kein Messergebnis einer TNSystem-Anwendung.
Neuer Blick auf Ansichtswechsel
Google hat den Chrome UX Report am 13. Oktober 2026 um experimentelle Varianten der Core Web Vitals ergänzt, die auch Soft Navigations berücksichtigen. Gemeint sind Ansichtswechsel ohne vollständiges Neuladen des Dokuments. [1]
Die Ergänzungen ersetzen die stabilen Kennzahlen vorerst nicht. Google führt sie parallel zur Bewertung ein. Aus der Ankündigung folgt also weder eine neue allgemeine Ranking-Regel noch automatisch ein besserer Wert für jede Website. [2]
Reaktion und fertiges Ergebnis auseinanderhalten
Eine Schaltfläche sollte erkennen lassen, dass eine Eingabe angekommen ist. Das ist aber noch nicht gleichbedeutend mit einem abgeschlossenen Suchlauf. Die Kennzahl INP betrachtet die Reaktionsfähigkeit bis zur nächsten Darstellung und nicht die gesamte Dauer aller nachfolgenden Netzwerk- und Verarbeitungsschritte. [3]
Ich würde deshalb zwei Fragen getrennt stellen: Bekommt der Nutzer zügig eine Rückmeldung? Und wann liegt das benötigte Ergebnis tatsächlich vor? Ein sofort sichtbarer Ladehinweis kann Unsicherheit reduzieren, behebt aber keine langsame Datenabfrage.
Einen echten Arbeitsweg prüfen
Für unser Beispiel würde ich einen einfachen Ablauf festlegen: anmelden, Auftrag suchen, nach Status filtern, einen Treffer öffnen und zur Liste zurückkehren. Die Prüfung sollte Datenmengen enthalten, die zum späteren Alltag passen. Eine leere Testliste beantwortet eine andere Frage als eine gefüllte Auftragsverwaltung.
Ebenso würde ich Geräte und Verbindung bewusst auswählen. Ein schneller Entwicklungsrechner ist ein nützlicher Prüfplatz, aber nicht automatisch ein Ersatz für den älteren Bürocomputer oder ein Mobilgerät. Die Bedingungen gehören zum Ergebnis, damit Vergleiche nachvollziehbar bleiben.
Die Wartezeit der richtigen Stelle zuordnen
Bei einer langsamen Suche würde ich den Weg vom Klick über die Anfrage bis zur Darstellung nachvollziehen. Hängt die Oberfläche bereits vor dem Absenden? Wartet sie auf den Server? Oder sind die Daten angekommen und die Darstellung benötigt lange?
Erst danach würde ich eine Maßnahme auswählen. Weniger unnötig übertragene Daten, eine passendere Abfrage oder eine begrenzte Ergebnisliste können sinnvolle Ansatzpunkte sein. Ein pauschaler Austausch des Webframeworks wäre für mich noch keine Diagnose.
Nicht nur den Durchschnitt betrachten
Eine Anwendung kann die meiste Zeit angenehm funktionieren und in einzelnen wichtigen Schritten trotzdem unzumutbar langsam werden. Ich würde deshalb nicht allein einen Durchschnitt über völlig verschiedene Tätigkeiten bilden. Die Suche, das Speichern und der Export verdienen jeweils einen nachvollziehbaren Blick.
Bei Messungen gehören Datenschutz und Zugriffsrechte dazu. Für die Untersuchung würde ich technische Zeitpunkte und freigegebene Testfälle verwenden, statt ungeprüft Suchbegriffe, Kundendaten oder vollständige Formulare in Analysedienste zu übertragen. Eine Leistungsprüfung ist kein Freibrief zur Datensammlung.
Mein Fazit
Ein guter Geschwindigkeitstest sollte erklären, wie sich Arbeit anfühlt, nicht nur, wie schnell die erste Seite erscheint. Ich würde die Abnahme deshalb an typischen Aufgaben ausrichten und festhalten, unter welchen Bedingungen sie geprüft wurden.
Experimentelle Messwerte können dabei zusätzliche Hinweise liefern. Sie ersetzen weder die Untersuchung eines konkreten Engpasses noch den Vergleich vor und nach einer begründeten Änderung. Dieser Beitrag enthält keine eigenen Benchmarks oder Leistungszusagen.
Quellen und Einordnung
Recherchestand: 23. Oktober 2026. Herstellerveröffentlichungen sind keine eigenen Produktprüfungen. Beispiele und Empfehlungen sind im Text als solche eingeordnet.
[1] Google: CrUX-Datensatz September 2026, veröffentlicht am 13.10.2026
Quelle lesen ↗
[2] Google: experimentelle Soft-Navigation-Messwerte, 13.10.2026
Quelle lesen ↗
[3] Google: Interaction to Next Paint und dessen Messgrenzen
Quelle lesen ↗