Performance

Angular — Performance

0:00 Über Performance wird viel geraten und wenig gemessen. Das ist bemerkenswert, denn die Werkzeuge dafür sind seit Jahren in jedem Browser eingebaut und kosten nichts. In diesem Modul geht es deshalb weniger um Optimierungstricks als um Messgewohnheiten: Wie findet man heraus, wo eine Anwendung tatsächlich Zeit verliert? Wir schauen uns drei Werkzeuge an, dann zwei Stellschrauben, die im Alltag am meisten bringen.

0:23 Und zum Schluss etwas, das keine Optimierung ist, sondern eine Versicherung — eine automatische Grenze, die Sie warnt, bevor eine Anwendung heimlich schwerer wird.

Lade- und Laufzeit-Performance

0:33 Fünf Kapitel in einer bewussten Reihenfolge. Die ersten drei sind Werkzeuge — der Netzwerk-Tab für die Frage, was geladen wird, der Performance-Tab für die Frage, wann der Nutzer etwas sieht, und die Angular DevTools für die Frage, welche Komponente rechnet. Erst danach kommen die Maßnahmen: OnPush als Voreinstellung und Größenbudgets im Build. Diese Reihenfolge ist Absicht.

0:55 Optimieren ohne Messung ist Ratespiel, und Ratespiele in Performance-Fragen gehen erstaunlich oft daneben — man verbessert dann sorgfältig etwas, das gar nicht das Problem war.

Netzwerk-Tab — Ladezeit diagnostizieren

1:06 Fangen wir mit dem einfachsten Werkzeug an, das zugleich am meisten verrät: dem Netzwerk-Tab. Er beantwortet die erste Frage, die man bei einer träge startenden Anwendung stellen sollte — was lädt der Browser eigentlich alles, bevor irgendetwas zu sehen ist? Und die Antwort darauf fällt regelmäßig anders aus, als das Team vermutet hätte — meistens sind es die Bilder und nicht der Code.

1:29 Der Netzwerk-Tab zeigt jede einzelne Anfrage: wie groß, wer sie ausgelöst hat, welchen Typ sie hat und wie sich ihre Zeit zusammensetzt. Das ist erst einmal eine Liste, und Listen wirken langweilig. Der Wert entsteht durch Wiederholung — wer regelmäßig hineinschaut, entwickelt ein Gefühl dafür, wie die eigene Anwendung normalerweise aussieht.

1:49 Und dann fallen Abweichungen sofort auf. Wichtig ist der Kontext: Messen Sie im Produktionsmodus, idealerweise gegen den echten Server. Ein Entwicklungsbuild ist unkomprimiert und sagt über die Realität wenig aus. Die ersten beiden Schritte richten die Messung ein, und der zweite ist der, den man am häufigsten vergisst: Caching abschalten.

2:09 Sonst messen Sie den zweiten Besuch, und der ist meistens unauffällig — die Probleme haben die Erstbesucher. Die Schritte drei und vier sind zwei verschiedene Blickwinkel auf dieselben Daten: nach Größe sortiert findet man einzelne Ausreißer, nach Typ sortiert erkennt man Muster — etwa dass Bilder zusammen mehr wiegen als der gesamte Code.

2:28 Und der fünfte Schritt ist der ernüchterndste: Drosseln Sie auf ein langsames Mobilfunknetz und schauen Sie zu. Die Fußzeile ist hier wichtiger als die Tabelle: Absolute Grenzwerte gibt es nicht. Was für eine Nachrichtenseite viel ist, ist für ein Werkzeug im Firmennetz wenig. Die Zahlen in der Tabelle sind deshalb Anhaltspunkte, keine Regeln.

2:49 Was tatsächlich zählt, ist die letzte Zeile: Wenn eine einzelne Datei sehr viele Anfragen auslöst, lohnt der Blick in die Auslöser-Spalte. Und die allgemeinste Regel lautet: Sie müssen nicht jede große Datei loswerden — Sie müssen nur zu jeder sagen können, warum sie so groß ist. Was Sie nicht erklären können, sollten Sie untersuchen.

