Performance messen und verbessern

Performance messen und verbessern

0:00 Ohne Messung ist jede Optimierung eine Vermutung mit Aufwand. Das ist der Satz, um den sich dieses Modul dreht, und er ist unbequemer, als er klingt. Denn Entwickler haben gute Vermutungen — wir wissen meistens ungefähr, wo es hakt. Ungefähr reicht nur nicht, wenn man begründen will, warum man zwei Tage in eine Umstellung gesteckt hat.

0:20 In diesem Modul erheben wir einen Befund, beheben genau eine Ursache und belegen die Wirkung.

Rendering, Performance und Sicherheit

0:27 Wir sind im fünften Tag. Die Auslieferung ist geklärt, jetzt die Frage, was beim Benutzer ankommt und wie schnell. Und danach, nach der Mittagspause, das Thema Sicherheit.

Zuerst messen, dann ändern

0:38 Beginnen wir mit den Werkzeugen und vor allem mit der Reihenfolge. Die ist nämlich das Entscheidende. Angular DevTools bietet vier Bereiche: einen für Komponenten samt Zustand, einen Profiler für die Change Detection, einen für die Injektor-Hierarchie und einen für den Routenbaum. Für Ladezeit und Bündelgröße kommen die Browserwerkzeuge dazu.

0:58 Vier Bereiche klingt nach viel; im Alltag brauchen Sie zwei — den Profiler, wenn die Oberfläche träge reagiert, und die Netzwerkansicht, wenn das Laden dauert. Die anderen beiden sind eher für das Verstehen als für das Messen. Fünf Schritte, und der wichtigste ist der zweite: drosseln. Ihr Entwicklungsrechner ist kein Werkstattrechner.

1:18 Wer auf einem schnellen Gerät mit Glasfaser misst, misst eine Anwendung, die es beim Kunden nicht gibt. Schritt eins ist die Voraussetzung — denselben Fall mit denselben Daten reproduzierbar machen. Schritt vier ist die Disziplin: den Befund mit Zahl und Bedingungen notieren. Und Schritt fünf ist die Reihenfolge, um die es geht: erst danach die Ursache suchen.

1:40 Vier Punkte, und der erste beschreibt, was tatsächlich passiert: Optimiert wird, was vertraut ist, nicht was teuer ist. Man kennt eine Stelle, die einem schon lange nicht gefällt, und macht die schön. Der zweite: Die Änderung bringt nichts, und niemand merkt es — weil niemand nachher misst. Der dritte ist der gefährliche: Eine Verschlechterung an anderer Stelle bleibt unbemerkt.

2:03 Und der vierte ist der organisatorische: Der Aufwand lässt sich niemandem gegenüber begründen. Mit zwei Zahlen schon. Der erste Punkt ist der, den ich eben genannt habe und der mit Abstand häufigste: Gemessen wird auf dem schnellen Rechner ohne Drosselung. Der zweite ist fast noch verbreiteter und macht die Zahlen unbrauchbar: gemessen am Entwicklungsbau statt am Produktionsbau.

2:25 Der Entwicklungsbau ist absichtlich unoptimiert — er sagt über die Auslieferung nichts. Und der dritte ist der, der den Vergleich unmöglich macht: Der Ausgangswert wird nicht notiert und fehlt nachher.

Lazy Routes und @defer

2:37 Jetzt zu den beiden Mitteln, mit denen Sie Ladeumfang verschieben. Das eine kennen Sie aus Modul neun, das andere ist neu. Lazy Routes teilen die Auslieferung entlang der Navigation — das haben wir gemacht. Der aufgeschobene Block teilt innerhalb einer Ansicht. Er kennt Platzhalter, Ladeanzeige und Fehlerfall sowie eine ganze Reihe von Auslösern: bei Leerlauf, bei Sichtbarkeit, bei Interaktion, beim Überfahren, sofort, nach einer Zeitspanne oder bei einer Bedingung.

3:05 Mit dem Vorabladen können Sie beides kombinieren. Und eine Einschränkung: Aufgeschoben werden können nur standalone Bausteine, die außerhalb des Blocks nicht referenziert sind. Die Kombination in der ersten Zeile ist die, die ich am häufigsten empfehle: bei Sichtbarkeit anzeigen, bei Leerlauf schon vorab laden. Damit ist der Inhalt da, sobald man hinscrollt, und trotzdem nicht im Startbündel.

3:28 Worauf es sonst ankommt, steht in den beiden Zeitangaben: Die eine verhindert, dass ein Platzhalter aufblitzt und sofort verschwindet, die andere, dass ein Ladetext erscheint, obwohl der Inhalt in achtzig Millisekunden da ist. Beides sind Kleinigkeiten, die den Unterschied zwischen ruhig und zappelig ausmachen. Der erste Punkt ist der, der die ganze Maßnahme wirkungslos macht und nirgends warnt: Der aufgeschobene Baustein wird außerhalb des Blocks referenziert — oft nur in der Import-Liste der Komponente — und lädt sofort mit.

3:58 Der zweite ist ein Gestaltungsfehler mit spürbarer Wirkung: Der Platzhalter hat eine andere Höhe, und das Layout springt. Und der dritte ist die Übertreibung: Alles wird aufgeteilt, und die Zahl der Anfragen kostet am Ende mehr, als die kleineren Dateien sparen.

Unnötige Arbeit erkennen

4:13 Kommen wir zur Laufzeit. Und zu vier Ursachen, die für die meisten trägen Oberflächen verantwortlich sind. Typische Ursachen sind Berechnungen im Template, die bei jedem Durchlauf laufen — das hatten wir in Modul vier. Zu breit geschnittene Zustandsflüsse, bei denen eine Änderung halbe Ansichten betrifft — Modul fünf. Und Listen, die wegen eines instabilen Schlüssels neu aufgebaut werden — ebenfalls Modul vier.

