Web Performance mit Nuxt: Was wirklich Ladezeit spart

Eine schnelle Website beginnt nicht beim Komprimieren einzelner Dateien. Sie beginnt mit der Entscheidung, was der Browser für den ersten sichtbaren Inhalt wirklich braucht. Wenn Hero, Schrift und Navigation erst nach einem großen JavaScript-Paket erscheinen, rettet auch das kleinste Icon-Set den Einstieg nicht mehr.

Auf dieser Website treffen Nuxt 4, Inhalte aus Markdown, GSAP-Animationen, weiches Scrollen und eine optionale 3D-Szene aufeinander. Genau diese Mischung ist spannend, aber auch gefährlich. Jede einzelne Technik kann sinnvoll sein. Zusammen brauchen sie ein Budget und klare Regeln.

Erst messen, dann optimieren

Google fasst die Nutzererfahrung mit drei stabilen Core Web Vitals zusammen:

Largest Contentful Paint, kurz LCP, misst, wann der größte sichtbare Inhalt gerendert ist. Ein guter Wert liegt bei höchstens 2,5 Sekunden.
Interaction to Next Paint, kurz INP, bewertet die Reaktion auf Eingaben. Als gut gelten höchstens 200 Millisekunden.
Cumulative Layout Shift, kurz CLS, misst unerwartete Verschiebungen. Der gute Bereich endet bei 0,1.

Diese Schwellen gelten jeweils für mindestens 75 Prozent der Seitenaufrufe. Die aktuelle Definition und der Lebenszyklus der Metriken stehen in der offiziellen Dokumentation zu Web Vitals.

Lighthouse hilft im Labor, einen reproduzierbaren Ausgangspunkt zu bekommen. Für die Entscheidung nach dem Launch sind Felddaten wichtiger, weil echte Geräte, Netze und Interaktionen darin vorkommen. Ein grüner Desktop-Lighthouse-Lauf ist deshalb kein Beleg für eine schnelle mobile Website.

Ich erfasse pro wichtiger Route mindestens:

mobile Lighthouse-Werte mit festem Profil
LCP-Element und dessen Ladepfad
JavaScript-Menge beim ersten Aufruf
lange Aufgaben auf dem Main Thread
Layout Shifts während Laden und Interaktion
Verhalten mit aktivierter Option für reduzierte Bewegung

Der kritische Pfad entscheidet über LCP

Der Browser sollte das LCP-Element im ersten HTML finden können. Bei einem Hero-Bild heißt das: ein echtes img mit src oder srcset, bekannten Abmessungen und sinnvoller Priorität. Wird das Bild erst nach einem Client-Script eingesetzt, startet der Download unnötig spät.

Der Leitfaden Optimize Largest Contentful Paint zerlegt LCP in Serverantwort, Verzögerung bis zum Ressourcenstart, Übertragung und Renderverzögerung. Diese Aufteilung ist nützlicher als pauschal "Bilder kleiner machen" zu sagen. Ein bereits geladenes Bild kann immer noch warten, weil JavaScript den Main Thread blockiert oder ein Element bis zur Hydration versteckt bleibt.

Für eine typische Marketingseite priorisiere ich deshalb:

vollständiges HTML für Headline, Subline und CTA
früh entdeckbare Hero-Ressource
kleine kritische Styles
JavaScript erst dort, wo eine echte Interaktion beginnt

Nuxt unterstützt universelles Rendering, statische Generierung und Regeln pro Route. Die Nuxt-Dokumentation zu Rendering Modes erklärt die Unterschiede. Für stabile Marketinginhalte ist vorgerendertes HTML meistens eine gute Basis, während dynamische API-Routen serverseitig bleiben können.

Hydration ist ein bewusstes Budget

Hydration verbindet bereits gerendertes HTML im Browser mit Vue-Logik. Sie ist für interaktive Komponenten nötig, aber nicht jeder Abschnitt braucht sie sofort. Ein Textblock, ein Preisvergleich oder ein Footer muss beim ersten Laden keinen eigenen Client-Lebenszyklus starten.

Ich teile Komponenten daher in drei Gruppen:

Inhalt, der als HTML vollständig funktioniert
Interaktion, die erst bei Sichtbarkeit oder Eingabe aktiv werden muss
kritische Interaktion wie Navigation, die sofort bereit sein soll

Nuxt 4 unterstützt verzögerte Hydration für Lazy-Komponenten. Die aktuelle Option ist in den Nuxt Experimental Features dokumentiert. "Experimental" heißt hier auch, dass ich die Funktion nur mit Tests und einem messbaren Vorteil einsetzen würde. Eine kleinere JavaScript-Zahl allein hilft nicht, wenn der erste Klick danach spürbar stockt.

Die passendere Frage lautet also: Wann muss diese Komponente interaktiv sein? Diese Antwort bestimmt, ob sie sofort, bei Sichtbarkeit oder erst nach einer Eingabe hydriert.

