Next.js-Performance-Audit
Scanverra prüft, wie deine Next.js-App rendert - server-seitig, statisch oder client-seitig - und markiert die next/image-, Metadata-API- und Hydration-Probleme, die dich still und leise Core-Web-Vitals-Punkte kosten.
Was wir für Next.js prüfen
Sechs Prüfungen speziell dafür, wie der App Router tatsächlich rendert und Code ausliefert.
Rendering-Strategie pro Route
Ob eine Route serverseitig gerendert, statisch generiert oder als leere Hülle ausgeliefert wird, die sich client-seitig füllt - und ob diese Wahl zum Inhalt passt. Eine Marketing-Seite, die komplett client-seitig gerendert wird, gibt einem Crawler beim ersten Paint nichts zu lesen.
next/image-Nutzung
Rohe img-Tags anstelle von next/image sowie Bilder ohne width/height (oder fill) - die Kombination, die Layout-Shift verursacht, wenn Bilder erst nachträglich in ihrer tatsächlichen Größe erscheinen.
Abdeckung der Metadata API
Title, Description, Canonical-Tag und Open-Graph-Daten pro Route im Vergleich zu einem einzigen wiederverwendeten - oder fehlenden - Root-Metadata-Export über alle Seiten hinweg.
Aufteilung Client- vs. Server-Komponenten
Unnötige "use client"-Direktiven, die zu weit oben im Komponentenbaum gesetzt sind und einen ganzen Teilbaum - samt allem, was er importiert - in das Browser-Bundle ziehen, obwohl nur ein kleiner interaktiver Teil nötig gewesen wäre.
Hydration-Mismatches
Server-gerendertes Markup, das nicht mit dem übereinstimmt, was React client-seitig erzeugt - oft verursacht durch Date.now(), Math.random() oder eine browser-only API, die während des Renderns aufgerufen wird. Diese zeigen sich als Konsolenfehler und drücken den Best-Practices-Score.
Sicherheits-Header auf Response-Ebene
Ob HSTS, X-Frame-Options und ähnliche Header global gesetzt sind - Next.js erlaubt dir, das einmal in der headers()-Funktion von next.config zu erledigen, statt jede Route auf ihre Standardwerte zu belassen.
How it works
Drei Schritte von der URL zu Next.js-spezifischen Fixes.
Deine Next.js-URL einfügen
Kein Repo-Zugriff und kein Build-Schritt nötig - wir scannen die live veröffentlichte Seite genauso, wie es ein Browser oder Crawler tun würde.
Wir bestätigen die App-Router-Signale
Response-Header wie x-powered-by: Next.js, /_next/static/-Asset-Pfade und das __NEXT_DATA__-Payload zeigen uns, dass wir es mit einer Next.js-App zu tun haben, bevor das Audit läuft.
Next.js-spezifische Fixes erhalten
Jedes Problem wird für das Framework geschrieben, das du tatsächlich einsetzt - Hinweise zu next/image und der Metadata API, keine allgemeinen Ratschläge.
Häufig gestellte Fragen
Es erkennt anhand von Response-Headern und Build-Asset-Pfaden, dass eine Website mit Next.js läuft, und wendet dann Prüfungen an, die für beide Router funktionieren - es muss die beiden nicht unterscheiden, um Rendering, Bilder und Metadaten zu prüfen.
Ja. Nicht optimierte Bilder und Bilder ohne width/height erscheinen als Core-Web-Vitals- und Best-Practice-Probleme, jeweils mit einer Korrektur für Ihr Setup.
Das Audit untersucht das HTML, das beim ersten Laden tatsächlich ausgeliefert wird. Eine Seite mit wenig oder keinem Inhalt, bevor JavaScript läuft, wird als Content-Visibility- und SEO-Problem angezeigt - meist ein Zeichen dafür, dass sie client-seitig rendert, ohne serverseitige Grundlage darunter.
Es prüft das Ergebnis - Title, Meta-Description, Canonical-Tag und Open-Graph-Daten auf der gerenderten Seite -, unabhängig davon, ob du diese mit der Metadata API, einer Head-Komponente oder fest codierten Tags erzeugt hast.
Konsolenfehler sind Teil des Best-Practices-Scores, und Hydration-Mismatches sind eine der häufigeren Arten, wie sie in einer Next.js-App auftreten.
Ja - Scanverra scannt eine live, öffentlich erreichbare URL. Eine localhost-Adresse oder ein passwortgeschütztes Preview-Deployment funktioniert nicht.
Weitere Technologie-Audits
Sieh deine Next.js-Core-Web-Vitals in unter einer Minute
Rendering, Bilder, Metadaten und Hydration - bewertet und erklärt anhand des Frameworks, das du tatsächlich ausgeliefert hast.
Kostenlosen Audit starten