# Core Web Vitals mit statischem Nuxt: LCP, INP und CLS im Griff
Wie statisch generierte Nuxt-Websites gute Core Web Vitals erreichen: Bilder, Schriften, Hydration, Lazy Loading von 3D-Szenen und die richtige Messung.
von Alexander Herling Veröffentlicht am 30. Juli 2026 7 Min. Lesezeit
Core Web Vitals sind die drei Kennzahlen, mit denen Google die Nutzererfahrung beim Laden und Bedienen einer Seite bewertet. Sie fließen in die Suche ein, aber wichtiger ist: Sie messen, was Besucher spüren. Statisch generierte Websites mit Nuxt bringen dafür beste Voraussetzungen mit. Wir zeigen, wo dennoch die typischen Bremsen liegen und wie Sie sie lösen, einschließlich Seiten mit interaktiven 3D-Elementen.
## Die drei Kennzahlen
| Kennzahl | Misst | Gut | Verbesserungsbedürftig | Schlecht |
| ----------------------------------- | --------------------------------------------- | -------- | ---------------------- | -------- |
| **LCP** (Largest Contentful Paint) | Wann das größte sichtbare Element geladen ist | ≤ 2,5 s | ≤ 4 s | > 4 s |
| **INP** (Interaction to Next Paint) | Wie schnell die Seite auf Eingaben reagiert | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| **CLS** (Cumulative Layout Shift) | Wie stark das Layout unerwartet springt | ≤ 0,1 | ≤ 0,25 | > 0,25 |
Bewertet wird jeweils das 75. Perzentil der Seitenaufrufe echter Nutzer, getrennt nach Mobil und Desktop. INP hat im März 2024 den früheren Wert FID abgelöst und ist strenger, weil er alle Interaktionen eines Besuchs berücksichtigt, nicht nur die erste.
## Warum statisches Nuxt einen Vorsprung hat
Mit `nuxt generate` oder vorgerenderten Routen entsteht beim Build fertiges HTML für jede Seite. Ein CDN liefert es aus, ohne dass ein Server bei jedem Aufruf rechnen muss. Die Antwortzeit ist kurz, und der Inhalt steht sofort im HTML, was auch Suchmaschinen und KI-Crawlern hilft.
Danach lädt der Browser das JavaScript und „hydratisiert“ die Seite, macht sie also interaktiv. Genau hier entstehen bei vielen Nuxt-Seiten die Probleme: zu viel JavaScript, das zu früh ausgeführt wird.
## LCP: das größte Element schnell zeigen
Das LCP-Element ist meist ein Hero-Bild oder eine große Überschrift. Damit es früh erscheint:
**Bilder optimieren.** Mit `@nuxt/image` erzeugen Sie beim Build passende Größen und moderne Formate wie AVIF und WebP. Geben Sie mit `sizes` an, wie breit das Bild im Layout tatsächlich ist, damit Mobilgeräte keine Desktop-Bilder laden.
**Das Hero-Bild priorisieren.** Es darf nicht lazy geladen werden, sondern bekommt hohe Priorität:
```
```
Für AVIF mit WebP-Fallback eignet sich ``. Alle Bilder unterhalb des sichtbaren Bereichs erhalten dagegen `loading="lazy"`.
**Render-blockierende Ressourcen klein halten.** Kritisches CSS sollte schmal sein, Drittanbieter-Skripte gehören nicht in den Kopf der Seite.
**Caching richtig setzen.** Dateien unter `/_nuxt/` tragen einen Hash im Namen und können ein Jahr lang als unveränderlich gecacht werden. HTML dagegen kurz oder mit Revalidierung, damit Änderungen schnell ankommen.
## Schriften ohne Sprünge und Verzögerung
Webfonts beeinflussen LCP und CLS gleichzeitig. Das Modul `@nuxt/fonts` hilft an beiden Stellen: Es lädt Schriften herunter und hostet sie selbst, statt sie von Drittanbietern zu beziehen, und es erzeugt angepasste Ersatzschriften mit passenden Metriken. Der Text erscheint damit sofort in einer Systemschrift, die fast genauso viel Platz einnimmt. Wird die Webfont geladen, verschiebt sich kaum etwas.
Weitere Regeln:
- Nur die Schnitte laden, die wirklich verwendet werden. Variable Fonts ersetzen oft mehrere Dateien.
- Zeichensätze auf die benötigten Sprachen beschränken (Subsetting).
- Die wichtigste Schrift vorladen, aber nicht alle.
Selbst gehostete Schriften haben einen Nebeneffekt: Es fließen keine Daten an Dritte, was auch beim Thema [Cookie-Banner und Consent](https://degoya.digital/blog/cookie-banner-consent-tdddg) hilft.
## INP: weniger JavaScript, später ausgeführt
INP misst die Zeit zwischen einer Eingabe und der nächsten sichtbaren Reaktion. Schlecht wird der Wert, wenn der Hauptthread blockiert ist, etwa weil gerade eine große Komponente hydratisiert wird.
**Komponenten verzögert laden.** Mit dem Präfix `Lazy` lädt Nuxt den Code einer Komponente erst, wenn sie gerendert wird. Seit Nuxt 3.16 lässt sich zusätzlich steuern, wann eine Komponente hydratisiert wird:
```
```
Inhalte, die nur angezeigt werden und keine Interaktion brauchen, müssen gar nicht hydratisiert werden.
**Drittanbieter-Skripte zähmen.** Chat-Widgets, Tag-Manager und Videoplayer sind häufige INP-Verursacher. Laden Sie sie erst nach einer Interaktion oder wenn der Browser untätig ist. Das Modul `@nuxt/scripts` bietet dafür Auslöser und Platzhalter-Fassaden.
**Lange Aufgaben aufteilen.** Aufwendige Berechnungen nach einem Klick sollten zuerst die sichtbare Reaktion zeigen und den Rest danach erledigen, etwa durch Aufteilen in kleinere Schritte oder Auslagern in einen Web Worker.
## CLS: Platz reservieren
Layoutsprünge entstehen, wenn Inhalte nachträglich Platz beanspruchen.
- Bilder und Videos mit `width` und `height` oder `aspect-ratio` versehen.
- Eingebettete Inhalte wie Karten oder Videos mit festen Platzhaltern einbinden.
- Banner, Hinweise und Consent-Dialoge als Overlay am Rand anzeigen, nicht oberhalb des Inhalts einschieben.
- Animationen auf `transform` und `opacity` beschränken, nicht auf `top`, `height` oder `margin`.
## 3D-Elemente, ohne die Ladezeit zu opfern
Interaktive 3D-Szenen mit Three.js oder TresJS können eine Website prägen. Die Bibliotheken sind aber groß, und WebGL beansprucht Prozessor und Grafikchip. So bleibt die Seite trotzdem schnell:
1. **Statisches Vorschaubild zuerst.** Ein optimiertes Bild der Szene wird sofort angezeigt und ist das LCP-Element.
2. **3D-Code getrennt laden.** Die Szene steckt in einer eigenen, per `` und `Lazy` eingebundenen Komponente, sodass Three.js nicht im Haupt-Bundle landet.
3. **Spät starten.** Erst laden, wenn die Szene in den sichtbaren Bereich kommt oder der Nutzer interagiert.
4. **Assets komprimieren.** glTF-Modelle mit Draco- oder Meshopt-Kompression, Texturen im KTX2-Format.
5. **Rendering begrenzen.** Pixeldichte auf höchstens 2 begrenzen, nicht sichtbare Szenen pausieren, bei `prefers-reduced-motion` auf Animation verzichten.
6. **Ausweichlösung.** Auf schwachen Geräten oder ohne WebGL bleibt das Vorschaubild stehen.
## Richtig messen
Es gibt zwei Arten von Daten:
- **Labordaten** aus Lighthouse oder den Chrome-Entwicklertools: reproduzierbar, gut zum Debuggen, aber unter simulierten Bedingungen.
- **Felddaten** echter Nutzer aus dem Chrome User Experience Report (CrUX): Grundlage für die Bewertung in der Search Console, ausgewertet über einen rollierenden Zeitraum von 28 Tagen. Verbesserungen werden dort also erst nach einigen Wochen vollständig sichtbar.
Für schnelles Feedback lohnt es sich, die Werte selbst zu erfassen, etwa mit der Bibliothek `web-vitals` und einer datenschutzfreundlichen Auswertung. Testen Sie immer auf einem durchschnittlichen Mittelklasse-Smartphone, nicht nur am Entwicklerrechner.
## Der Weg zu guten Werten
Öffnen Sie den Bericht zu den Core Web Vitals in der Search Console und sehen Sie nach, welche Kennzahl auf welchen Seitengruppen schlecht ist. Meist ist es eine Ursache, die viele Seiten betrifft: ein zu großes Hero-Bild, eine Schrift, ein Drittanbieter-Skript. Beheben Sie diese eine Ursache zuerst. Wenn Sie eine neue Website mit Nuxt planen oder eine bestehende beschleunigen möchten, unterstützen wir Sie im Bereich [Webentwicklung und Apps](https://degoya.digital/leistungen/webentwicklung-apps).
## Häufige Fragen
Sind statisch generierte Seiten automatisch schnell?
Sie haben einen großen Vorsprung, weil fertiges HTML ohne Serverberechnung ausgeliefert wird. Große Bilder, nachladende Schriften oder viel JavaScript können die Werte trotzdem verschlechtern.
Warum zeigt PageSpeed Insights andere Werte als die Search Console?
PageSpeed Insights zeigt oben Felddaten echter Nutzer, darunter einen Labortest unter simulierten Bedingungen. Die Search Console wertet ausschließlich Felddaten aus, gruppiert nach ähnlichen Seiten und über 28 Tage.
Verschlechtert eine 3D-Szene zwangsläufig die Core Web Vitals?
Nicht, wenn sie richtig geladen wird. Ein statisches Vorschaubild übernimmt die Rolle des größten Elements, die 3D-Bibliothek wird erst nachgeladen, wenn die Szene sichtbar ist oder der Nutzer interagiert.
## Über den Autor: Alexander Herling
Gründer und Inhaber von DEGOYA.digital. Seit dem ersten Kontakt mit 8-Bit-Computern in seiner Kindheit beschäftigt er sich mit Technologie. Heute verbindet er 35 Jahre Erfahrung in Marketing und Webentwicklung mit einem Schwerpunkt auf technischer Suchmaschinenoptimierung.
Passende Leistung
[Webentwicklung & Apps](https://degoya.digital/leistungen/webentwicklung-apps)
[Zurück zum Blog](https://degoya.digital/blog)
Source: https://degoya.digital/blog/core-web-vitals-nuxt-static