Next.js-Entwickler in Düsseldorf

Mein Name ist Mariusz Szatkowski. Ich entwickle allein, aus Gdynia, und arbeite seit 2006 mit WordPress. Für Düsseldorf schreibe ich über drei Dinge, die bei einer Next.js-Seite Ladezeit und Datenschutzrisiko zugleich bestimmen: Bilder, Schriften und die Frage, woran man beides misst. Die Angaben zu Next.js stammen aus der Dokumentation auf nextjs.org, die Schwellenwerte aus dem Artikel zu den Web Vitals auf web.dev. Die aktuelle Version ist nach der npm-Registry 16.4.6, veröffentlicht am 9. November 2026.

#Seiten mit Stichtag: was Düsseldorf dafür liefert

Der Messekalender der Messe Düsseldorf nannte am 11. November 2026 unter anderem MEDICA und COMPAMED (16. bis 19. November 2026), die VALVE WORLD EXPO (1. bis 3. Dezember 2026) und die boot Düsseldorf (23. bis 31. Januar 2027). Wer dazu eine Produktseite, einen Katalog oder eine Anmeldestrecke braucht, hat ein festes Datum, an dem die Seite stehen muss. Für die Ladezeit folgt daraus etwas Unbequemes: Messwerte echter Besucher entstehen erst, wenn Besucher kommen. Ich richte die Messung deshalb vor dem Livegang ein, nicht danach, und lege die Bild- und Schriftentscheidungen schriftlich fest, solange sich noch alles ändern lässt.

Foto: Dietmar Rabich, CC BY-SA 4.0, Wikimedia Commons.

#Woraus sich die Ladezeit des größten Elements zusammensetzt

Der Largest Contentful Paint (LCP) misst, wann das größte Bild oder der größte Textblock im sichtbaren Bereich fertig gezeichnet ist. Die Schwelle nennt web.dev: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1, jeweils beim 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Der Leitfaden zur LCP-Optimierung zerlegt den Wert in vier Teile, die sich lückenlos zur Gesamtzeit addieren:

web.dev nennt das Richtwerte, keine Regeln. Wer ohnehin innerhalb von 2,5 s liegt, muss die Verteilung nicht beachten. Für meine Arbeit zählt der Hinweis darunter: Ist das größte Element ein Textknoten in einer Systemschrift, sind Ladeverzögerung und Ladedauer null. Sobald dieser Text eine Webschrift braucht, kommt die Schrift als Ressource dazu. Bilder und Schriften sind deshalb dieselbe Frage, nur an zwei Stellen der Tabelle.

#next/image: sizes entscheidet, was der Browser lädt

Die Komponente next/image erzeugt zu jedem Bild mehrere Breiten und trägt sie in srcset ein. Welche der Browser wählt, hängt an sizes. Fehlt das Attribut, nimmt er laut Referenz zur Image-Komponente an, das Bild sei so breit wie der Bildschirm (100vw). Ein Foto, das in Wirklichkeit nur eine halbe Spalte füllt, kommt dann unnötig groß an. Die Dokumentation verlangt sizes bei Bildern mit fill und bei Bildern, die per CSS responsiv werden. Es verändert auch, was Next.js erzeugt:

• Ohne sizes entsteht bei einem Bild mit width nur ein knappes srcset für feste Größen, zum Beispiel 1x und 2x.
• Ohne sizes entsteht bei einem Bild mit fill ein srcset allein aus den Gerätebreiten, als läge das Bild über die ganze Seite.
• Mit sizes entsteht ein volles srcset für responsive Layouts.

Für ein Titelbild, das ich nach Ihrem Wireframe baue, sieht das so aus:

import Image from 'next/image'

export function Titelbild() {
  return (
    <div style={{ position: 'relative', aspectRatio: '16 / 9' }}>
      <Image
        src="/stand.jpg"
        alt="Messestand mit Produktvitrine"
        fill
        sizes="(min-width: 1024px) 960px, 100vw"
        fetchPriority="high"
      />
    </div>
  )
}

