Was Next.js Builds in realen Projekten verlangsamt (und wie man es behebt, ohne SEO zu verlieren)

Und wie man es behebt, ohne SEO zu verlieren

Viele Teams geben dem Framework die Schuld, wenn Production Builds langsam werden. In der Praxis ist Build-Zeit meistens ein Architekturproblem, nicht ein Next.js-Problem.

In diesem Leitfaden:

• welche Faktoren Build-Zeit in echten Projekten treiben
• warum Full-Pre-Rendering die Entwicklung ausbremst
• welche Folgen das technisch und geschäftlich hat
• wie man Build-Zeit reduziert und SEO stabil hält

Die wichtigsten Build-Zeit-Treiber

1. Zu viele statisch generierte Seiten

Der größte Faktor ist oft die Seitenanzahl, nicht die Bundle-Größe.

Wenn man komplett prerendert:

• alle Blog-Slugs
• alle Knowledge-Slugs
• alle Tag-Kombinationen
• alle Locale-Varianten

explodiert die Anzahl der Seiten pro Build.

Typisches Muster:

• 100+ Blogposts
• 30+ Knowledge-Artikel
• 150+ Tags
• 2 Locales

Das ergibt schnell hunderte Seiten pro Build, auch wenn nur eine Seite geändert wurde.

2. Übernutzung von generateStaticParams

generateStaticParams ist hilfreich, wird aber teuer, wenn jede dynamische Route vollständig vorgebaut wird. Für Long-Tail-Traffic ist das oft ineffizient.

3. Schwere Berechnungen in generateMetadata

Komplexe Metadata-Logik, wiederholte Lookups und Transformationen summieren sich über viele Seiten.

4. Full-Rebuild in jeder CI-Ausführung

Wenn jeder Commit einen vollständigen Production Build startet, wird die Pipeline zum Bottleneck.

Warum Full Builds problematisch sind

Full Builds sind nicht nur "etwas langsamer", sie erzeugen strukturelle Reibung:

1. Langsamere Feedback-Loops
   Developer warten länger auf CI und Preview-Umgebungen.

2. Niedrigere Release-Frequenz
   Teams shippen seltener, weil jeder Release-Durchlauf teurer wird.

3. Höhere Betriebskosten
   Mehr Build-Minuten, mehr Compute, mehr Queue-Druck.

4. Mehr Risiko bei Hotfixes
   Kritische Fixes brauchen länger bis in Produktion.

5. Mehr Kontextwechsel im Team
   Wartezeiten unterbrechen Fokus und reduzieren Produktivität.

Langsame Builds beeinflussen also direkt Lead Time, Stabilität und Delivery-Tempo.

SEO-Praxis: Muss wirklich alles vorgebaut werden?

Kurz: nein.

Für SEO zählen:

• crawlbare URLs
• stabiler Render-Output
• korrekte Metadata und Canonicals
• interne Verlinkung und Sitemap-Abdeckung
• akzeptable Antwortzeit

Das lässt sich auch mit ISR und On-Demand-Generierung für Long-Tail-Seiten erreichen. Alles vorzubauen ist oft nicht nötig.

Praktische Strategie

1. Nur priorisierte Seiten prerendern

Full SSG für:

• Startseite
• Kern-Service-Seiten
• kommerziell wichtige Landingpages
• kleine kuratierte Menge relevanter Artikel

2. Long-Tail-Inhalte auf ISR On-Demand verschieben

revalidate setzen und bei weniger priorisierten dynamischen Routen in generateStaticParams leer zurückgeben.

3. Metadata deterministisch und leicht halten

Teure Runtime-Transformationen vermeiden, lieber auf vorbereitete Content-Maps setzen.

4. Build-Profile trennen

Nutze:

• schnelles Build-Profil für Dev/QA
• vollständiges Profil nur dort, wo es wirklich gefordert ist

5. Vorher/Nachher messen

Wichtige Kennzahlen:

• gesamte Build-Dauer
• Anzahl statischer Seiten
• CI-Queue-Zeit
• Deploy-Frequenz

Ohne Messung bleibt Optimierung Bauchgefühl.

Beispiel aus der Praxis

Vorher:

• Full Pre-Rendering für /blog/[slug], /knowledge/[slug], /blog/tag/[tag]
• 800+ statische Seiten pro Build
• 60s+ Build-Zeit

Nachher:

• On-Demand ISR für Long-Tail-Routen
• selektives Pre-Rendering nur für priorisierte Seiten
• ~300 statische Seiten pro Build
• ~30-35s Build-Zeit

Ergebnis:

• schnellere CI-Feedback-Zyklen
• schnellere Releases
• keine SEO-Regression, wenn Sitemap, Links und Metadata sauber bleiben

Build-Performance-Checkliste

1. Wie viele statische Seiten entstehen pro Build?
2. Welche dynamischen Routen nutzen generateStaticParams?
3. Haben alle prerenderten Seiten echten Business-Impact?
4. Wird Long-Tail ohne ROI vorgebaut?
5. Werden Metadata-Berechnungen unnötig oft wiederholt?
6. Werden Builds in CI zu häufig ausgelöst?
7. Gibt es eine Trennung zwischen Priority- und Long-Tail-Seiten?
8. Sind ISR-Revalidate-Werte sinnvoll gewählt?

Fazit

Langsame Builds sind meist ein Architektursignal, kein Framework-Limit. Ziel ist nicht "alles prerendern", sondern die richtigen Seiten zum richtigen Zeitpunkt zu rendern.

Wenn man unnötige Vorab-Generierung reduziert und SEO-Grundlagen sauber hält, gewinnt man beides:

• höhere Engineering-Geschwindigkeit
• stabile organische Sichtbarkeit