Das Plugin-Problem
Die meisten Website-Betreiber, die über langsame Ladezeiten klagen, greifen zu Plugins: Caching-Plugins, Bild-Optimierungs-Plugins, Minification-Plugins. Sie versuchen, ein Architektur-Problem mit Bandaids zu lösen.
Das funktioniert — bis zu einem Punkt. Aber ein monolithisches CMS, das bei jedem Seitenaufruf eine Datenbank abfragt, 30 Plugins lädt und dynamisch HTML generiert, wird nie so schnell sein wie eine statisch generierte Seite, die direkt vom CDN ausgeliefert wird. Egal wie viele Caching-Layer Sie davorschalten.
Was Core Web Vitals messen
Google misst drei Metriken, die direkt ins Ranking einfließen:
LCP (Largest Contentful Paint): Wie schnell wird das größte sichtbare Element geladen? Zielwert: unter 2,5 Sekunden.
INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Nutzerinteraktionen? Zielwert: unter 200 Millisekunden.
CLS (Cumulative Layout Shift): Wie stabil ist das Layout während des Ladens? Zielwert: unter 0,1.
Diese Metriken sind nicht willkürlich — sie messen, was Nutzer tatsächlich als "schnell" oder "langsam" wahrnehmen.
Die drei Rendering-Strategien
SSG (Static Site Generation)
Die Seite wird zur Build-Zeit generiert — HTML wird einmal erstellt und dann bei jedem Aufruf direkt vom CDN ausgeliefert. Keine Datenbankabfrage, kein Server-Rendering, kein Warten.
Stärke: Maximale Performance. TTFB (Time to First Byte) ist minimal, weil es keinen Server gibt, der erst etwas berechnen muss. LCP profitiert direkt.
Schwäche: Inhaltsänderungen erfordern ein neues Build und Deployment. Bei sehr großen Websites (100.000+ Seiten) kann die Build-Zeit lang werden.
Ideal für: Blogs, Dokumentationen, Marketing-Websites, Landing Pages — alles, was sich selten ändert.
SSR (Server-Side Rendering)
Die Seite wird bei jedem Aufruf auf dem Server gerendert — dynamisch, mit aktuellen Daten. Der Server liefert fertiges HTML, das sofort im Browser angezeigt wird.
Stärke: Immer aktuelle Daten. Personalisierung möglich. SEO-freundlich, weil der Server fertiges HTML liefert (im Gegensatz zu Client-Side Rendering, wo der Browser erst JavaScript ausführen muss).
Schwäche: Jeder Seitenaufruf belastet den Server. TTFB ist höher als bei SSG, weil der Server erst rendern muss. Caching kann das mildern, aber nicht eliminieren.
Ideal für: E-Commerce, Dashboards, personalisierte Inhalte — alles, was aktuelle Daten braucht.
Hybrid Rendering
Die intelligenteste Option: Statische Seiten für alles, was selten ändert. Server-Rendering für alles, was dynamisch sein muss. Im selben Projekt, auf derselben Domain.
Nuxt.js, Next.js und Astro unterstützen Hybrid Rendering nativ. Sie entscheiden pro Route, welche Strategie passt:
/blog/**→ SSG (ändert sich selten, maximale Performance)/produkte/**→ ISR mit Revalidierung alle 60 Sekunden (Preise können sich ändern)/dashboard/**→ SSR (personalisiert, immer aktuell)
Das ist der eigentliche Architektur-Vorteil: Nicht alles muss gleich schnell sein. Aber die Seiten, die den meisten Traffic bekommen (Blog, Landing Pages, Produktübersichten), sollten maximal schnell sein.
Warum die Architektur wichtiger ist als Optimierung
Der Unterschied in Zahlen
Ein WordPress-Blog mit Caching-Plugin, Bild-Optimierung und CDN erreicht typischerweise LCP-Werte von 2-4 Sekunden. Ein Nuxt.js-Blog mit SSG und CDN erreicht 0,5-1,5 Sekunden. Das ist nicht eine marginale Verbesserung — es ist ein anderes Level.
Der Grund: Bei WordPress rendert der Server bei jedem Aufruf (oder liefert eine gecachte Version, die irgendwann invalidiert werden muss). Bei SSG existiert die fertige HTML-Datei bereits auf dem CDN — der "Server" ist das nächstgelegene Edge-Datacenter.
Plugins als Performance-Bremse
Jedes Plugin in einem monolithischen CMS ist ein zusätzlicher PHP-Prozess, eine zusätzliche Datenbankabfrage, zusätzliches CSS und JavaScript. 20 aktive Plugins bedeuten 20 potenzielle Quellen für Performance-Probleme, JavaScript-Konflikte und CSS-Bloat.
In einer modernen Frontend-Architektur gibt es keine Plugins — es gibt Dependencies, die beim Build aufgelöst werden. Nicht genutzter Code wird per Tree-Shaking entfernt. CSS wird per Component gescoped. JavaScript wird per Code-Splitting in Chunks aufgeteilt.
Edge Computing: Performance weltweit
Moderne Hosting-Plattformen (Vercel, Cloudflare Pages, Netlify) deployen Ihre Website auf Edge-Servern weltweit. Ein Besucher in München bekommt die Seite vom nächsten Edge-Server — nicht von einem zentralen Rechenzentrum in den USA.
Bei SSG ist das trivial: HTML-Dateien werden auf alle Edge-Server verteilt. Bei SSR ist es komplexer, aber möglich: Edge Functions (wie Cloudflare Workers oder Vercel Edge Functions) rendern die Seite am Edge — nah am Nutzer.
Konkrete Maßnahmen
Sofort umsetzbar (jede Architektur)
- Bilder optimieren: WebP/AVIF-Format, responsive Sizes, Lazy Loading für alles unterhalb des Viewports
- Critical CSS inlinen: Das CSS für den sichtbaren Bereich direkt in den HTML-Head
- JavaScript minimieren: Nur laden, was gebraucht wird. Drittanbieter-Scripts (Analytics, Chat-Widgets) defer oder async laden
- Fonts optimieren: font-display: swap, Preload für kritische Fonts, Subset statt kompletter Font-Datei
Langfristig (Architektur-Ebene)
- Hybrid Rendering evaluieren: Welche Seiten können statisch sein? Welche müssen dynamisch bleiben?
- CDN als Standard: Jede statische Asset sollte vom CDN kommen — nicht vom Origin-Server
- Build-Pipeline optimieren: ISR (Incremental Static Regeneration) für Seiten, die sich gelegentlich ändern
- Monitoring einrichten: Core Web Vitals über die Google Search Console oder ein Tool wie web-vitals.js tracken — nicht nur einmalig messen, sondern kontinuierlich überwachen
Fazit
Core Web Vitals sind kein Plugin-Problem — sie sind ein Architektur-Problem. Die Wahl zwischen SSG, SSR und Hybrid Rendering hat mehr Einfluss auf Ihre Ladezeiten als jedes Optimierungsplugin.
Wenn Performance für Ihr Projekt geschäftskritisch ist — für SEO, Conversions oder Nutzererlebnis —, investieren Sie in die richtige Architektur, nicht in mehr Plugins.
