Migration zu Next.js / Astro in Wien

Bei einer Migration von WordPress, Joomla oder Drupal auf Astro oder Next.js geraten Bilder oft erst am Ende in den Blick, wenn die Seiten schon stehen. Dann fehlen Dateien, die Google noch in der Bildersuche führt, ein Banner lädt als Original mit mehreren Megabyte, und niemand weiß, wer das Foto im Footer aufgenommen hat. Diese Seite behandelt nur die Medien: Mediathek, Bild-URLs, die Bildkomponenten beider Frameworks, Formate, PDFs und Video. Den Gesamtablauf einer Migration beschreibe ich auf der Seite zur Migration zu Astro und Next.js. Die Barrierefreiheit von Next.js-Anwendungen nach dem BaFG steht auf der Seite Next.js-Entwickler Wien.

#Was in Ihrer Mediathek liegt, bevor etwas umzieht

Ich beginne mit einer Liste, nicht mit einem Export. Sie enthält jede Datei im Medienordner des alten Systems, ob sie noch irgendwo eingebunden ist und ob sie Besucher oder Suchmaschinen erreichen. Ältere Systeme legen neben dem Original oft mehrere Größen mit Maßangabe im Dateinamen ab. Für die Planung zählt meist nur das Original; die Varianten erzeugt das neue Frontend selbst.

Google nennt das in seiner Anleitung zum Website-Umzug ausdrücklich. Die URLs eingebetteter Inhalte (Videos, Bilder, JavaScript- und CSS-Dateien) gehören in die Umzugsplanung und werden wie der übrige Inhalt behandelt. Gehostete Downloads wie PDFs soll man ebenfalls übertragen, weil sie bereits Suchtreffer und Links haben können. Quelle: Google Search Central, Umzug mit URL-Änderungen.

Foto: Andreas Praefcke, CC BY 3.0, Wikimedia Commons.

#Bild-URLs behalten oder weiterleiten

Das neue System entscheidet mit, was möglich ist.

Astro. Bilder in src/ kann Astro verändern, optimieren und bündeln, und die Dokumentation empfiehlt das. Dateien in public/ werden dagegen unverändert ausgeliefert und nie optimiert. Wer alte Pfade exakt behalten will, legt die Originale in public/ ab. Wer optimierte Bilder will, nimmt neue Adressen in Kauf und leitet die alten um.

Next.js. Dateien in public/ werden ab der Basis-URL ausgeliefert, ein statischer Import bekommt laut Dokumentation einen Hash im Dateinamen. Weiterleitungen trägt man in next.config.js ein: permanent: true liefert 308, sonst 307. Auf manchen Plattformen gibt es eine Obergrenze. Die Dokumentation nennt für Vercel 1.024 Weiterleitungen und empfiehlt ab etwa tausend Einträgen eine eigene Lösung über Proxy. Bei einer Mediathek mit vielen tausend Dateien kommt man schnell dorthin, deshalb leite ich Muster statt Einzeldateien um, etwa einen ganzen Upload-Ordner auf einen neuen Pfad.

Meine Faustregel: Pfade bleiben, die in der Suche oder in fremden Links auftauchen. Alles andere bekommt eine 301-Weiterleitung auf das neue Bild oder, wenn es nicht mehr gebraucht wird, einen sauberen 404. Google rät außerdem, ein Bild immer über dieselbe URL einzubinden, damit es zwischengespeichert werden kann, und empfiehlt, im src-Attribut stets eine Rückfalladresse anzugeben, weil nicht jeder Crawler srcset und picture versteht. Quelle: Google Search Central, Bilder.

#Astro: astro:assets, Image und Picture

Die Komponente <Image /> verändert Größe, Dateityp und Qualität eines lokalen oder freigegebenen externen Bilds. alt ist Pflicht. Für Bilder in src/ kann Astro die Maße selbst ermitteln, für Bilder in public/ müssen width und height angegeben werden. <Picture /> erzeugt ein <picture>-Element mit mehreren Formaten. Laut Referenz ist ['webp'] voreingestellt, ein Aufruf mit formats={['avif', 'webp']} ergänzt AVIF. Als Rückfall gilt bei JPG-Quellen wieder JPG.

Mit einem layout erzeugt Astro die Werte für srcset und sizes automatisch; image.layout in der Konfiguration setzt das global, auch für Markdown-Bilder. Die Option priority setzt loading="eager", decoding="sync" und fetchpriority="high" und gehört auf das eine Bild oben auf der Seite. Als Bildservice ist Sharp voreingestellt, und Bilder auf vorgerenderten Seiten entstehen immer beim Build in Node.

Für Bilder, die weiter im alten CMS oder in einem Bucket liegen, gilt: Astro verarbeitet nur Quellen aus image.domains und image.remotePatterns. Beide Listen sind standardmäßig leer. Alles andere wird ausgeliefert, aber nicht optimiert.

Quellen: Astro, Images, Astro, astro:assets, Astro, Konfiguration.

#Next.js: next/image, sizes und remotePatterns

