Zum Inhalt springen

Next.js Performance-Engineering

Core-Web-Vitals-Arbeit an bestehenden Next.js-Anwendungen — gemessen an Felddaten, an der architektonischen Ursache behoben und in der CI verteidigt, damit die Zahlen behoben bleiben.

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.

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.

Häufige Fragen

Arbeiten Sie mit Lighthouse-Scores?
Nicht als primäres Signal. Lighthouse ist ein Laborwerkzeug und nützlich, um ein Problem zu reproduzieren, aber Rankings und Umsatz folgen den Felddaten. Wir beginnen mit dem Chrome UX Report und Ihrem Real-User-Monitoring und nutzen das Labor dann zur Ursachenisolierung.
Was, wenn das Problem unser CMS oder unsere Drittanbieter-Skripte sind?
Dann ist das der Befund. Ein großer Teil der LCP- und INP-Regressionen, die wir zurückverfolgen, endet bei einem Tag-Manager, einem Chat-Widget oder einer unoptimierten Medien-Pipeline statt im Anwendungscode. Wir berichten die Ursache, die wir finden, nicht die bequeme.
Können Sie einen Score garantieren?
Wir vereinbaren mit Ihnen ein Ziel auf Basis von Felddaten und sagen Ihnen vorab, ob es in der bestehenden Architektur erreichbar ist. Wenn nicht, lautet die ehrliche Antwort: Neubau der betroffenen Route — und das sagen wir dann auch.