Das Elternelement braucht bei fill eine Positionierung, sonst hat das Bild keine Fläche. Den Wert in sizes leite ich aus dem Layout ab, das Sie liefern, nicht aus einer Schätzung. Zwei weitere Punkte betreffen die Messwerte direkt:

Bild oben auf der Seite. Seit Next.js 16 ist priority veraltet, an seine Stelle tritt preload. Die Dokumentation rät in den meisten Fällen trotzdem zu loading="eager" oder fetchPriority="high", und preload nicht zusammen mit diesen beiden. web.dev ergänzt, dass man das LCP-Bild nie mit loading="lazy" laden soll, weil es immer unnötige Ladeverzögerung erzeugt. Alle anderen Bilder bleiben standardmäßig lazy.

Platz reservieren. width und height sind die Originalmaße und liefern das Seitenverhältnis, damit der Browser Platz freihält und nichts springt. Bei statisch importierten Bildern ermittelt Next.js beide Werte selbst. Bei Bildern von fremden Servern kennt der Build die Datei nicht, dort gebe ich beide Werte an oder nutze fill. Außerdem verlangt die Dokumentation eine Liste erlaubter Adressen, so eng wie möglich:

// next.config.js
module.exports = {
  images: {
    remotePatterns: [
      { protocol: 'https', hostname: 'medien.beispiel.de', pathname: '/uploads/**' },
    ],
  },
}

Der Host ist ein Platzhalter. Ein Muster für eine ganze Domain wäre die bequeme Variante und genau die, die man nicht will. Weitere Einstellungen wie formats, qualities und minimumCacheTTL beschreibt die Referenz; sie ändern das Verhalten der Optimierung, aber nicht die Logik oben.

#next/font: Schriften ohne Anfrage an Google

Das Modul next/font liefert Schriften aus dem eigenen Build aus. Nach der Dokumentation laden Google Fonts beim Build herunter und liegen danach bei den übrigen statischen Dateien, und der Browser des Besuchers schickt keine Anfrage an Google. Dasselbe gilt für eigene Dateien über next/font/local.

// app/layout.tsx
import localFont from 'next/font/local'

const marke = localFont({
  src: './fonts/marke-variable.woff2',
  display: 'swap',
  variable: '--font-marke',
})

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="de" className={marke.variable}>
      <body>{children}</body>
    </html>
  )
}

Die Referenz zum Font-Modul nennt die Stellschrauben, die für die Messwerte zählen:

Zum Umfang sagt die Dokumentation zweierlei. Jeder Aufruf der Funktion legt eine eigene Instanz an, deshalb gehört eine Schrift in eine gemeinsame Definitionsdatei. Und die Schrift wird nur auf den Routen vorgeladen, in deren Datei sie steht: im Root-Layout auf allen, in einer einzelnen Seite nur dort. Mehrere Schriften soll man sparsam einsetzen, weil jede ein weiterer Download ist.

Selbst gehostet heißt nicht automatisch schneller. web.dev schreibt in den Best Practices für Schriften, die Unterschiede seien in der Praxis weniger eindeutig, als man erwartet, und die Web-Almanac-Daten hätten für Drittanbieter-Schriften sogar schnelleres Rendern gezeigt. Eigene Schriften lohnen sich laut dem Artikel vor allem hinter einem CDN und mit HTTP/2. Dass ich sie trotzdem selbst ausliefere, hat einen anderen Grund.

#Google Fonts und die Aufsicht in Düsseldorf