next/image verlangt width und height, außer bei einem statischen Import oder mit fill. Beide Werte sind die Eigengröße und dienen dem Seitenverhältnis, damit nichts springt; die dargestellte Größe steuert CSS. Fremde Bilder kennt Next.js beim Build nicht, deshalb müssen Sie dort die Maße selbst angeben.

sizes ist die Stellschraube, die am häufigsten fehlt. Ohne den Wert nimmt der Browser an, das Bild sei so breit wie der Viewport, und lädt unnötig große Dateien. Mit sizes erzeugt Next.js ein vollständiges srcset, ohne sizes bei einem fill-Bild nur eines aus den deviceSizes.

Formate. Voreinstellung ist WebP. Mit formats: ['image/avif', 'image/webp'] bekommt AVIF den Vorrang, WebP ist der Rückfall, und die Reihenfolge im Array zählt. Die Dokumentation nennt AVIF etwa 50 Prozent langsamer beim Kodieren und etwa 20 Prozent kleiner als WebP, jedes Format wird einzeln zwischengespeichert, und sie empfiehlt für die meisten Fälle weiterhin WebP.

Fremde Quellen. remotePatterns erlaubt Bilder nur von den eingetragenen Adressen, alles andere antwortet mit 400. Wer Protokoll, Host, Port, Pfad oder Suchparameter weglässt, lässt jeden Wert zu, und die Dokumentation rät davon ab. Eine Weiterleitung auf der Quelle folgt Next.js, ohne das Muster am Ziel erneut zu prüfen. Für eigene Dateien gibt es localPatterns.

Eigener Server. Mit next start läuft die Optimierung ohne Konfiguration. Auf Linux mit glibc kann sie zusätzliche Einstellungen gegen hohen Speicherverbrauch brauchen. Steht ein Proxy oder CDN davor, muss er den Header Accept weiterreichen. Zwischengespeicherte Bilder lassen sich nicht gezielt ungültig machen, deshalb ist minimumCacheTTL besser niedrig. Wer die Optimierung nicht braucht, setzt unoptimized oder einen eigenen Loader.

Wichtigstes Bild. Seit Next.js 16 ist priority veraltet; preload ersetzt es, und die Dokumentation rät in den meisten Fällen zu loading="eager" oder fetchPriority="high". web.dev rät unabhängig vom Framework: Das LCP-Bild nie lazy laden, im HTML auffindbar halten und höchstens ein bis zwei Bildern hohe Priorität geben. Als Ziel gilt ein LCP bis 2,5 s im 75. Perzentil, siehe web.dev, Core Web Vitals.

Quellen: Next.js, Image-Komponente, Next.js, Bildoptimierung, Next.js, Self-Hosting, Next.js, Weiterleitungen, web.dev, LCP optimieren.

#Astro und Next.js im Vergleich

Die letzte Zeile entscheidet bei großen Mediatheken: Astro verlagert den Aufwand in den Build, Next.js in den Betrieb und in den Cache.

#PDFs, Downloads und Video

PDFs. Ich lege sie unter dem alten Pfad ab, wenn sie Treffer oder Links haben, und leite sie sonst einzeln um. Beim Test prüfe ich jede Adresse der URL-Liste auf Status 200 oder genau eine Weiterleitung, auch für Dateien, die niemand im Menü verlinkt hat.

Video. Ein animiertes GIF ist selten die richtige Lösung. In einem Beispiel auf web.dev schrumpfte ein GIF mit 3,7 MB auf ein MP4 mit 551 KB und ein WebM mit 341 KB. Die Attribute autoplay, loop, muted und playsinline ahmen das GIF-Verhalten nach. Browser wählen die beste <source> nicht selbst, die Reihenfolge zählt: Wer WebM nutzen will, nennt es zuerst. Quelle: web.dev, GIFs durch Videos ersetzen.

#Fotorechte und Datenschutz bei einem Bestand aus Wien

Eine Migration verschiebt Fotos, die jemand vor Jahren eingestellt hat. Zwei Vorschriften kommen dabei ins Spiel. Ich bin kein Anwalt, die Bewertung im Einzelfall gehört zu Ihrer Rechtsberatung.

Lichtbilder. Nach § 74 Abs. 1 UrhG hat, wer ein Lichtbild aufnimmt, das ausschließliche Recht, es zu vervielfältigen, zu verbreiten und der Öffentlichkeit zur Verfügung zu stellen. Hat der Hersteller das Lichtbild mit seinem Namen bezeichnet, müssen nach § 74 Abs. 3 auch Vervielfältigungsstücke mit einem entsprechenden Hinweis versehen werden. Für die Migration folgt daraus: Namensangaben, die nur in den Metadaten einer Datei oder in einem Plugin standen, müssen ins neue System. Ich führe sie als eigenes Feld im Inhaltsmodell und gebe sie als sichtbare Bildunterschrift aus.

