Caching und Streaming in Next.js: Leistung wurde zu einer architektonischen Entscheidung

Lange Zeit war die Aufführung die letzte Phase des Projekts. Die Anwendung wurde erstellt, am Ende gemessen, und als die Seite langsam war, kamen Abhilfemaßnahmen zum Vorschein: ein Cache hier, ein Spinner dort, ein Lazy Load dort. Es handelte sich um ein letztes Detail, das bearbeitet wurde, nachdem die wichtigen Entscheidungen bereits getroffen worden waren.

Modern Next.js löst diese Reihenfolge auf. Cache, Streaming und Suspense sind keine Knöpfe, die man am Ende einschaltet; Sie sind Eigenschaften dafür, wie die Seite zusammengestellt und bereitgestellt wird. Die Entscheidung, wann Daten neu berechnet werden, in welcher Reihenfolge die Teile des Bildschirms angezeigt werden und was vor dem Rest bereitgestellt werden kann, sind strukturelle Entscheidungen. Die These dieses Textes ist einfach: Die wahrgenommene Leistung wurde zu einer architektonischen Entscheidung, und es wurde kostspielig, sie als letztes Detail zu behandeln.

Drei Mechanismen, die unterschiedliche Probleme lösen

Es lohnt sich, die einzelnen Teile voneinander zu trennen, da sie oft mit einer einzigen vagen Vorstellung von „schnell gehen“ verwechselt werden.

Beim Cache geht es darum, Arbeit nicht zu wiederholen. Wenn bereits Daten abgerufen oder eine Seite bereits gerendert wurde, können Sie durch das Speichern vermeiden, dass bei der nächsten Anfrage erneut dieselben Kosten anfallen. Der Gewinn liegt im Durchsatz und in der Latenz: Antworten, die die Bank nicht berühren müssen, werden in Bruchteilen der Zeit ausgegeben.

Beim Streaming geht es darum, nicht darauf zu warten, dass alles für die Auslieferung bereit ist. Anstatt die gesamte Seite zu warten, bis der langsamste Teil fertig ist, sendet der Server den HTML-Code in Blöcken, sobald jeder verfügbar ist. Der Benutzer beginnt zu sehen und mit dem zu interagieren, was bereits angekommen ist, während der Rest noch zusammengebaut wird.

Spannung macht Streaming nutzbar. Es ermöglicht Ihnen, in der Komponente selbst zu deklarieren: „Wenn diese Daten nicht ausreichen, zeigen Sie sie an“. Es markiert die Grenzen zwischen dem, was bereit ist, und dem, was noch geladen wird, und gibt dem Framework die Erlaubnis, den Bildschirm in zusammenhängenden Blöcken statt in einem einzelnen Block zu senden.

Wie sie zusammenarbeiten

Der Zauber entsteht in der Kombination. Stellen Sie sich eine Produktseite vor: Kopfzeile, Artikeldaten, Bewertungen und Empfehlungen. Die Kopf- und Positionsdaten sind schnell. Bewertungen basieren auf starker Aggregation. Empfehlungen erfordern einen langsamen externen Dienst.

Im alten Modell wartete die gesamte Seite auf die langsamste Komponente. Der Benutzer blickte auf einen leeren Bildschirm, bis alles, einschließlich der Empfehlung eines mürrischen Dritten, fertig war. Die Leistung der Seite wurde von ihrem schlimmsten Element beeinflusst.

Da Suspense jeden Block abgrenzt und das Streaming aktiv ist, liefert der Server sofort den Artikel-Header und die Daten, mit Ladeindikatoren anstelle von Bewertungen und Empfehlungen. Sobald jedes Teil auf dem Server bereitsteht, wird es übertragen und rastet ein. Darunter sorgt der Cache dafür, dass beim nächsten Besuch die Teile, die sich nicht geändert haben, nicht einmal neu berechnet werden müssen. Die drei Mechanismen summieren sich: Caching reduziert die Arbeit, Streaming eliminiert die Wartezeit im schlimmsten Fall und Suspense organisiert die Zustellung.

Das Ergebnis ist, dass die wahrgenommene Leistung abhängig von der langsamsten Komponente stoppt und beginnt, je nachdem, wie Sie die Grenzen gezogen haben. Und Grenzen ziehen ist Architektur.

Warum dies eine architektonische Entscheidung und keine endgültige Anpassung ist

Beachten Sie, dass jede der oben genannten Entscheidungen früh und nicht am Ende getroffen wurde. Wo ein Suspense-Limit platziert werden soll, welche Daten warten können und was im ersten Byte sein muss, was zwischenspeicherbar ist und wie lange: All dies prägt die Komponentenstruktur und die Art und Weise, wie Daten abgerufen werden.

Sie können auf einer Seite, die als monolithischer Block geschrieben wurde, der alles auf einmal abruft, kein „Streaming später hinzufügen“. Zum Streamen muss die Seite in unabhängigen Teilen gestaltet sein, von denen jeder seine eigene Ladegrenze hat. Diese Zerlegung ist eine Entwurfsentscheidung, die zu Beginn zusammen mit der Datenmodellierung getroffen wird.

