Next.js-Entwickler in Stuttgart

#Next.js für Stuttgarter Unternehmen, schriftlich geplant und remote umgesetzt

Mein Name ist Mariusz Szatkowski. Seit 2006 baue ich Websites mit WordPress, heute auch Frontends mit Next.js, und zwar von Gdynia aus für Kunden in Deutschland. Mit Stuttgarter Unternehmen arbeite ich ausschließlich schriftlich: Sie beschreiben das Vorhaben, ich stelle Rückfragen per E-Mail, und Umfang und Annahmen stehen am Ende in einem Dokument. Termine vor Ort und Telefonate biete ich nicht an.

Diese Seite konzentriert sich auf vier Themen, an denen Next.js-Projekte in der Praxis am häufigsten scheitern oder unnötig teuer werden: Bilder, die die Ladezeit ruinieren, eine zweite Sprache, die nachträglich angeflanscht wird, Formulare, die mehr annehmen als sie sollten, und Tracking, das vor der Einwilligung lädt. Zu allen vier Punkten zitiere ich die Dokumentation von Next.js oder den Gesetzestext, damit Sie die Grundlage selbst nachlesen können. Die Dokumentation trug beim Schreiben im November 2026 die Version 16.4.6.

#Warum Stuttgarter Websites oft zwei Sprachen brauchen

Das Statistische Amt der Landeshauptstadt nennt in “Stuttgart in Zahlen” (Stand 8. Oktober 2026) mehr als 600.000 Einwohnerinnen und Einwohner und einen Anteil von etwa 48 Prozent mit Migrationshintergrund (stuttgart.de). Dieselbe Seite meldet für 2022 rund 538.000 Erwerbstätige am Arbeitsort Stuttgart, davon fast 15 Prozent im Produzierenden Gewerbe, und für 2023 über 60 Prozent Einpendler unter den sozialversicherungspflichtig Beschäftigten. Über ein Drittel der Beschäftigten hat eine akademische Ausbildung. Für 2023 verzeichnet das Amt außerdem über 4 Millionen Übernachtungen in knapp 170 geöffneten Betrieben, von Geschäftsreisenden und Touristen.

Für ein Frontend heißt das: Wer in Stuttgart Fachkräfte sucht, Geschäftskunden aus dem Ausland bedient oder Gäste anspricht, liest seine Zielgruppe nicht nur auf Deutsch. Wie selbstverständlich das hier ist, zeigt das Welcome Center Stuttgart am Charlottenplatz 17. Es ist eine gemeinsame Anlaufstelle der Landeshauptstadt und der Wirtschaftsförderung Region Stuttgart für Neubürgerinnen, Neubürger und internationale Fachkräfte, und seine Website ist in sechs Sprachen umschaltbar (welcome-center-stuttgart.de). Eine Karriereseite oder ein Händlerportal, das Englisch erst im zweiten Jahr bekommt, muss dann meistens umgebaut werden. Plant man die Sprache von Anfang an in die Routen ein, kostet sie kaum Mehraufwand.

Foto: Bigbossfarin, CC0, Wikimedia Commons.

#Deutsch und Englisch im App Router

Die Next.js-Anleitung zur Internationalisierung empfiehlt, die Sprache aus den Browsereinstellungen abzuleiten: Der Header Accept-Language verrät, was ein Besucher bevorzugt. Eine proxy.js prüft beim Aufruf, ob im Pfad schon eine unterstützte Sprache steht, und leitet sonst um, etwa von /produkte auf /de/produkte (Internationalization). Die Routen können über Unterpfade (/en/...) oder über eigene Domains laufen; beides ist dort beschrieben.

So setze ich das für ein zweisprachiges Projekt um:

1. Alle Seiten unter app/[lang]. Damit erhält jedes Layout und jede Seite den Parameter lang, und das Wurzel-Layout setzt <html lang> passend.
2. Wörterbücher auf dem Server. Übersetzungen liegen als JSON-Dateien je Sprache und werden in Server Components geladen. Laut Dokumentation landet dadurch nur das fertige HTML im Browser, nicht die Übersetzungsdateien im JavaScript-Bundle.
3. Unbekannte Sprachen abfangen. Ruft jemand /fr/... auf, obwohl es kein Französisch gibt, liefert notFound() eine echte 404-Seite statt einer leeren Vorlage.
4. Sprache ohne Durchreichen. Die Dokumentation beschreibt next/root-params: Jede Server Component kann die Sprache direkt lesen, ohne dass sie durch zehn Komponenten weitergegeben werden muss. Die Anleitung wurde am 6. November 2026 zuletzt aktualisiert.
5. Statisch vorbauen. Mit generateStaticParams werden die Seiten für de und en beim Build erzeugt.