Animation darf den Browser nicht dauerhaft beschäftigen

Hochwertige Bewegung entsteht durch Timing und Hierarchie. Ein permanenter Loop ist kein Qualitätsmerkmal. Besonders teuer wird es, wenn JavaScript in jedem Frame Layoutwerte liest und direkt danach Styles schreibt. Der Browser muss dann Arbeit wiederholen, obwohl sich für den Nutzer vielleicht gar nichts verändert.

Meine Regeln für Animationen sind konkret:

transform und opacity bevorzugen, wenn die Gestaltung es erlaubt
Geometrie nach Resize oder Inhaltsänderung neu messen, nicht pauschal in jedem Frame
Animation stoppen, sobald das Element außerhalb des Viewports oder der Tab verborgen ist
Canvas und 3D auf kleinen Geräten nur laden, wenn sie einen echten Zweck erfüllen
laufende Ticker pausierbar machen
bei prefers-reduced-motion eine vollständige statische Darstellung liefern

Die W3C-Technik zu prefers-reduced-motion beschreibt, warum bewegungsempfindliche Nutzer Animationen systemweit reduzieren können. Für mich ist das kein nachträglicher Accessibility-Schalter. Die statische Variante gehört schon beim Entwurf zur Komponente.

Bilder brauchen mehr als ein modernes Format

AVIF oder WebP senkt häufig die übertragene Datenmenge. Das löst aber nur einen Teil des Problems. Das Bild braucht passende Abmessungen für den Viewport, sonst lädt ein Smartphone dieselbe Datei wie ein großer Desktop. Breite und Höhe verhindern zudem Layout Shifts.

Für Hero-Bilder gelten andere Regeln als für eine Galerie:

Das wahrscheinliche LCP-Bild wird nicht lazy geladen.
Der Browser erhält es früh und mit passender Priorität.
Bilder unterhalb des Folds laden verzögert.
srcset und sizes bilden die realen Layoutbreiten ab.
Alt-Texte beschreiben den Inhalt, wenn das Bild Informationen trägt.

Die Bildqualität darf sichtbar bleiben. Ein matschiges Hero spart Bytes und kostet Vertrauen. Ich suche deshalb den kleinsten Wert, der im tatsächlichen Layout sauber aussieht, statt jedes Bild mit derselben Qualitätsstufe zu exportieren.

Performance ist auch Architektur

Ein großes Client-Bundle entsteht selten durch eine einzelne Zeile. Häufig laden globale Komponenten Bibliotheken, die nur auf einer Route gebraucht werden. Oder ein Chat wird vollständig initialisiert, obwohl niemand ihn öffnet. Route-basiertes Splitting, dynamische Imports und ein später Start solcher Funktionen bringen dann mehr als Mikrotuning.

Das hat eine direkte Verbindung zur KI-Systemarchitektur. Klare Grenzen halten Provider austauschbar. Außerdem erlauben sie, teure Funktionen getrennt zu laden und zu messen.

Ich prüfe bei jeder globalen Abhängigkeit:

Braucht jede Route diesen Code?
Muss er vor dem ersten sichtbaren Inhalt laufen?
Kann die Funktion nach einer Interaktion geladen werden?
Bleiben Listener oder Animationen nach dem Verlassen der Seite aktiv?

Gerade der letzte Punkt fällt in statischen Screenshots nicht auf. Im echten Besuch sammeln sich solche Aufgaben über mehrere Navigationen an und machen die Seite schleichend träger.

Ein Performance-Gate für den Launch

Ein Release braucht messbare Grenzen. Für diese Website setze ich mobil mindestens 90 Punkte in Lighthouse Performance sowie mindestens 95 in Accessibility, Best Practices und SEO für Startseite und Websites-Angebot. Dazu kommen die Core-Web-Vitals-Ziele LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 in Felddaten.

Ein einzelner Lauf reicht nicht. Ich teste mehrere Durchläufe mit kaltem Cache, dokumentiere Median und Abweichungen und prüfe zusätzlich die Hauptinteraktionen. Nach dem Launch zeigen Search Console und Felddaten, ob die Laborannahmen auch bei echten Besuchern halten.

Wenn du eine Website brauchst, bei der Gestaltung, Inhalt und technische Auslieferung zusammen geplant werden, findest du den Projektrahmen unter Websites. Für ein konkretes Vorhaben führt der kürzeste Weg über Gespräch starten.

Über den Autor

Ich bin Kirk Kleinau, AI Strategist und Creative Technologist. Seit acht Jahren arbeite ich an Design, Konzeption, Projektleitung, Web und Frontend. Bei meinen eigenen Builds behandle ich Performance als Teil des Entwurfs, weil eine starke visuelle Idee nur funktioniert, wenn sie auf dem Gerät des Nutzers rechtzeitig ankommt.