3:09 Die Wasserfall-Ansicht ist der unterschätzteste Teil dieses Werkzeugs, weil sie die Frage nach dem Warum beantwortet. Eine langsame Anfrage kann drei sehr verschiedene Ursachen haben, und die Behandlung ist jeweils eine andere. Lange Verbindungsaufbauzeiten deuten auf Serverstandort oder Netzwerk — daran ändert kein Code etwas.

3:29 Lange Wartezeit auf den Server heißt: Dort wird gerechnet, vermutlich in einer Datenbankabfrage. Und eine lange Download-Zeit ist schlicht eine Frage der Größe. Drei Ursachen, drei Zuständigkeiten. Wer das auseinanderhält, optimiert nicht am falschen Ende. Eine Aufgabe, die in fünf Minuten erledigt ist und trotzdem etwas verändert.

3:49 Nehmen Sie ein Ladeprofil Ihrer eigenen Anwendung auf und benennen Sie die drei größten Anfragen — mit Begründung. Geschafft haben Sie es, wenn Sie zu jeder etwas sagen können. Der Hinweis wiederholt sich, weil er wirklich der häufigste Fehler ist: Caching abschalten, sonst messen Sie am Problem vorbei. Und wenn Sie danach Lust haben: Machen Sie dieselbe Messung mit gedrosselter Verbindung. Die Reihenfolge der drei größten Posten kann sich dabei durchaus ändern.

Performance-Tab — LCP verstehen und verbessern

4:16 Der Netzwerk-Tab hat gezeigt, was geladen wird. Der Performance-Tab beantwortet die interessantere Frage: Wann sieht der Nutzer eigentlich das, wofür er gekommen ist? Und er gibt dazu konkrete Handlungsempfehlungen — was ihn von einem reinen Messwerkzeug unterscheidet. Denn zwischen „technisch fertig geladen" und „für den Menschen davor brauchbar" liegen oft ein paar Sekunden, die in keiner Ladeliste auftauchen.

4:41 Largest Contentful Paint misst den Zeitpunkt, an dem der größte sichtbare Inhalt fertig gerendert ist. Der Gedanke dahinter ist bestechend einfach: Nicht jeder Ladevorgang ist gleich wichtig — entscheidend ist, wann das da ist, weswegen jemand gekommen ist. Bei einem Shop ist das das große Produktbild, nicht das Impressum im Fußbereich. Der Performance-Tab nimmt beim Neuladen ein Profil auf und leitet daraus Empfehlungen ab.

5:05 Das ist der angenehme Teil: Sie bekommen nicht nur Zahlen, sondern konkrete Vorschläge, was zu tun ist. Der erste Schritt ist der wichtigste und wird am häufigsten übersehen: Docken Sie die Entwicklerwerkzeuge in ein eigenes Fenster ab. Der Grund ist banal und folgenschwer — analysiert wird nur, was tatsächlich sichtbar ist. Wenn die halbe Seite von den Werkzeugen verdeckt wird, fehlt sie in der Messung.

5:29 Die restlichen Schritte sind ein Kreislauf: aufnehmen, eine Empfehlung umsetzen, erneut aufnehmen, prüfen. Der letzte Schritt ist das eigentliche Erfolgserlebnis — wenn ein Punkt von der Empfehlungsliste in die Liste der bestandenen Prüfungen wandert, haben Sie einen Beleg statt eines Gefühls. Die ersten beiden Punkte sind Werkzeug-Eigenheiten, die einen Nachmittag kosten können, wenn man sie nicht kennt. Der erste ist der eben erwähnte Sichtbarkeits- Effekt.