Was das Framework nicht entscheidet: welche Inhalte es überhaupt auf Englisch gibt. Eine englische Version mit drei übersetzten Seiten und vierzig deutschen Fallbacks schadet mehr, als sie nützt. Deshalb steht im Umfang eine Liste, welche Seiten in welcher Sprache erscheinen, und was mit Seiten passiert, die es nur auf Deutsch gibt.

#Bilder, die nicht bremsen

Auf vielen Unternehmensseiten ist das größte Element beim Laden ein Bild: das Titelfoto, ein Produkt, ein Team. Die Komponente next/image erweitert das HTML-Element <img> um automatisch passende Größen, moderne Formate wie WebP, Schutz vor Layoutverschiebungen und natives Lazy Loading (Image Optimization). Damit diese Vorteile auch ankommen, achte ich auf folgende Einstellungen aus der Referenz zur Image-Komponente:

Zwei Hinweise aus der Referenz sind für Eigenbetrieb wichtig. Steht ein Proxy oder CDN vor Next.js, muss er den Header Accept weiterreichen, sonst bekommt jeder Browser dasselbe Format. Und der Standard-Loader schickt keine Header mit, wenn er das Originalbild holt; Bilder hinter einem Login lassen sich deshalb nicht über die eingebaute Optimierung ausliefern.

Gemessen wird gegen die offiziellen Schwellen für Core Web Vitals auf web.dev: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1. Eigene Versprechen über Ladezeiten mache ich nicht; die Werte kommen aus Messungen auf Ihrer Testumgebung und später aus Felddaten.

Foto: qwesy qwesy, CC BY 3.0, Wikimedia Commons.

#Formulare mit Server Actions, ohne offene Türen

Kontaktanfragen, Bewerbungen, Händlerregistrierung, Angebotsanfragen: In Next.js laufen solche Formulare heute meist über Server Actions. Das Formular ruft eine Funktion auf dem Server auf, die das FormData-Objekt erhält (Forms). Das ist bequem, hat aber eine Eigenschaft, die viele Teams übersehen.

Die Anleitung Data Security sagt es deutlich: Eine exportierte Server Action ist per direktem POST erreichbar, nicht nur über die Oberfläche. Next.js erzeugt verschlüsselte, nicht vorhersagbare IDs, die höchstens 14 Tage im Cache bleiben, und entfernt ungenutzte Aktionen beim Build. Trotzdem gilt jede Aktion als eigener Einstiegspunkt. Eine Login-Prüfung auf der Seite schützt die Aktion darin nicht.

Daraus folgt meine Prüfliste für jede Server Action:

• Wer fragt an? Die Sitzung wird in der Aktion selbst geprüft, nicht nur im Layout.
• Darf diese Person dieses Objekt ändern? Die Dokumentation nennt das Risiko beim Namen: Insecure Direct Object Reference. Ein Händler darf nur seine eigenen Bestellungen sehen, auch wenn er eine fremde ID in die Anfrage schreibt.
• Stimmen die Eingaben? Validierung auf dem Server mit Zod oder Valibot, Fehlermeldungen über useActionState zurück an das Formular. Die HTML-Attribute required und type="email" sind eine Hilfe für Nutzer, kein Schutz.
• Was geht zurück? Rückgabewerte werden serialisiert und an den Browser geschickt. Ich gebe nur zurück, was die Oberfläche braucht, nie einen kompletten Datenbankdatensatz.
• Wie oft darf jemand senden? Für teure Vorgänge wie E-Mail-Versand empfiehlt die Dokumentation eine Begrenzung der Anfragen.

Zwei Einstellungen gehören zum Betrieb. Server Actions vergleichen den Header Origin mit Host oder X-Forwarded-Host und brechen bei Abweichung ab; liegt ein Reverse Proxy mit anderer Adresse davor, kommt die Liste serverActions.allowedOrigins in die Konfiguration. Und der Request-Body ist standardmäßig auf 1 MB begrenzt (serverActions). Für ein Bewerbungsformular mit Lebenslauf als PDF reicht das oft nicht, und die Grenze gilt für den rohen Body einschließlich der Multipart-Verpackung. Läuft die Anwendung auf mehreren eigenen Servern, setze ich zusätzlich NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, damit alle Instanzen denselben Schlüssel für die verschlüsselten Closure-Variablen verwenden.

