Next.js-Entwickler in Augsburg

#Next.js in Augsburg: Cache und Revalidierung, schriftlich geplant

Ich bin Mariusz Szatkowski und baue seit 2006 Websites mit WordPress, heute auch Frontends mit Next.js. Ich arbeite von Gdynia aus, remote und schriftlich: Sie beschreiben das Vorhaben, ich stelle Rückfragen per E-Mail, Umfang und Annahmen stehen am Ende in einem Dokument. Besuche vor Ort und Telefonate gibt es bei mir nicht.

Diese Seite behandelt ein Thema, an dem Redaktionen und Entwickler am häufigsten aneinander vorbeireden: Was speichert Next.js zwischen, wann wird neu gerendert, und wie sieht die Redaktion eine Änderung, ohne auf den nächsten Build zu warten? Grundlage sind die Dokumentation auf nextjs.org und die Upgrade-Leitfäden, die ich am 11. November 2026 abgerufen habe. Die Dokumentation trug an diesem Tag die Version 16.4.6; laut npm-Registry erschien diese Version am 9. November 2026.

#Warum Inhalte in Augsburg ein Verfallsdatum haben

Die Startseite der Technischen Hochschule Augsburg verwies am 11. November 2026 auf die Public Climate School vom 9. bis 13. November 2026, die Hochschule und Universität gemeinsam mit der Stadt Augsburg ausrichteten, und auf den Tag der Lehre am 26. November 2026 (hs-augsburg.de). Solche Hinweise müssen pünktlich erscheinen und nach dem Termin wieder verschwinden. Ob das klappt, hängt nicht vom Design ab, sondern davon, wie die Seite zwischengespeichert wird.

Für Unternehmen in Augsburg gilt dasselbe im Kleinen: ein Hinweis auf eine Betriebsferien-Regelung, eine geänderte Öffnungszeit, ein ausverkauftes Produkt. Die Redaktion will das sofort live sehen, die Besucher sollen trotzdem eine schnelle Seite bekommen. Beides geht zusammen, wenn jede Art von Inhalt bewusst eine Lebensdauer bekommt.

Foto: User:Neitram, CC BY-SA 4.0, Wikimedia Commons.

#Was Next.js standardmäßig zwischenspeichert, Version für Version

Wer mit alten Erfahrungen an eine neue Version geht, wird überrascht. Die Standardwerte haben sich zweimal gedreht:

Belege: Upgrade auf 15 und Upgrade auf 16. Der Leitfaden zu Version 15 schreibt, dass fetch-Anfragen “no longer cached by default” sind; wer sie weiter cachen will, setzt cache: 'force-cache'. Für den Client-Cache gab es zunächst den experimentellen Schalter staleTimes.

Die Seite zum Caching, zuletzt am 6. Oktober 2026 aktualisiert, beschreibt nur noch das neue Modell. Neue Apps mit den empfohlenen create-next-app-Voreinstellungen haben Cache Components und Partial Prefetching schon aktiv, und beide sollen in der nächsten Hauptversion überall gelten.

Was das praktisch heißt: In einem Projekt, das ich übernehme, prüfe ich als Erstes, ob cacheComponents in der next.config.ts steht. Davon hängt ab, welches Modell gilt und welche der folgenden Abschnitte auf Ihr Projekt zutreffen.

#use cache: eine Lebensdauer pro Inhalt

Mit Cache Components wird nichts mehr stillschweigend zwischengespeichert. Die Direktive use cache markiert eine asynchrone Funktion oder Komponente als cachebar, und der Rückgabewert bekommt eine Lebensdauer (Caching, use cache):

import { cacheLife, cacheTag } from 'next/cache'

export async function getAnnouncements() {
  'use cache'
  cacheLife('hours')
  cacheTag('announcements')
  return db.query('SELECT * FROM announcements')
}

Die Dokumentation empfiehlt, jede Direktive mit einem cacheLife zu kombinieren; ohne gilt das Profil default. Die Profile aus der Revalidierungs-Anleitung:

Wer feiner steuern will, übergibt ein Objekt mit stale, revalidate und expire in Sekunden. Zwei Regeln aus der Dokumentation entscheiden im Alltag über Fehler:

• Kurzlebige Caches fallen aus dem Vorab-Rendering. Als kurzlebig gilt das Profil seconds, revalidate: 0 oder ein expire unter 5 Minuten. Solche Inhalte werden dynamische Lücken statt Teil der statischen Hülle.
• Laufzeitdaten kommen als Argument hinein. Innerhalb von use cache sind cookies(), headers() und searchParams verboten. Die Werte werden außerhalb gelesen und übergeben; sie werden Teil des Cache-Schlüssels, genau wie Argumente und aus dem Umfeld erfasste Variablen. Auch die Build-ID gehört zum Schlüssel.