4:38 Sie sehen: Die Performance-Arbeit besteht zum großen Teil daraus, Entscheidungen einzusammeln, die an anderer Stelle getroffen wurden. Mit OnPush als Standard und Signals wird der betroffene Bereich ohnehin kleiner. Vier Zeilen, und alle vier sind Rückverweise auf frühere Module — das ist kein Zufall. Ein Methodenaufruf im Template wird zur Ableitung.

5:00 Ein instabiler Schlüssel wird zum fachlichen. Ein zu grob geschnittenes Signal wird feiner. Und eine vollständig gerenderte große Liste wird abschnittsweise geladen oder aufgeschoben. Wenn Sie in Ihrer eigenen Anwendung nach Leistungsproblemen suchen: Diese vier Zeilen sind eine brauchbare erste Checkliste, und sie kosten kein Werkzeug.

5:20 Der erste Punkt ist der unscheinbarste: Eine Ableitung enthält eine teure Berechnung und wird nie gemessen — sie sieht ja harmlos aus, ein Einzeiler. Der zweite ist ein Entwurfsfehler mit Breitenwirkung: Der Zustand ist so grob geschnitten, dass jede Änderung alles betrifft. Und der dritte ist der, den man beim Entwickeln nie sieht, weil man mit zehn Testdatensätzen arbeitet: Eine Liste mit tausend Zeilen wird vollständig gerendert.

5:45 Beim Kunden sind es dann zwölfhundert.

Verbesserung belegen

5:48 Bleibt die zweite Hälfte der Arbeit, die gern ausfällt: nachweisen, dass es etwas gebracht hat. Eine Verbesserung gilt erst als belegt, wenn dieselbe Messung unter denselben Bedingungen einen besseren Wert zeigt. Denselben — das ist der ganze Punkt. Und dann kommt die zweite Frage, die seltener gestellt wird: Ist die Änderung für den Benutzer spürbar?

6:10 Zwanzig Millisekunden weniger in einem Ablauf, den niemand bemerkt, sind kein Gewinn, sondern Aufwand. Manchmal auch schlechter lesbarer Code für nichts. Diese Abwägung gehört ausgesprochen, nicht stillschweigend getroffen. Vier Punkte, und die beiden mittleren werden am häufigsten übersprungen. Ausgangswert und neuer Wert unter gleichen Bedingungen — klar. Aber dann: Ist der Unterschied wahrnehmbar?

6:35 Und: Was hat die Änderung an Lesbarkeit und Pflege gekostet? Eine Optimierung, die den Code für die nächsten drei Entwickler unverständlich macht, hat einen Preis, der nirgends in der Messung auftaucht. Und der vierte: Ist an anderer Stelle etwas schlechter geworden? Das prüft fast niemand. Der erste Punkt macht die Zahlen wertlos: Der Vergleich läuft unter anderen Bedingungen als die erste Messung — andere Drosselung, anderer Datenbestand, anderer Browser.

7:03 Der zweite ist die Abwägung, die nicht stattgefunden hat: Eine unmerkliche Verbesserung wird mit deutlich schlechterem Code bezahlt. Und der dritte ist der, der eine Anwendung langsam werden lässt, ohne dass es jemand merkt: Nach der Änderung wird nie wieder gemessen. Dann wächst die Ladezeit über Monate zurück.

Übung

7:21 Messen wir. Und zwar unter Bedingungen, die denen in der Werkstatt ähneln — nicht denen an Ihrem Schreibtisch. Die Auftragsübersicht von Spurweite lädt bei zwölfhundert offenen Aufträgen spürbar langsam. Die Werkstattrechner sind nicht schnell, und das Netz im Standort ist es auch nicht. Bisher wurde ohne Messung optimiert — jemand hat eine Liste umgebaut, jemand anders hat etwas nachgeladen, und ob eines davon geholfen hat, weiß niemand.

7:48 Genau diese Situation wollen wir beenden. Das Lernziel hat drei Teile, und sie gehören in dieser Reihenfolge zusammen: erheben, genau eine Ursache beheben, Wirkung belegen. Das Wort „genau eine" ist wichtig. Das Erfolgskriterium verlangt beide Werte unter gleichen Bedingungen, die benannte Ursache — und eine begründet verworfene zweite Optimierung.

8:09 Dieser letzte Punkt ist ungewöhnlich für eine Übung und mir der liebste: Etwas nicht zu tun und dafür einen Grund zu haben, ist eine Fähigkeit. Der erste Schritt schafft die Bedingungen: Produktionsbau und Drosselung. Ohne beides messen Sie etwas anderes als das, was Ihre Benutzer erleben. Schritt zwei erhebt den Ausgangswert — notieren Sie ihn. Schritt drei behebt eine Ursache, nur eine. Schritt vier misst erneut, gleiche Bedingungen.

8:36 Und Schritt fünf verwirft begründet. Wenn Sie die fünfzig Minuten überziehen, dann an Schritt drei — lassen Sie lieber die Behebung kleiner ausfallen als die Messung. Der erste Punkt ist die verbreitetste Selbsttäuschung: Zwei Ursachen werden gleichzeitig behoben, und die Wirkung ist nicht zuzuordnen. Man hat dann eine Verbesserung und weiß nicht, wovon — also auch nicht, was man beim nächsten Mal wieder tun sollte.

9:01 Der zweite ist der Messfehler von vorhin: am Entwicklungsbau ohne Drosselung. Und der dritte ist die halbe Arbeit: Die verworfene Optimierung wird nicht begründet, sondern nur weggelassen. Als Nächstes: Sicherheit — und dort geht es um Ausnahmen, die jemand vor Jahren eingebaut hat.