#Analytics und Einwilligung im Next.js-Frontend

§ 25 TDDDG erlaubt das Speichern von Informationen im Endgerät und den Zugriff darauf nur nach Einwilligung auf Grundlage klarer und umfassender Informationen. Ausnahmen gibt es für die Übertragung einer Nachricht und für das, was unbedingt erforderlich ist, damit ein ausdrücklich gewünschter Dienst funktioniert. Ein Statistik-Tag fällt in der Regel nicht darunter.

Für die technische Seite ist wichtig, wie Next.js Skripte lädt. Die Script-Komponente kennt vier Strategien: beforeInteractive, afterInteractive (Standard), lazyOnload und experimentell worker. Als Beispiele für beforeInteractive nennt die Dokumentation ausdrücklich Cookie-Consent-Manager. Sie weist außerdem darauf hin, dass diese Skripte einmal pro Dokument laufen und bei einer clientseitigen Navigation nicht erneut starten, auch nicht beim Wechsel von /en zu /de. Bei einer zweisprachigen Seite muss das Einwilligungsbanner also selbst die Sprache wechseln können.

Das Paket @next/third-parties bietet fertige Komponenten für Google Tag Manager und Google Analytics, die das Skript nach der Hydration laden (Third Party Libraries). Die Dokumentation bezeichnet es als experimentell. Ich binde solche Komponenten erst ein, wenn die Einwilligung vorliegt, und trenne in der Konfiguration klar zwischen notwendigen und zustimmungspflichtigen Diensten.

Mit § 26 TDDDG hat der Gesetzgeber anerkannte Dienste zur Einwilligungsverwaltung vorgesehen. Die Details regelt die Einwilligungsverwaltungsverordnung. Nach § 1 Absatz 2 EinwV bleibt der Anbieter des digitalen Dienstes aber selbst verantwortlich für Informationspflichten und eine wirksame Einwilligung. Ein externer Dienst nimmt Ihnen diese Pflicht also nicht ab.

Die Aufsicht sitzt in Stuttgart selbst: Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat seit dem 22. Dezember 2025 seine Adresse in der Heilbronner Straße 35. Vom 1. Januar bis 31. Dezember 2026 führt er den Vorsitz der Datenschutzkonferenz, und die 111. Datenschutzkonferenz tagte vom 16. bis 18. Juni 2026 in Stuttgart (LfDI BW, DSK-Vorsitz 2026). Wenn ein Analytics-Dienst oder ein Bild-CDN Daten in die USA überträgt, ist die Handreichung des LfDI zu Kapitel V der DS-GVO ein guter Ausgangspunkt. Sie bezieht sich auf den Angemessenheitsbeschluss der EU-Kommission vom 10. Juli 2023, der Übermittlungen an selbstzertifizierte US-Organisationen auf der Liste des US-Handelsministeriums erlaubt (LfDI BW, Drittstaatentransfer). Ob ein Anbieter auf dieser Liste steht, prüft Ihr Datenschutzbeauftragter vor dem Start; ich baue die Einbindung so, dass sie sich ohne Umbau austauschen lässt.

#Vom ersten Satz bis zur Abnahme

1. Ihre Beschreibung. Per Kontaktformular oder E-Mail: was gebaut oder geändert werden soll, für wen, bis wann.
2. Meine Rückfragen, schriftlich. Meist geht es um Sprachen, Formulare, Datenquellen und Hosting.
3. Umfang als Dokument. Darin stehen Leistungen, Ausschlüsse, Annahmen und wer was liefert. Erst nach Ihrer schriftlichen Bestätigung fange ich an. Was später dazukommt, bekommt eine eigene Einschätzung.
4. Staging. Jede Änderung läuft zuerst auf einer Testumgebung, auf die Sie Zugriff haben.
5. Abnahme gegen den Umfang. Sie prüfen Punkt für Punkt; offene Punkte schicken Sie mir als Liste.
6. Nach dem Start. Updates und kleine Änderungen kann ich in einem eigenen Wartungsvertrag übernehmen. Wie das aussieht, steht auf der Seite Wartung und Support in Stuttgart.