Ein Hinweis zur Seitenstruktur: Je tiefer ein Zugriff auf Laufzeitdaten im Komponentenbaum sitzt, desto mehr der Seite bleibt Teil der statischen Hülle. Die Dokumentation beschreibt das als “Maximizing the static shell”. Ich lege Seiten deshalb so an, dass Kopfbereich, Navigation und redaktioneller Text fest sind und nur kleine Inseln wie ein Warenkorbsymbol oder eine Begrüßung hinter <Suspense> laufen.

#Nach Zeit oder auf Zuruf: revalidateTag, updateTag, revalidatePath

Die Revalidierung kennt zwei Wege: zeitbasiert über cacheLife und auf Anforderung über drei Funktionen.

Drei Punkte, die in der Praxis Zeit kosten:

1. Version 16 verlangt ein zweites Argument. Die Form revalidateTag('posts') ist veraltet; der Upgrade-Leitfaden nennt revalidateTag('posts', 'max') als Ersatz und updateTag für sofortigen Verfall.
2. Die Revalidierung läuft beim nächsten Aufruf, nicht beim Funktionsaufruf. Laut Dokumentation wird sie von einer Anfrage ausgelöst. Mit max sieht der erste Besucher nach dem Veröffentlichen also noch den alten Stand, bis die neue Version bereitsteht.
3. revalidatePath erwartet den Pfad der Routendatei. Bei einer Umschreibung von /blog auf /news ist /news richtig, nicht die Adresse aus der Browserzeile. Die Dokumentation rät außerdem, Tags dem Pfad vorzuziehen, weil sie genauer sind.

Für ein CMS, das Inhalte nur selten ändert, empfiehlt die Dokumentation, Tag und ein langes cacheLife wie max zu verbinden und das CMS per Webhook revalidateTag auslösen zu lassen. Das spart zeitbasierte Neuberechnungen für Inhalte, die sich nicht geändert haben. Ein Webhook kommt von außen und kann updateTag nicht nutzen; dort bekommt revalidateTag den Wert { expire: 0 }, wenn der Eintrag sofort verfallen soll. Ein Route Handler dafür ist kurz, braucht aber ein Geheimnis, das nur CMS und Anwendung kennen:

import { revalidateTag } from 'next/cache'

export async function POST(request: Request) {
  const secret = request.headers.get('x-revalidate-secret')
  const { tag } = await request.json()
  if (secret !== process.env.REVALIDATE_SECRET || typeof tag !== 'string') {
    return new Response('Invalid request', { status: 401 })
  }
  revalidateTag(tag, { expire: 0 })
  return Response.json({ revalidated: true })
}

Welche der beiden Varianten ich einsetze, hängt von der Redaktion ab. Bei einem Beitragsarchiv genügt max: Der erste Leser sieht einen Moment lang den alten Text, alle folgenden den neuen. Bei einer Preisliste, einem Lagerbestand oder einem Hinweis mit Enddatum setze ich expire: 0, weil ein veralteter Stand dort mehr schadet als eine kurze Wartezeit.

#Wie die Redaktion Änderungen sofort sieht: Draft Mode

Auch ein gut getakteter Cache hilft nicht, wenn eine Redakteurin vor der Veröffentlichung prüfen will, wie ihr Text aussieht. Dafür gibt es den Draft Mode. Die Anleitung beschreibt ihn so: Solange ein Redakteur ihn aktiv hat, werden zwischengespeicherte oder vorgerenderte Inhalte umgangen und direkt beim Ursprung geholt; andere Besucher sehen weiter die zwischengespeicherte Version. Konkret passiert Folgendes:

• fetch()-Anfragen umgehen den Next.js-Cache.
• Komponenten und Funktionen mit use cache laufen bei jeder Anfrage neu, ihre Ergebnisse werden nicht gespeichert.
• Die Seite wird mit Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate ausgeliefert.

Das CMS bekommt dafür eine Vorschau-Adresse, die einen Route Handler der Anwendung aufruft. Der Handler setzt ein Cookie namens __prerender_bypass. Die Anleitung nennt zwei Sicherungen, die ich nie weglasse: ein gemeinsames Geheimnis, damit nicht jeder den Draft Mode einschalten kann, und die Weiterleitung auf den Pfad aus den CMS-Daten statt auf einen Parameter aus der Adresse, um offene Weiterleitungen zu vermeiden. Außerdem darf enable() nicht innerhalb eines use cache-Bereichs stehen, nur in einem Route Handler oder einer Server Action.