Personenbilder. § 78 Abs. 1 UrhG verbietet, Bildnisse von Personen öffentlich auszustellen oder sonst der Öffentlichkeit zugänglich zu machen, wenn dadurch berechtigte Interessen der abgebildeten Person verletzt würden. Die Datenschutzbehörde hält in ihren FAQ zu Foto und Video fest, dass eine zulässige Aufnahme noch nicht zur Weitergabe oder Veröffentlichung berechtigt; dort geht es um Videoüberwachung und anlassbezogene Aufnahmen. Als Prüfpunkt nehme ich das trotzdem mit: Team-, Event- und Kundenfotos im alten Bestand sehe ich vor dem Go-live durch und gebe Ihnen eine Liste.

Neue Dienste. Ein Bild-CDN oder ein externer Bucket ist ein Dienst mehr, der Besucheranfragen sieht. Ich führe ihn in der Liste der Drittanbieter auf, die Sie mit Ihrer Datenschutzerklärung abgleichen. Zuständige Aufsichtsbehörde ist die Datenschutzbehörde, Barichgasse 40-42, 1030 Wien.

Quellen: RIS, Urheberrechtsgesetz, Datenschutzbehörde, FAQ Foto und Video, Datenschutzbehörde.

#Checkliste für Ihre Mediathek

1. Alle Dateien des alten Systems auflisten, auch die, die nirgends mehr eingebunden sind.
2. Pro Datei festlegen: Pfad behalten, per 301 umleiten oder streichen.
3. Prüfen, welche Bilder in der Bildersuche und in fremden Links vorkommen.
4. Entscheiden, wo die Dateien künftig liegen: im Repository, in einem Bucket oder weiter im alten CMS.
5. Pro Seite das wichtigste Bild bestimmen: kein Lazy Loading, fetchpriority oder priority setzen.
6. alt, Breite, Höhe und sizes für jede Vorlage festlegen.
7. Namensangaben der Fotografen in ein Feld übernehmen.
8. Bilder mit erkennbaren Personen sichten und intern freigeben.
9. GIFs durch Video ersetzen, PDFs und andere Downloads einzeln prüfen.
10. Nach dem Go-live in der Search Console auf 404-Fehler bei Bild- und PDF-Adressen achten.

#Häufige Fragen

#Muss ich die alten Bild-URLs nach der Migration behalten?

Nicht zwingend, aber jede alte Adresse braucht ein Ziel. Google verlangt in seiner Anleitung zum Website-Umzug, die URLs eingebetteter Inhalte wie Bilder und Videos in die Umzugsplanung aufzunehmen und wie die übrigen Inhalte zu behandeln. Ich behalte Pfade, die Besucher oder fremde Seiten nachweislich nutzen, und leite den Rest per 301 weiter.

#Lohnt sich AVIF, oder reicht WebP?

Next.js liefert laut Dokumentation standardmäßig WebP und empfiehlt WebP weiterhin für die meisten Fälle. AVIF ist etwa 20 Prozent kleiner, braucht aber etwa 50 Prozent länger beim Kodieren und erhöht den Speicherbedarf des Caches, wenn beide Formate aktiv sind. Astro erzeugt standardmäßig WebP; AVIF lässt sich in der Picture-Komponente ergänzen. Ich entscheide nach Ihrem Bildbestand.

#Können meine Bilder im alten CMS bleiben?

Ja. Beide Frameworks können Bilder von einer fremden Adresse ausliefern, aber nur, wenn Sie die Quelle freigeben: in Next.js über remotePatterns, in Astro über image.domains oder image.remotePatterns. Astro optimiert fremde Bilder sonst nicht. Ob das sinnvoll ist, hängt davon ab, wie lange das alte System weiterläuft.

#Was geschieht mit PDFs und anderen Downloads?

Google nennt sie ausdrücklich: Auch gehostete Downloads wie PDFs sollen Sie beim Umzug übertragen, weil sie Suchtreffer und Links haben können. Ich lege PDFs unter demselben Pfad ab oder leite sie einzeln um und prüfe jede Adresse der Liste auf eine Antwort mit Status 200 oder genau eine Weiterleitung.

#Soll ich ein animiertes GIF durch ein Video ersetzen?

In der Regel ja. web.dev zeigt ein Beispiel, in dem aus einem GIF mit 3,7 MB ein MP4 mit 551 KB und ein WebM mit 341 KB wurde. Ein Video-Element mit autoplay, loop, muted und playsinline verhält sich wie das GIF.

#Darf ich alte Fotos von Mitarbeitern und Veranstaltungen übernehmen?

Das hängt vom Einzelfall ab und gehört in die Hand Ihrer Rechtsberatung. § 78 UrhG schützt Personen vor einer Veröffentlichung, die ihre berechtigten Interessen verletzt. Ich liefere Ihnen vor dem Go-live eine Liste aller Bilder mit erkennbaren Personen, damit Sie entscheiden können, was online bleibt.

#Schreiben Sie mir

Schicken Sie mir über die Kontaktseite die Adresse Ihrer aktuellen Website, das CMS mit Version, den ungefähren Umfang der Mediathek (Bilder, PDFs, Videos) und Ihren Termin. Ich antworte an Werktagen schriftlich mit Rückfragen und einem schriftlichen Umfang. Eine erste schriftliche Einschätzung ist bei mir kostenlos. Layout und Gestaltung liefern Sie, ich setze sie um, und die Arbeit läuft vollständig remote und schriftlich.