5:55 Der zweite ist eine Kuriosität: Bei maximiertem Werkzeugfenster startet das Neuladen nicht zuverlässig — man klickt und wartet auf etwas, das nie kommt. Der dritte Punkt ist der methodische: Im Entwicklungsmodus messen liefert Zahlen, mit denen man nichts anfangen kann. Und der vierte ist der, der die ganze Übung entwertet: Empfehlungen abarbeiten, ohne danach noch einmal zu messen.

6:18 Hier steckt eine kleine, feine Idee drin. Der Browser weiß nicht, welche Bilder wichtig sind — für ihn sind alle gleich. Mit der Prioritäts-Angabe sagen Sie es ihm. Wichtig ist der zweite Teil des Beispiels: Nur die ersten drei bekommen Vorrang. Alles zu priorisieren ist dasselbe wie nichts zu priorisieren — dann konkurrieren wieder alle miteinander.

6:39 Und ein praktischer Hinweis: Die Bild-Direktive verlangt zwingend Breite und Höhe. Das ist keine Schikane, sondern verhindert, dass die Seite beim Laden springt, weil der Platz vorher nicht reserviert war. Eine Zeile mit erstaunlicher Wirkung. Das Problem, das sie löst, ist typisch für moderne Anwendungen: Der Browser beginnt mit dem JavaScript, und erst wenn das läuft, erfährt er überhaupt, welches Bild er braucht.

7:04 Die Vorlade-Angabe steht dagegen im HTML-Kopf und wird sofort gelesen — der Browser kann also parallel laden, statt zu warten. In der Messung sieht man das als deutlich gesunkene Verzögerung vor dem eigentlichen Laden. Sparsam einsetzen: Das lohnt für genau das eine Bild, das den größten sichtbaren Inhalt ausmacht. Diese Aufgabe übt etwas, das über Performance hinausgeht: eine Änderung durch Messung zu belegen.

7:29 Nehmen Sie sich eine Empfehlung aus dem Profil vor, setzen Sie sie um, und messen Sie erneut. Geschafft haben Sie es, wenn der Punkt bei den bestandenen Prüfungen auftaucht. Der Hinweis ist der Lerninhalt: Nur Bilder über der Falz priorisieren. Wer alle priorisiert, hat die Empfehlung formal befolgt und praktisch nichts erreicht — ein Muster, das man in Performance- Diskussionen häufiger antrifft, als einem lieb ist.

Angular DevTools — Change Detection profilieren

7:54 Die Chrome-Werkzeuge sind hervorragend, haben aber einen blinden Fleck: Sie kennen Angular nicht. Sie sehen JavaScript-Funktionen, nicht Komponenten. Für die Frage, welche Komponente bei einem Klick rechnet, gibt es ein eigenes Werkzeug vom Angular-Team. Das ist keine Schwäche der Chrome-Werkzeuge, sondern eine Frage der Perspektive: Sie sehen, was der Browser tut, nicht was Ihr Framework tut.

8:18 Für die zweite Sicht gibt es ein eigenes Werkzeug. Die Angular DevTools sind eine Browser-Erweiterung. Ihr Profiler zeichnet die Change-Detection-Zyklen auf und zeigt je Zyklus, wo die Zeit geblieben ist — aufgeschlüsselt nach Komponenten. Ein wichtiger Unterschied zu den vorigen Werkzeugen: Hier brauchen Sie den Entwicklungsmodus.

8:37 Im Produktionsbuild fehlen die Informationen, die das Werkzeug auswertet, und der Angular-Tab bleibt leer. Das ist die Umkehrung dessen, was wir bisher gemacht haben — und eine häufige Verwirrung, wenn man beide Werkzeuge in derselben Sitzung benutzen will. Anders als beim Ladeprofil messen Sie hier nicht einen Vorgang, sondern Benutzung.