Der Vorteil für Ihr Team: Die Redaktion muss keine Wartezeit einplanen, und niemand baut für eine Vorschau eine zweite Umgebung. Ob das mit Ihrem CMS geht, hängt davon ab, ob es konfigurierbare Vorschau-Adressen kennt; die Anleitung setzt das voraus. Bei WordPress als Redaktionssystem ist das meist eine Frage des Plugins und der Konfiguration, wie ich sie auf der Seite zu Headless CMS beschreibe.

#Wo der Cache liegt, und warum das auf das Hosting ankommt

Die Caching-Seite nennt drei Orte, an denen ein Ergebnis liegen kann: vorgerendertes HTML auf der Festplatte oder im dauerhaften Speicher der Plattform hinter einem CDN, ein gemeinsamer Speicher und der Browser. Der gemeinsame Speicher ist standardmäßig ein flüchtiger Arbeitsspeicher je Instanz. Die Dokumentation zu use cache, zuletzt am 6. November 2026 aktualisiert, unterscheidet zwei Umgebungen:

Anbieter können den Standard-Handler ersetzen, und manche speichern Laufzeitergebnisse gar nicht. Wer einen dauerhaften, gemeinsamen Speicher braucht, nutzt use cache: remote; das kostet laut Dokumentation einen Netzwerkzugriff und Plattformgebühren und lohnt sich nur bei hoher Trefferquote. Außerdem gilt jeder Cache für genau ein Deployment: Ein neuer Build beginnt leer, weil die Build-ID zum Schlüssel gehört.

Für die Auswahl des Hostings ist das wichtiger als die Frage “Vercel oder selbst”: Zuerst steht, welche Inhalte Laufzeit-Caching überhaupt brauchen, und erst dann, ob der gewählte Anbieter es speichert.

#Cache, Zugangsdaten und das BayLDA

Ein Cache fügt einer Anwendung zwei Türen hinzu: den Webhook, der Inhalte verfallen lässt, und den Draft-Mode-Einstieg. Beide sind über das Netz erreichbar und beide sind nur durch ein Geheimnis geschützt. Das Geheimnis gehört in eine Umgebungsvariable, nicht ins Repository, und wird beim Wechsel einer Agentur oder eines Entwicklers ausgetauscht.

Das Bayerische Landesamt für Datenschutzaufsicht schreibt auf seiner Cyberfestung-Seite, dass bei ihm täglich Meldungen bayerischer Firmen über Cybersicherheitsvorfälle eingehen, von kompromittierten E-Mail-Konten bis zu Verschlüsselungs- und Erpressungsfällen. Für bayerische nicht-öffentliche Stellen bietet das Amt dort eine Checkliste mit zehn Punkten für Datensicherheit an. Sie ersetzt keine Prüfung Ihrer Anwendung, ist aber ein sinnvoller Gegenpol zu allem, was ich hier zu Webhooks und Zugängen schreibe.

Für personenbezogene Daten im Cache gilt meine eigene Regel: Was von einer Sitzung abhängt, kommt nicht in einen gemeinsamen Server-Cache. Die Dokumentation sieht für Laufzeitdaten use cache: private vor, dessen Ergebnisse nur im Browser liegen, nennt ihn aber einen seltenen Ausnahmefall. Landet ein Wert wie eine Sitzungskennung als Argument in einem use cache-Bereich, wird er Teil des Cache-Schlüssels und damit Teil dessen, was im Speicher liegt. Gehört ein externer Cache wie Redis oder ein KV-Speicher zur Lösung, kommt er in das Verzeichnis der eingesetzten Dienste, das Ihr Datenschutzbeauftragter ohnehin pflegt.

#Was ich vor dem Projekt klären lasse

Gemessen wird der Erfolg 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 Zahlen verspreche ich nicht; sie kommen aus Messungen auf der Testumgebung und später aus Felddaten.

#So läuft ein Auftrag aus Augsburg bei mir

1. Ihre Beschreibung. Per Formular oder E-Mail: Was soll entstehen oder sich ändern, für wen, bis wann?
2. Meine Rückfragen, schriftlich. Meist zu CMS, Hosting, Veröffentlichungsrhythmus und Vorschau.
3. Umfang als Dokument. Leistungen, Ausschlüsse, Annahmen und wer was liefert. Ich beginne erst nach Ihrer schriftlichen Bestätigung. Zusätzliche Wünsche schätze ich getrennt ein.
4. Staging. Änderungen gehen zuerst auf eine Testumgebung, die Sie selbst durchklicken können.
5. Abnahme gegen den Umfang. Sie prüfen Punkt für Punkt und schicken mir offene Punkte als Liste.
6. Danach. Updates und kleine Änderungen übernehme ich auf Wunsch im Rahmen der Wartung in Augsburg. Die Stunden eines Monats verfallen am Monatsende.