Wer Google Fonts per Link vom Google-Server lädt, schickt die IP-Adresse seiner Besucher an Google. Das Landgericht München I hat darüber am 20. Januar 2022 entschieden (Az. 3 O 17493/20). Nach den Gründen ist die dynamische IP-Adresse für den Betreiber ein personenbezogenes Datum, ohne Einwilligung war die Weitergabe unzulässig, und ein berechtigtes Interesse lag nicht vor, weil sich Google Fonts auch nutzen lässt, ohne dass beim Aufruf eine Verbindung zu einem Google-Server entsteht. Das Gericht sprach Unterlassung, Auskunft und Schadensersatz nach Art. 82 DSGVO zu. Es ist das Urteil eines Landgerichts in einem Einzelfall. Ob und wie es auf Ihre Seite wirkt, klärt Ihre Rechtsberatung. Der technische Teil ist dagegen klein: Die Anfrage entfällt, wenn die Schrift aus dem eigenen Build kommt.

Zuständig für Unternehmen in Düsseldorf ist die LDI NRW. Auf ihrer Seite zu den allgemeinen Grundsätzen der Drittlandübermittlung schreibt sie, eine Übermittlung liege in der Regel vor, wenn eine Stelle Daten an eine Stelle im Drittland sendet oder sie von dort abrufen lässt, und auch Zugriffe aus dem Drittland für Backups, Wartung und Service seien Übermittlungen. Für Schriften reicht mir das als Anlass, bei jedem Projekt zu fragen, welche externen Adressen die fertige Seite überhaupt aufruft. Die Antwort liefere ich als Liste: Schrift, Bild-CDN, Karte, Video, Messdienst. Was auf der Liste bleibt, bewertet Ihre Rechtsberatung.

#Messen mit Felddaten statt mit einem einzelnen Testlauf

web.dev unterscheidet Labordaten aus einer kontrollierten Umgebung mit festgelegtem Gerät und Netz von Felddaten echter Besucher. Beide können sich stark unterscheiden: Das Labor zeigt gute Werte, das Feld schlechte, oder umgekehrt. Im Leitfaden zur LCP-Optimierung heißt es, bei vorhandenen Felddaten solle man sich zuerst auf diese konzentrieren. Zwei Quellen gibt es:

• CrUX und PageSpeed Insights. Das Chrome User Experience Report sammelt anonyme Daten echter Chrome-Nutzer. PageSpeed Insights zeigt sie oben an, bis zu vier Ansichten: Mobil und Desktop, jeweils für die URL und für die ganze Origin. Fehlt der URL genug Verkehr, zeigt es die Daten der Origin. Der Wert einer einzelnen Seite kann davon stark abweichen.
• Eigene Messung. Wo CrUX keine Seitendaten hat, empfiehlt web.dev Messung per JavaScript auf der Seite. Next.js bringt dafür den Hook useReportWebVitals mit (Dokumentation). Er meldet TTFB, FCP, LCP, INP und CLS, jeweils mit einer Einstufung als good, needs-improvement oder poor.

Die Funktion, die der Hook aufruft, darf ihre Referenz nicht ändern, sonst meldet sie Werte doppelt. Deshalb steht sie außerhalb der Komponente:

'use client'

import { useReportWebVitals } from 'next/web-vitals'

type Report = Parameters<typeof useReportWebVitals>[0]

const senden: Report = (metric) => {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    path: location.pathname,
  })
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', body)
  } else {
    fetch('/api/vitals', { body, method: 'POST', keepalive: true })
  }
}

export function WebVitals() {
  useReportWebVitals(senden)
  return null
}

Die Komponente gehört ins Root-Layout, so bleibt die Client-Grenze auf dieses Modul beschränkt. Der Endpunkt liegt in Ihrer Anwendung, es gibt keinen zusätzlichen Dienstleister. Ich sende nur die vier Felder oben, nicht das ganze Metric-Objekt. Ob die Messung in Ihre Datenschutzerklärung gehört, entscheidet Ihre Rechtsberatung, die Beschreibung der Felder bekommt sie von mir schriftlich.

#Checkliste für Bilder, Schriften und Messung