8:57 Profiler starten, dann die Anwendung wirklich bedienen — navigieren, klicken, Dinge hinzufügen und entfernen. Jede Interaktion, die eine Change Detection auslöst, erscheint als Balken. Und dann kommt der eigentliche Schritt: einen auffällig hohen Balken anklicken und nachsehen, welche Komponenten dahinter stecken. Achten Sie dabei nicht nur auf die Zeit, sondern auch auf die Zahl der Instanzen. Die verrät oft mehr über die Ursache als die Millisekunden daneben.

9:25 Der erste Punkt ist der Grund, warum dieses Werkzeug neben den Chrome-Werkzeugen existiert: Es spricht Ihre Sprache. „Die Detail-Komponente kostet" ist eine Aussage, mit der Sie etwas anfangen können. „Eine anonyme Funktion in einer gebündelten Datei kostet" ist es nicht. Der zweite Punkt ist der, der oft die eigentliche Entdeckung ist: wie viele Instanzen ein einziger Klick neu rendert.

9:48 Diese Zahl überrascht regelmäßig — und sie ist meistens der Einstieg in das Thema des nächsten Kapitels. Der erste Punkt gehört zur Bedienungsanleitung: Der Profiler zeigt nicht alles. Was unter einer Zehntelmillisekunde bleibt, fällt weg. Wenn dort also fünf Instanzen stehen, obwohl vierzehn auf dem Bildschirm sind, ist das kein Fehler — die anderen waren nur zu billig.

10:11 Der zweite Punkt ist der irritierendere: Manchmal wird die Zeit auf eine Elternkomponente hochgerollt, und Sie erfahren nur, dass „die Anwendung" langsam war. Dann hilft eine andere Interaktion. Und der dritte kostet fünf Minuten Verwirrung: im Produktionsmodus messen und einen leeren Tab vorfinden. Diese Aufgabe übt den Übergang vom Vermuten zum Zuordnen.

10:32 Nehmen Sie eine Interaktion Ihrer Anwendung auf und benennen Sie danach drei Dinge: welche Komponente, wie lange, wie viele Instanzen. Der Hinweis ist ein didaktischer Trick, den ich empfehle: Bauen Sie zum Üben absichtlich eine teure Berechnung in eine Komponente ein, die oft gerendert wird. Dann sehen Sie im Profiler einen eindeutigen Ausschlag und wissen genau, wie so ein Befund aussieht. Beim echten Problem erkennen Sie ihn danach wieder.

OnPush als Voreinstellung

10:58 Jetzt die erste echte Maßnahme dieses Moduls. OnPush hatte lange den Ruf, heikel zu sein — und das war vor einigen Jahren berechtigt. Durch Signals und Zoneless hat sich diese Lage grundlegend verändert, und das macht die Empfehlung heute zu einer anderen als noch vor drei Jahren. Wir schauen uns an, was OnPush genau bewirkt, warum die alten Vorbehalte weitgehend entfallen sind und was beim Umstellen zu beachten ist.

11:22 Mit OnPush prüft Angular eine Komponente nur noch unter drei Bedingungen: wenn sich ein Input ändert, wenn in ihr selbst ein Ereignis auftritt, oder wenn ein Signal sich ändert, das sie liest. Die Voreinstellung ist deutlich großzügiger — dort wird bei jedem Zyklus vorsichtshalber alles geprüft. Das Bild dazu: Statt im ganzen Haus nachzuschauen, ob sich etwas verändert hat, gehen Sie nur in die Räume, aus denen jemand Bescheid gegeben hat.

11:47 Das ist offensichtlich weniger Arbeit — es setzt nur voraus, dass wirklich alle Bescheid geben. Der erste Punkt ist der, den man im Profiler sofort sieht: Ein Klick rendert nicht mehr sämtliche Geschwister neu. Bei einer Liste mit vierzig Einträgen ist das der Unterschied zwischen einer und vierzig Berechnungen. Der zweite Punkt ist der eigentliche Grund, warum die Empfehlung sich geändert hat: Mit Signalen geben tatsächlich alle Bescheid, und die früheren Fallstricke verschwinden weitgehend.

