Next.js Performance-Engineering

Performance-Arbeit hat einen typischen Fehlermodus: Ein Team investiert einen Sprint in Optimierung, der Score springt, und sechs Wochen später ist er wieder da, wo er war. An den Fixes war nichts falsch. Es fehlte der Mechanismus, sie zu halten.

Wie ein Projekt abläuft

Zuerst messen, im Feld. Wir beginnen mit Chrome-UX-Report-Daten und Ihrem RUM, segmentiert nach Geräteklasse und Routen-Template. Ein p75-LCP von 3,4 s auf mobilen Produktseiten ist eine handlungsfähige Aussage; „unser Lighthouse-Score ist 62" ist es nicht.

Die Ursache finden, nicht das Symptom. Ein langsames LCP ist eine Rendering-Entscheidung, eine Font-Strategie, eine Bild-Pipeline oder ein blockierender Drittanbieter. Ein schlechtes INP ist fast immer Umfang und Zuschnitt des JavaScripts, das oberhalb der Falz hydratisiert. Wir führen jede Metrik auf die konkrete Entscheidung auf Commit-Ebene zurück, die sie erzeugt hat.

Auf architektonischer Ebene beheben. Eine Komponente über die Servergrenze verschieben, einen clientseitigen Datenabruf entfernen, der ein Server-Render hätte sein sollen, eine 300 KB große Datumsbibliothek ersetzen, eine Route aufteilen, die das gesamte Admin-Bundle an anonyme Besucher ausliefert. Das sind die Änderungen, die halten.

Das Ergebnis verteidigen. Jedes Projekt endet mit einem in der CI durchgesetzten Performance-Budget. Ein Pull Request, der das Routen-Bundle über seine Obergrenze drückt, lässt die Prüfung scheitern. Das Budget ist das Ergebnis; der Score ist ein Nebeneffekt.

Warum der Score zurückkommt

Weil ein Score ein Ergebnis ist und niemand ein Ergebnis besitzt. Ein Budget ist eine Zahl in einer Datei, von einer Maschine geprüft, bei jedem Pull Request, und es lässt den Build derjenigen scheitern, die es überschritten haben - solange sie sich noch erinnern, was sie geändert haben.

Dieser Unterschied ist der ganze Grund, warum das zweite Projekt meist ausbleibt. Optimierung ohne Budget ist ein Kredit auf das nächste Quartal: dieselbe Komponente bekommt ein use client, das sie nicht braucht, dieselbe Bibliothek wird auf oberster Ebene importiert, und die Regression kommt Commit für Commit zurück - von Leuten, die es nicht wissen konnten.

Damit ein Budget wirkt, muss es das Richtige messen. Eine Obergrenze für die gesamte Build-Ausgabe sagt nichts, weil der Build Code enthält, den keine Route lädt. Was wir setzen, ist eine Obergrenze pro Route für das gzippte JavaScript, das das HTML dieser Route tatsächlich anfordert - die Zahl, die ein Besucher bezahlt.

Wo die Zeit tatsächlich hingeht

Über die Projekte hinweg, die wir durchführen, häufen sich die Ursachen:

Eine zu hoch gezogene Client-Grenze. Eine Direktive an einem Layout liefert dieses Layout und alles darunter an jeden Besucher jeder Route darunter aus. Es ist die häufigste Ursache für ein schlechtes INP in einer Next.js-Anwendung - und meist eine einzige Zeile. Wo die Grenze hingehört.

Eine Bild-Pipeline, die überall optimiert ist außer an der einen Stelle, auf die es ankommt. Das LCP-Bild lazy geladen, ohne Maße, oder über eine Transformation ausgeliefert, die 300 ms vor dem ersten Byte hinzufügt. Was das kostet, und die Lösung.

Eine Route, die dynamisch wurde, ohne dass jemand das entschieden hat. Ein einziger cookies()-Aufruf in einer geteilten Komponente nimmt jede Route darunter vom statischen Rendering aus, und das CDN antwortet nicht mehr. Die Seite wurde nicht wegen ihres Codes langsamer; sie wurde langsamer, weil sie aufgehört hat, gecacht zu werden.

Drittanbieter, geladen als wären sie kostenlos. Ein Tag Manager, der vier weitere Skripte nachzieht, ein Chat-Widget, das vor dem Inhalt hydratisiert, ein Consent-Banner, das das Rendering blockiert, das es eigentlich nur gaten sollte. Das ist kein Anwendungscode - genau deshalb profiliert es niemand.

Fonts, die den Text blockieren, für den sie da sind. Ein selbst gehosteter Font ohne font-display, oder drei Schnitte geladen, wo oberhalb der Falz einer verwendet wird.

Was wir nicht tun

Wir optimieren nicht gegen einen Laborwert, den Sie vorab gewählt haben. Wenn Ihre Felddaten sagen, dass es für Besucher in Ordnung ist, und ein Werkzeug 62 anzeigt, lautet die ehrliche Antwort, dass das Werkzeug ein Gerät und ein Netz misst, das Ihr Publikum nicht hat - und wir sagen Ihnen das, statt einen Sprint zu verkaufen.

Wir umgehen auch keine Ursache, die wir nicht beheben können, indem wir etwas anderes schneller machen. Wenn das LCP-Problem ein Drittanbieter ist, den Ihr Marketing braucht, steht das im Befund, und die Entscheidung über diesen Kompromiss gehört Ihnen - statt in einer Zusammenfassung vergraben zu werden.

Was Sie erhalten

Ein priorisiertes Befunddokument, in dem jedes Problem auf seine Ursache zurückgeführt und nach Aufwand bewertet ist, die umgesetzten Fixes als prüfbare Pull Requests, die CI-Budget-Konfiguration und einen Vorher-Nachher-Vergleich auf Felddaten, sobald die Änderung lange genug live war, um das 28-Tage-Fenster zu bewegen.

Wenn die Architektur selbst die Obergrenze ist - und bei manchen Anwendungen ist sie das -, steht auch das im Befund, mit den Kosten der Alternative daneben. Dieses Gespräch gehört an den Anfang eines Projekts, nicht an dessen Ende.