#Wann ich Next.js dafür nicht empfehle

Besteht die Seite hauptsächlich aus Inhalt, Bildern und einem Formular, ist Next.js oft mehr Werkzeug, als sie braucht. Dann prüfe ich vorab, ob Astro mit weniger JavaScript auskommt. Läuft Ihre Redaktion ohnehin in WordPress und braucht nur ein besseres Frontend, ist WordPress in Düsseldorf eine eigene Seite wert. Next.js lohnt sich, wenn die Seite wirklich Anwendung ist: Konfigurator, Händlerportal, Bestellstrecke.

#Ablauf eines Projekts

Ich arbeite allein und remote, alles läuft schriftlich, Termine und Telefonate gibt es nicht. Zum Start schicken Sie mir eine Mail mit Ziel, Stack und Termin. Meine Rückfragen und den Umfang mit allen Annahmen bekommen Sie als Text. Ich baue auf einer Staging-Umgebung, Sie prüfen und nehmen schriftlich ab, dann gehe ich live. Layout, Mockups und Wireframes kommen von Ihnen oder Ihrer Agentur: Sie markieren in einer Tabellenvorlage, welches Element auf welche Ansicht gehört, und ich setze das responsive Frontend danach um. Für die Pflege nach dem Livegang beschreibt die Seite Wartung und Support in Düsseldorf den Ablauf.

#Häufige Fragen

Lädt next/font Schriften von Google, wenn ich Google Fonts wähle? Beim Build, ja, im Browser Ihrer Besucher nein. Laut Dokumentation werden CSS und Schriftdateien beim Build heruntergeladen und mit den übrigen statischen Dateien ausgeliefert. Der Browser schickt keine Anfrage an Google.

Muss ich bei jedem Bild width und height angeben? Nicht bei statisch importierten Bildern, dort ermittelt Next.js beide Werte selbst. Bei Bildern von fremden Servern kennt der Build die Datei nicht, dort braucht es beide Werte oder fill mit einem positionierten Elternelement.

Was ersetzt priority bei next/image? Seit Next.js 16 ist priority veraltet, an seine Stelle tritt preload. Die Dokumentation empfiehlt in den meisten Fällen loading="eager" oder fetchPriority="high" und rät davon ab, preload zusammen mit diesen Eigenschaften zu nutzen.

Ist ein Google-Fonts-Link in einem älteren Theme ein Datenschutzproblem? Das Landgericht München I hat 2022 in einem Einzelfall die Weitergabe der IP-Adresse an Google ohne Einwilligung für unzulässig erklärt, auch weil sich die Schrift ohne Verbindung zu Google nutzen lässt. Die rechtliche Bewertung Ihrer Seite gehört zu Ihrer Rechtsberatung. Technisch lässt sich die Anfrage vermeiden, indem die Schrift vom eigenen Server kommt.

Reicht ein guter Lighthouse-Wert? Nein. Ein Lighthouse-Lauf ist ein Labortest mit festgelegten Bedingungen. web.dev beschreibt, dass Labor- und Felddaten sich deutlich unterscheiden können, und rät, bei vorhandenen Felddaten zuerst diese anzusehen. Bei Bewertung zählt das 75. Perzentil der echten Seitenaufrufe.

Gestalten Sie auch das Layout? Nein. Das Layout liefern Sie oder Ihre Agentur. Ich setze es nach Ihren Vorgaben um.

#Ihr Projekt in einer E-Mail

Wollen Sie wissen, wo Ihre Next.js-Seite Ladezeit verliert, oder eine neue Seite mit Messung von Anfang an aufsetzen? Schreiben Sie mir über das Kontaktformular. Nennen Sie die Adresse Ihrer Seite, Ihr Ziel, den Wunschtermin und den aktuellen Stack samt Hosting. Die erste schriftliche Schätzung ist kostenlos, meine Antwort mit Rückfragen kommt an Werktagen.