Was Sie mitbringen: Gestaltung, Mockups und Wireframes liefern Sie oder Ihre Agentur. Ich setze sie als responsives Frontend um und entwerfe nichts selbst. Gibt es noch keinen Entwurf, tragen Sie in meiner Tabellenvorlage je Ansicht ein, welches Element wohin kommt. Dazu brauche ich Zugang zu Repository, Hosting und CMS sowie die Angabe, wer die Texte liefert.

#Verwandte Seiten für Augsburg

• WordPress Entwickler in Augsburg: wenn ein klassisches WordPress ohne getrenntes Frontend genügt.
• Astro Entwickler in Augsburg: für Inhaltsseiten mit wenig Interaktion.
• Migration von Next.js zu Astro in Augsburg: wenn ein bestehendes Next.js mehr Framework ist als nötig.
• PHP Entwickler in Augsburg: wenn ein Laravel- oder Symfony-Backend die Daten liefert.
• Headless CMS Entwickler: wenn Redaktionssystem und Frontend getrennt laufen sollen.

#Fragen aus Augsburger Anfragen

#Speichert Next.js 16 automatisch alles zwischen?

Nein. Seit Version 15 werden fetch-Anfragen und GET-Route-Handler nicht mehr standardmäßig zwischengespeichert. Mit aktivierten Cache Components entsteht ein Cache nur dort, wo die Direktive use cache steht. Ungecachte Daten gehören hinter eine Suspense-Grenze, sonst meldet die Entwicklungsumgebung ein blockierendes Rendering.

#Was ist der Unterschied zwischen revalidateTag und updateTag?

revalidateTag markiert getaggte Daten als veraltet und liefert sie noch aus, während im Hintergrund neu gerendert wird. updateTag läuft nur in Server Actions und lässt den Eintrag sofort verfallen, damit der Nutzer seine eigene Änderung gleich sieht. Ein Webhook des CMS ruft einen Route Handler auf; dort ist updateTag nicht verfügbar, und revalidateTag bekommt zum sofortigen Verfall den Wert { expire: 0 }.

#Mein CMS veröffentlicht, aber die Seite zeigt noch den alten Stand. Woran liegt das?

Meist an einem von vier Punkten. Der Cache-Eintrag hat keinen Tag, den der Webhook trifft. Der Webhook nutzt revalidateTag mit max, dann sieht der erste Besucher noch den alten Stand. Bei Serverless-Hosting wird der Eintrag nicht im Speicher gehalten. Oder revalidatePath bekam die Adresse aus dem Browser statt den Pfad der Routendatei.

#Kann die Redaktion Entwürfe sehen, ohne dass Besucher sie sehen?

Ja, mit dem Draft Mode. Das CMS öffnet eine Adresse in der Anwendung, die ein Cookie setzt. Solange es gesetzt ist, umgeht der Redakteur alle Caches und sieht den aktuellen Entwurf. Alle anderen Besucher bekommen weiter die zwischengespeicherte Seite.

#Muss ich auf Cache Components umstellen?

Nicht sofort. Neue Apps aus create-next-app haben die Option laut Dokumentation bereits aktiv, und sie soll in der nächsten Hauptversion überall gelten. Für eine bestehende App ist die Umstellung mehr als eine Umbenennung und kann Build-Fehler für ungecachte Daten außerhalb von Suspense zeigen. Ich plane sie als eigenen Schritt auf der Testumgebung.

#Welche Angaben brauchen Sie für eine erste Einschätzung?

Die Adresse Ihrer Website, das CMS, das die Inhalte liefert, die Frage, wer wie oft veröffentlicht, und den Hoster. Wenn ein Layout existiert, legen Sie es bei; die Platzierung der Elemente liefern Sie, ich setze sie um.

#Ihr Next.js-Vorhaben in Augsburg

Ob eine Seite, auf der die Redaktion Änderungen endlich sofort sieht, ein Portal mit Login oder ein Frontend, das nach dem Versionssprung wieder berechenbar zwischenspeichert: Schreiben Sie mir über das Kontaktformular. Nennen Sie die Adresse Ihrer aktuellen Website, das Ziel, den gewünschten Termin, das CMS und den Stack, mit dem Sie heute arbeiten. An Werktagen antworte ich schriftlich; die erste Einschätzung zu Ihrem Vorhaben kostet nichts.