Entwicklung für Performance

Performance ist keine Funktion, die man am Ende hinzufügt. Wenn eine langsame Anwendung erst einmal ausgeliefert ist, sind die architektonischen Entscheidungen, die die Langsamkeit verursacht haben, oft teuer rückgängig zu machen. Geschwindigkeit muss von Anfang an mitgedacht werden — aber das bedeutet nicht, dafür Funktionalität oder Developer Experience zu opfern.

Hier sind die Praktiken, die zuverlässig schnelle, wartbare Webanwendungen hervorbringen.

#Verstehe, worauf du optimierst

Die Core Web Vitals — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) und Interaction to Next Paint (INP) — sind die Metriken, die für die wahrgenommene Performance und das Suchmaschinen-Ranking am wichtigsten sind. Bevor du irgendetwas optimierst, führe Lighthouse oder PageSpeed Insights aus und finde heraus, welche Metrik dein größtes Problem ist. Der Versuch, alles auf einmal zu verbessern, verbessert meist gar nichts.

LCP ist fast immer das Ziel mit der größten Wirkung. Es misst, wann das größte sichtbare Element geladen wird — typischerweise ein Hero-Bild oder eine Überschrift above the fold. Eine Verbesserung des LCP hat oft den größten Effekt darauf, wie schnell sich eine Seite anfühlt.

#Liefere nur das aus, was die Seite braucht

Moderne JavaScript-Bundler sind leistungsfähig, aber standardmäßig nachsichtig. Ungebremst kann eine einzelne Seite Hunderte Kilobyte JavaScript ausliefern, das läuft, bevor der Nutzer mit irgendetwas interagieren kann.

Code Splitting ist das wirksamste Gegenmittel. In Next.js erlauben dynamische Importe (next/dynamic), schwere Komponenten — Modale, Rich-Text-Editoren, Datenvisualisierungen — aufzuschieben, bis der Nutzer sie tatsächlich braucht. Der initiale Load bleibt schlank; der Rest lädt bei Bedarf.

Tree Shaking entfernt ungenutzte Exporte aus deinem Bundle, funktioniert aber nur, wenn deine Abhängigkeiten ES-Module unterstützen und du selektiv importierst. Ersetze import _ from 'lodash' durch import debounce from 'lodash/debounce' und beobachte, wie die Bundle-Größe sinkt.

#Bilder sind meist der größte Übeltäter

Nicht optimierte Bilder machen auf den meisten Marketing-Seiten den Großteil des überschüssigen Seitengewichts aus. Die Lösung ist systematisch:

• Nutze Next.js <Image> für automatische Formatkonvertierung (WebP/AVIF), responsive Größen und Lazy Loading
• Gib width und height an (oder verwende fill mit einem dimensionierten Container), um Layout Shift zu verhindern
• Ergänze priority bei Bildern above the fold, damit sie vorgeladen statt lazy geladen werden
• Speichere Originale in der doppelten maximalen Anzeigegröße und lass das CDN passende Größen ausliefern

Ein Hero-Bild, das als 3 MB großes PNG ankommt und zu einem 120 KB großen AVIF wird, ist mehr Performance-Budget wert als jede noch so große JavaScript-Optimierung.

#Cache aggressiv, invalidiere präzise

Statische Assets — Schriften, Icons, versionierte JS- und CSS-Dateien — sollten langlebige Cache-Control-Header tragen (max-age=31536000, immutable). Inhalte, die sich ändern — API-Antworten, personalisierte Daten — brauchen kürzere TTLs oder Stale-while-revalidate-Strategien.

Im Next.js App Router akzeptieren fetch-Aufrufe cache- und revalidate-Optionen, die sich in den eingebauten Data Cache integrieren. Ein revalidate: 3600 auf einer CMS-Abfrage bedeutet, dass die Seite jede Stunde aus frischen Daten neu gebaut wird — ohne ein vollständiges Deployment.

#Messen, nicht raten

Jede Performance-Behauptung sollte durch eine Messung gestützt sein. Das Performance-Panel der Chrome DevTools zeigt exakt, wo Zeit verbraucht wird. Der Network-Tab zeigt, was geladen wird und in welcher Reihenfolge. Real-User-Monitoring-Tools wie Vercel Analytics zeigen, was echte Nutzer erleben — was sich oft von Labormessungen unterscheidet.

Lege ein Performance-Budget fest, bevor du beginnst: zum Beispiel LCP unter 2,5 s, gesamtes JavaScript unter 200 KB komprimiert. Behandle eine Budgetüberschreitung genauso wie einen fehlgeschlagenen Test — behebe sie, bevor sie ausgeliefert wird.

#Der Mindset-Wandel

Die Teams, die schnelle Anwendungen ausliefern, haben keine Performance-Phase — sie haben Performance-Bewusstsein in jeder Entscheidung verankert. Wird eine neue Abhängigkeit hinzugefügt, fragt jemand, wie viel sie wiegt. Wird eine neue Seite gebaut, prüft jemand ihren LCP. Kleine gewohnheitsmäßige Checks verhindern die langsame Anhäufung von Schulden, die irgendwann einen eigenen Performance-Sprint zur Tilgung verlangt.