Profilisiere eine Kundenreise, bevor du Code änderst
Wählen Sie einen wichtigen Pfad und eine Interaktion, z. B. das Öffnen der Navigation, Filtern von Ergebnissen oder Absenden eines Formulars. Zeichnen Sie die Aktion im Performance-Panel der Chrome DevTools bei sauberem Browserzustand auf. Wiederholen Sie die Aktion und erfassen Sie sowohl einen Durchlauf mit gedrosselter CPU als auch einen auf einem Entwicklungsrechner; Desktop-Traces können Arbeit verbergen, die auf einem weniger leistungsfähigen Smartphone stört.
Verwende den Trace, um eine enge Hypothese zu testen, nicht um eine Komponente allein aus einem Bundle-Bericht zu beschuldigen. Im Main-Flame-Chart zeigen breitere Balken längere Zeiten und gestapelte Balken den Call-Stack. Ein rotes Dreieck auf einer Task identifiziert eine potenzielle Long Task; wähle sie aus und folge dem Link zum initialisierenden Code. Speichere Vorher-/Nachher-Traces für aussagekräftige Änderungen.
Nimm kurz vor der Aktion auf und stoppe nach dem sichtbaren Ergebnis.
Halte Route, Account-Zustand und Aktionssequenz konsistent.
Ordnen Sie jede wesentliche Kostenstelle einer zuständigen Person im Team oder beim Anbieter zu.
Lies den Trace als Warteschlange von Arbeit
Eine Long Task ist ein Schwellenwert für die Untersuchung, aber keine vollständige Diagnose. Die W3C-Spezifikation Long Tasks erfasst Aufgaben, die 50 Millisekunden oder länger dauern. Untersuchen Sie innerhalb einer Aufgabe JavaScript-Auswertung, einen Event-Handler, Stilneuberechnung, Layout oder Paint. Der Call-Stack zeigt, wo Sie beginnen sollten; die Zeitmessung zeigt, ob das Problem im Code, beim Rendering oder in einem Drittanbieter-Frame liegt.
Priorisiere Kosten, die während einer wertvollen Interaktion wiederkehren. Ein kurzer Handler kann sich immer noch langsam anfühlen, wenn er Layout auslöst oder hinter früherer Arbeit wartet. Der Trace ist eine Labor-Messung, also bestätige die Behebung auf repräsentativen Geräten und, wo verfügbar, mit datenschutzbewusster Feldtelemetrie.
Das Parsen beim Start erfordert eine andere Maßnahme als ein Handler nach einem Tap.
Suchen Sie vor einer Refaktorisierung nach wiederholten Mustern, bei denen Stile geändert und anschließend Layoutdaten gelesen werden.
Hänge Trace, Szenario und Top-Kosten an das Arbeitspaket.
Liefer weniger Code zur relevanten Zeit
Erstelle ein Inventar der Skripte nach Route und Zweck. Entferne ungenutzte Pakete, Duplikate, eingestellte Experimente und Code für beendete Features. Teile anschließend routespezifische oder selten genutzte Features so auf, dass sie bei Bedarf geladen werden und nicht im Initialpfad. Dynamisches Laden kann Startup-Arbeit reduzieren, kann aber eine sichtbare Verzögerung erzeugen, wenn ein Nutzer die Funktion sofort braucht.
Frage dich, ob eine Komponente ein komplettes Client-Framework benötigt, ob ein Utility vorhandene Fähigkeiten dupliziert und ob statisches HTML plus eine kleine Verbesserung ausreicht. Teste den Fallback-Zustand eines verzögert geladenen Moduls. Die Seite sollte eine optionale Fähigkeit elegant verschieben statt ein totes Bedienelement anzuzeigen.
Dokumentiere, welche Skripte auf einer Route erlaubt sind und warum.
Denk daran für optionale Editoren, Karten, Player oder Reporting-Views.
Testen Sie Authentifizierung, Barrierefreiheit, Zahlungen und Formularabschlüsse; lassen Sie betroffene Kontrollen qualifiziert prüfen.
Teile Arbeit auf, damit der Browser reagieren kann
Das Benennen kleinerer Funktionen erzeugt keine separaten Browser-Tasks, wenn sie synchron laufen. Bei einer langen Schleife: verarbeite in Batches, aktualisiere sofort sichtbaren UI-Zustand und gib dann Kontrolle zurück, bevor du fortfährst. So kann der Browser zwischen den Batches Eingaben und Rendering verarbeiten.
Wenn unterstützt, räumt scheduler.yield() dem Hauptthread Zeit ein und setzt die Arbeit später fort; prüfen Sie, ob die Funktion verfügbar ist, und verwenden Sie für nicht unterstützte Browser einen Fallback. Geben Sie die Kontrolle nicht nach jeder winzigen Operation ab: Das verursacht Overhead und kann die Gesamtausführungszeit erhöhen. Legen Sie die Grenzen anhand von Messungen fest, erhalten Sie Abbruchmöglichkeiten und verhindern Sie, dass veraltete Ergebnisse neuere Zustände überschreiben.
Zeige Bestätigung oder Fortschritt vor nicht sichtbarer Nacharbeit.
Gebe zurück, bevor gemessene Arbeit lang wird, statt einmal pro Item.
Die aktuelle web.dev-Empfehlung rät nicht zu einer neuen Strategie, die auf isInputPending() basiert.
Verschiebe Berechnung, nicht die Oberfläche, in einen Worker
Ein Web Worker führt ein Script in einem Hintergrund-Thread aus, getrennt vom Hauptausführungs-Thread. Er eignet sich für kostspieliges Parsen, Datenumwandlung, Suchindexierung und andere Berechnungen, die keinen direkten Interface-Zugriff benötigen. Sende definierte Eingaben, gib ein definiertes Ergebnis zurück und behalte Rendering und sichtbare Zustandsänderungen im Haupt-Thread.
Worker sind nicht universell einsetzbar. Sie können das DOM nicht direkt manipulieren oder Window verwenden, und generelle Nachrichtenkommunikation kopiert Daten. Erstellung von Workern, Datenbewegung und Fehlerkoordination können kleinen Berechnungen mehr Aufwand hinzufügen als Einsparung. Messe die komplette Interaktion, beende unnötige Worker und entwerfe einen Fallback, falls Worker-Arbeit fehlschlägt.
Beginne mit einer Berechnung, deren Eingabe und Ausgabe serialisierbar und testbar sind.
Verwerfen Sie Ergebnisse, die für einen früheren Filter, eine frühere Route oder eine frühere Aktion erstellt wurden.
Kommuniziere sinnvollen Fortschritt über die normale Oberfläche.
Behandle Drittanbieter-JavaScript als Produktionsabhängigkeit
Analytics, Werbung, Experimente, Social-Embeds, Videoplayer und Support-Widgets können Anfragen, JavaScript-Auswertung, Iframes und Abhängigkeiten hinzufügen. Ein Anbieterskript kann notwendig sein, liegt jedoch außerhalb der direkten Kontrolle des Anwendungsteams und kann Performance, Datenschutz, Sicherheit und Kontinuität beeinträchtigen. Erstellen Sie ein Inventar mit Zweck, Routen, Ladebedingungen, Genehmiger, Einwilligungsanforderung und einer verantwortlichen Person für die Entfernung.
Soweit Bedingungen und Verträge es erlauben, vergleiche eine repräsentative Seite mit und ohne eine Drittanbieter-Origin. Performance-Tools können kostspielige Evaluation, Payloads und Long-Task-Attribution offenlegen. Behalte nur eine leichte oder verzögerte Integration, wenn ihr dokumentierter Wert die gemessenen Kosten rechtfertigt. Bestätige Kerninhalte und die primäre Transaktion, wenn eine optionale Abhängigkeit langsam oder nicht vorhanden ist.
Lade ein Tag nur auf Routen und unter Bedingungen, die es benötigen.
Beziehen Sie Änderungen im Tag-Manager in die Prüfungen zu Performance, Datenschutz, Sicherheit und Rollback ein.
Dokumentiere und teste, wie eine nicht-kritische Integration deaktiviert wird.
Mache Reaktionsfähigkeit zur Release-Sicherheitsmaßnahme
Verwandle den erfolgreichsten Trace in eine kleine Regressionsprüfung für die wichtige Reise. Definiere abgedeckte Interaktionen, Geräte- oder CPU-Einschränkung, erwartete Reaktion und Reviewer. Koppel das mit Bundle- und Drittanbieter-Inventar-Review, sodass ein neues Paket oder Tag nicht stillschweigend Haupt-Thread-Arbeit wieder einführt.
Status Is UP verwendet diese Evidenz für proaktive Optimierung und sichere Behebung, nicht als Ersatz für die Live-Überwachung der Verfügbarkeit. Bereiten Sie vor einer risikoreichen Änderung ein Rollback vor und verifizieren Sie den kritischen Ablauf nach dem Release. Ergebnisse variieren je nach Gerät, Netzwerk, Browser, Inhalt und Account-Zustand; behandeln Sie Schwellenwerte als Leitplanken, nicht als Garantien.
Fordere Vorher-/Nachher-Traces für gemeinsame Navigation, Checkout, Suche oder große Bundles.
Kennen Sie das Feature-Flag, die Tag-Einstellung oder die Deployment-Version, mit der sich bekanntermaßen funktionierendes Verhalten wiederherstellen lässt.
Profilisiere nach größeren Releases, Vendor-Änderungen oder Verschiebungen in der Geräte-Mischung erneut.