12:15 Und der vierte Punkt ordnet es ein — OnPush ist die logische Ergänzung zu zoneless. Beides steht für dasselbe Prinzip: rechnen, wenn es einen Anlass gibt, statt vorsichtshalber. Eine Zeile, und das ist zugleich die schlechte Nachricht. Es gibt keine globale Einstellung — die Zeile gehört in jede Komponente. Bei einer gewachsenen Anwendung ist das eine mechanische Fleißarbeit, die sich gut automatisieren lässt, aber eben anfällt.

12:40 Was Sie dabei nicht vergessen dürfen, ist der Import; das ist der Fehler, den man beim fünften Mal Kopieren macht. Mein Rat: Machen Sie es nicht auf einmal, sondern bereichsweise — und messen Sie zwischendurch, damit Sie merken, wenn irgendwo etwas nicht mehr aktualisiert. Der erste Punkt ist der klassische OnPush-Fehler und der Grund für seinen früheren Ruf: Wer ein Objekt verändert, statt es zu ersetzen, ändert nichts, was Angular bemerken könnte.

13:07 Die Liste ist dieselbe Liste — der Input gilt als unverändert, die Anzeige bleibt alt. Der zweite ist die allgemeine Form davon: Zustand außerhalb von Signalen und Inputs löst nichts aus. Der dritte ist der vergessene Import. Und der vierte ist eine Fehldeutung beim Messen: Der Erstaufbau einer langen Liste ist teuer, und daran ändert OnPush nichts — das ist kein Versagen der Strategie.

13:31 Diese Aufgabe verbindet die Werkzeuge aus der ersten Hälfte des Moduls mit der Maßnahme aus dieser. Nehmen Sie ein Profil auf, stellen Sie eine Komponente auf OnPush um, nehmen Sie erneut auf, und vergleichen Sie. Geschafft haben Sie es, wenn die Zahl der neu gerenderten Instanzen sichtbar fällt. Ich empfehle diese Übung ausdrücklich, weil sie eine Behauptung in einen Beleg verwandelt.

13:52 Und weil zwei Bilder aus dem Profiler im Team überzeugender sind als jeder Blogartikel über Change-Detection-Strategien.

Bundle-Größen mit Budgets überwachen

14:00 Das letzte Kapitel ist keine Optimierung, sondern eine Versicherung. Es geht um das Problem, dass Anwendungen langsam schwerer werden — nie durch eine Entscheidung, immer durch viele kleine. Und darum, wie man das bemerkt, bevor es die Nutzer tun. Denn eine Anwendung wird nie an einem Tag doppelt so schwer. Sie wird es in achtzehn Monaten, in Schritten, die einzeln niemandem auffallen — und genau davor schützt eine automatische Grenze.

14:26 Angular kann beim Produktionsbuild Größengrenzen prüfen. Wird eine überschritten, gibt es eine Warnung oder einen Fehler — und im Fehlerfall bricht der Build ab. Das klingt streng und ist genau der Punkt. Denn das typische Wachstumsmuster ist schleichend: Jemand braucht eine Datumsfunktion und installiert eine Bibliothek, die auch dreißig andere Dinge kann.

14:47 Das fällt niemandem auf, weil nichts kaputt geht. Ein Budget macht daraus ein Ereignis, das jemand bemerken muss — und dann kann man entscheiden, statt es zu erben. Interessant ist hier die Variante mit der Grundlinie. Statt einer absoluten Zahl geben Sie den aktuellen Stand an und legen fest, wie viel Prozent Zuwachs eine Warnung oder einen Fehler auslösen.

15:08 Das hat einen praktischen Vorteil: Sie müssen sich nicht überlegen, wie groß eine Anwendung sein darf — eine Frage, auf die es ohnehin keine allgemeine Antwort gibt. Sie legen nur fest, wie viel unbemerktes Wachstum Sie akzeptieren. Fünf Prozent für die Warnung, zehn für den Fehler ist ein brauchbarer Ausgangspunkt. Die Logik hinter dieser Liste ist eine Staffelung von eng nach weit.