Ihr Beitrag zum Start: Gestaltung, Mockups und Wireframes kommen von Ihnen oder Ihrer Agentur; ich entwerfe keine Oberflächen, sondern setze sie als funktionierendes, responsives Frontend um. Wenn noch kein Entwurf existiert, markieren Sie in meiner Tabellenvorlage pro Ansicht, welches Element wohin gehört. Dazu brauche ich Zugang zu Repository und Hosting, die Texte in beiden Sprachen oder die Angabe, wer sie liefert, und die Namen der Dienste, die eingebunden werden sollen.

#Vor dem Projekt: zehn Fragen zum Abhaken

#Verwandte Seiten für Stuttgart

• WordPress Entwickler in Stuttgart: wenn ein klassisches WordPress ohne getrenntes Frontend genügt.
• Astro Entwickler in Stuttgart: für Inhaltsseiten mit wenig Interaktion.
• Migration von Next.js zu Astro in Stuttgart: wenn ein bestehendes Next.js mehr Framework ist als nötig.
• PHP Entwickler in Stuttgart: wenn ein Laravel- oder Symfony-Backend die Daten liefert.
• WooCommerce Entwickler in Stuttgart: für Shops, die in WooCommerce bleiben.
• Headless CMS Entwickler: Überblick, wann ein getrenntes Frontend vor einem CMS sinnvoll ist.

#Fragen aus Stuttgarter Anfragen

#Brauche ich für Deutsch und Englisch zwei Domains?

Nein. Next.js unterstützt laut Dokumentation beide Wege: Unterpfade wie /en/produkte oder eine eigene Domain je Sprache. Unterpfade sind einfacher zu betreiben, weil es nur ein Zertifikat, ein Hosting und eine Search-Console-Property gibt. Eigene Domains lohnen sich, wenn Sie in einem Land mit eigener Marke oder eigenem Impressum auftreten.

#Woher weiß die Seite, welche Sprache ein Besucher sehen will?

Der Browser schickt seine Spracheinstellung im Header Accept-Language mit. Eine Proxy-Datei in Next.js liest ihn beim ersten Aufruf und leitet auf den passenden Pfad um. Danach entscheidet der Besucher selbst über den Sprachumschalter, und diese Wahl hat Vorrang vor der Automatik.

#Sind Formulare mit Server Actions automatisch sicher?

Nicht automatisch. Next.js verschlüsselt die IDs der Aktionen und vergleicht Origin und Host, aber jede Server Action bleibt per direktem POST erreichbar. Deshalb prüfe ich in jeder Aktion selbst, wer anfragt, ob diese Person das betroffene Objekt ändern darf und ob die Eingaben dem Schema entsprechen.

#Darf Google Analytics laden, bevor der Besucher zugestimmt hat?

Nach § 25 TDDDG nicht, sobald dafür Informationen im Endgerät gespeichert oder ausgelesen werden und das für den gewünschten Dienst nicht unbedingt erforderlich ist. Im Frontend heißt das: Der Tag wird erst nach der Einwilligung eingebunden, und ein Widerruf muss genauso einfach sein. Die rechtliche Bewertung Ihres Falls bleibt bei Ihrer Rechtsberatung.

#Werden meine Produktfotos durch Next.js automatisch kleiner?

Ja, wenn sie über die Komponente next/image laufen. Sie liefert pro Gerät eine passende Größe, standardmäßig als WebP, und lädt Bilder außerhalb des sichtbaren Bereichs erst später. Fotos von fremden Servern werden nur verarbeitet, wenn deren Adresse in einer Freigabeliste steht.

#Was soll ich Ihnen zuerst schicken?

Die Adresse Ihrer heutigen Website, das Ziel des Projekts, den Termin und den eingesetzten Stack. Wenn es ein Layout gibt, legen Sie es bei; die Platzierung der Elemente liefern Sie, ich setze sie um. Mehr brauche ich für eine erste schriftliche Einschätzung nicht.

#Ihr Next.js-Vorhaben in Stuttgart

Ob zweisprachige Karriereseite, Händlerportal mit Login oder ein Frontend, dessen Bilder und Formulare endlich sauber laufen sollen: Schreiben Sie mir über das Kontaktformular. Nennen Sie die Adresse Ihrer aktuellen Website, das Ziel, den gewünschten Termin und den Stack, mit dem Sie heute arbeiten. Gibt es schon Anforderungen an Sprachen, Formulare oder Tracking, hängen Sie sie gern an. Ich antworte an Werktagen schriftlich mit Rückfragen oder einer ersten Einschätzung, und diese erste schriftliche Einschätzung ist kostenlos.