Das Gleiche gilt für den Cache. Die Entscheidung, was aus einer gespeicherten Version bereitgestellt werden kann und was immer aktuell sein muss, bedeutet in der Praxis, die Daten Ihrer Domain nach veralteter Toleranz zu klassifizieren. Dabei handelt es sich nicht um eine Leistungsoptimierung, sondern um eine Aussage über das Unternehmen: Könnte dieser Preis schon ein paar Minuten alt sein? Dieses Gleichgewicht, nicht wahr? Diese Antworten gehören zur Architektur, und wer sie bis zum Schluss aufschiebt, stellt fest, dass das Umschreiben der Datensuchstruktur viel teurer ist, als vorher gedacht. Die Beziehung zum Rest des Frameworks wird im Next.js App Router-Handbuch klarer.

Das Risiko, das auf der schönen Folie niemand erwähnt: Missverständnisse im Cache

Cache ist der verführerischste und gefährlichste Teil. Der klassische Satz, dass die Cache-Invalidierung eines der schwierigsten Probleme beim Rechnen sei, ist kein Programmiererwitz, sondern eine Produktionsbeschreibung.

Das zentrale Problem sind alte Daten. Sobald Sie sich entscheiden, eine Antwort zu speichern, akzeptieren Sie, dass sie möglicherweise veraltet ist, wenn jemand sie erneut liest. Für Inhalte, die sich langsam ändern, großartig. Für einen Saldo, einen Lagerbestand, einen Bestellstatus bedeutet die Bereitstellung einer Version, die zu lange gespeichert wurde, dem Benutzer eine Realität zu zeigen, die nicht mehr existiert. Und die schlimmste Art dieses Fehlers ist der stille: Nichts geht kaputt, nichts gibt einen Fehler aus, der Bildschirm lügt einfach.

Next.js bietet feine Caching-Kontrollen, gerade weil diese Entscheidungen pro Daten und nicht global getroffen werden müssen. Aber eine Feinsteuerung ist ein zweischneidiges Schwert: Der Entwickler, der nicht genau weiß, auf welcher Ebene Daten gespeichert werden, wird Phantomverhalten debuggen. Warum wird diese Seite nicht aktualisiert? Weil es eine Cache-Schicht gibt, von der er vergessen hat, dass sie existiert, mit einem Ungültigmachungsschlüssel, den niemand ausgelöst hat. Wer tiefer einsteigen möchte, findet einen guten Überblick in gute Caching-Praktiken in Anwendungen.

Komplexität ist Teil des Deals

Es gibt kognitive Kosten, die ehrlich berücksichtigt werden müssen. Mit mehreren Ebenen von Caching, Streaming und Suspense-Grenzen wird das mentale Modell dessen, „was passiert, wenn der Benutzer diese Seite anfordert“, reichhaltiger und schwerer im Kopf zu behalten.

Daten können auf mehr als einer Ebene mit unterschiedlicher Lebensdauer gespeichert werden. Ein Teil der Seite wird auf dem Server gerendert und gestreamt, ein anderer Teil wird auf dem Client hydratisiert. Wenn etwas veraltet erscheint, muss die Untersuchung diese Ebenen durchgehen, um herauszufinden, wo die alte Version hängengeblieben ist. Dies erfordert, dass das Team das Modell versteht und nicht nur Konfigurationen aus einem Beispiel im Internet kopiert.

Daher lautet die praktische Empfehlung, explizit und konservativ zu sein. Beginnen Sie mit weniger Cache, als es verlockend erscheint, und fügen Sie Ebenen hinzu, wenn die Messung dies erfordert, und dokumentieren Sie die Invalidierungsstrategie für jede einzelne. Behandeln Sie aggressives Caching sensibler Daten als eine Entscheidung, die einer Begründung bedarf, und nicht als Standard. Die goldene Regel lautet: Niemand sollte mit einem Schulterzucken erklären können, warum ein Bildschirm alte Informationen anzeigt.

Was ist bei der Entscheidung zu berücksichtigen?

Durch Cache, Streaming und Suspense wurde die wahrgenommene Leistung deutlich besser, als dies mit den Finishing-Tricks der Vorgängergeneration möglich war. Der Gewinn ist konkret: Seiten, die in Teilen erscheinen, Arbeiten, die sich nicht wiederholen, Wartezeiten, die den Nutzer im schlimmsten Fall nicht ausbremsen.

Der Kontrapunkt besteht darin, dass diese Gewinne aus frühzeitig getroffenen Entscheidungen über Komponentengrenzen und die Toleranz gegenüber veralteten Daten resultieren. Sie bis zum Ende aufzuschieben ist nicht neutral: Es bedeutet, das Streaming aufzugeben und den Cache in den Bereich stiller alter Daten zu verschieben. Die wahrgenommene Leistung wurde zur Architektur, mit allem, was dies an Planung und Entwertungsdisziplin mit sich bringt.

Wenn Sie den Stack einer Anwendung Next.js definieren und den Cache-Albtraum vermeiden möchten, den niemand versteht, lohnt es sich, die Datenstrategie vor dem ersten Bildschirm zu entwerfen. Ich habe dieses Design viel diskutiert; Finden Sie mich in den Kommentaren oder in den Netzwerken zum Austausch.