15:30 Ganz oben das Startpaket — das, worauf es beim ersten Eindruck ankommt und was die meisten als Einziges überwachen. Darunter Prüfungen für einzelne Komponenten-Stile, für namentlich genannte Pakete, für das gesamte JavaScript und schließlich für alles zusammen. Der letzte Eintrag ist ein nützlicher Wächter: Er schlägt an, wenn eine einzelne Datei beliebigen Typs zu groß wird — der Fall, in dem jemand ein unkomprimiertes Bild ins Repository legt.

15:56 Der erste Schritt ist die Bestandsaufnahme, und den braucht man wirklich — ohne den aktuellen Wert setzt man Grenzen ins Blaue. Die Schritte zwei und drei setzen zwei Schwellen: eine, die warnt, und eine, die anhält. Der vierte Schritt ist wieder der, der über Wirkung oder Wirkungslosigkeit entscheidet — genau wie bei Sheriff im Architekturmodul.

16:16 Eine Grenze, die nur lokal geprüft wird, greift im entscheidenden Moment nicht. Und der fünfte gehört zur Pflege: Nach einem bewussten Zuwachs muss die Grundlinie nachgezogen werden, sonst stimmen die Prozentwerte nicht mehr. Die ersten beiden Punkte beschreiben, wie ein Budget stirbt. Der erste ist der schnelle Tod: Es läuft nie dort, wo es zählen würde.

16:37 Der zweite ist der langsame: Bei jeder Warnung wird die Grenze angehoben. Nach einem Jahr ist die Zahl in der Konfiguration doppelt so hoch, und niemand kann sagen, wann das passiert ist. Der dritte Punkt ist eine typische Lücke — nur das Startpaket zu überwachen und die verzögert geladenen Bereiche wachsen zu lassen. Und der vierte ist der Pflegefehler bei der Grundlinie.

17:00 Auch diese Aufgabe funktioniert über das absichtliche Kaputtmachen — aus demselben Grund wie bei Sheriff. Installieren Sie ein Paket, benutzen Sie es irgendwo, und schauen Sie zu, wie der Build am Budget scheitert. Geschafft haben Sie es, wenn der Build mit einem Budgetfehler abbricht. Danach entfernen Sie das Paket wieder und setzen die Grundlinie auf den echten Wert.

17:20 Was Sie dabei gewinnen, ist Vertrauen: Sie haben die Grenze einmal auslösen sehen und wissen, dass sie im Ernstfall nicht stillschweigend danebenliegt. Vier Punkte, und der erste trägt alles andere: erst messen, dann ändern — und danach noch einmal messen. Der zweite ordnet die Werkzeuge: Die Chrome-Werkzeuge sind für das Laden und den sichtbaren Inhalt zuständig, die Angular DevTools für die Change Detection.

17:44 Beide braucht man, keins ersetzt das andere. Der dritte fasst die Maßnahme zusammen — OnPush ist mit Signalen und Zoneless nicht mehr riskant, sondern naheliegend. Und der vierte ist die Versicherung: Budgets in der Bau-Pipeline fangen Wachstum ab, bevor es beim Nutzer ankommt.

Fragen & Weiterarbeiten

18:01 Damit ist das vorletzte Modul geschafft. Im letzten geht es noch einmal näher an den Code, und zwar an Fragen, die gar nichts Angular-Spezifisches haben: das Single-Responsibility-Prinzip, kleine Funktionen und die Frage, wo Logik eigentlich hingehört. Das klingt nach Grundlagen und ist trotzdem der Teil, an dem sich im Alltag am meisten entscheidet.

18:20 Wenn Sie die Angular DevTools noch nicht installiert haben — sie stehen im Chrome Web Store und sind in zwei Minuten eingerichtet. Fragen zu Performance gerne jetzt.