PageSpeed Score von 40 auf 95: Der komplette Guide

Ein PageSpeed Score unter 50 ist kein Schönheitsfehler. Er kostet Sie Besucher, Rankings und Umsatz. Google bewertet Ladezeit als Rankingfaktor, und Nutzer verlassen eine Seite, wenn sie länger als 3 Sekunden braucht. Die gute Nachricht: Die meisten Performance-Probleme lassen sich mit systematischer Arbeit lösen. Hier ist der komplette Fahrplan.

Warum PageSpeed so wichtig ist

Google hat es oft genug gesagt: Core Web Vitals sind ein Rankingfaktor. Drei Metriken entscheiden, ob Google Ihre Seite als "gut" oder "verbesserungswürdig" einstuft:

• LCP (Largest Contentful Paint): Wie schnell wird der größte sichtbare Inhalt geladen? Ziel: unter 2,5 Sekunden.
• INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Nutzer-Interaktionen? Ziel: unter 200 Millisekunden.
• CLS (Cumulative Layout Shift): Wie stabil ist das Layout beim Laden? Ziel: unter 0,1.

Neben dem Ranking-Effekt gibt es den direkten Einfluss auf Nutzerverhalten. Studien zeigen immer wieder: Jede zusätzliche Sekunde Ladezeit reduziert die Conversion Rate um 7-10%. Bei einem Online-Shop mit 10.000 Euro Monatsumsatz bedeutet eine Sekunde Verzögerung potenziell 700 bis 1.000 Euro weniger. Pro Monat.

Schritt 1: Bilder optimieren (größter Hebel)

Bilder sind fast immer der größte Performance-Killer. Eine durchschnittliche Unternehmenswebseite lädt 2-5 MB an Bildern. Mit den richtigen Maßnahmen lässt sich das auf 200-400 KB reduzieren, ohne sichtbaren Qualitätsverlust.

Modernes Format verwenden. WebP und AVIF sind deutlich kleiner als JPEG oder PNG bei gleicher Qualität. WebP wird von allen modernen Browsern unterstützt. AVIF ist noch effizienter, hat aber noch nicht ganz die gleiche Browserunterstützung. Nutzen Sie das <picture>-Element, um Fallbacks anzubieten.

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg" alt="Beschreibung"
       width="1200" height="600" loading="lazy" />
</picture>

Richtige Größe ausliefern. Ein 4000px breites Bild für einen 800px breiten Container zu laden, verschwendet 80% der Bandbreite. Erstellen Sie verschiedene Größen und nutzen Sie srcset, damit der Browser die passende wählt.

Lazy Loading. Bilder, die nicht im sichtbaren Bereich sind, müssen nicht sofort geladen werden. Das native loading="lazy" Attribut reicht für die meisten Fälle aus. Das Bild im Hero-Bereich (above-the-fold) sollte aber sofort laden, nicht lazy.

Typischer Effekt: Bei einem Kundenprojekt haben wir die Bildgröße von 3,2 MB auf 280 KB reduziert. Der LCP ging von 4,1 auf 1,8 Sekunden. Allein durch Bilder.

Schritt 2: JavaScript reduzieren und splitten

Zu viel JavaScript ist der zweithäufigste Performance-Killer. Jedes Kilobyte JavaScript muss heruntergeladen, geparst und ausgeführt werden. Besonders auf mobilen Geräten, die langsamer parsen als Desktop-Rechner, macht sich das bemerkbar.

Unnötige Libraries entfernen. Brauchen Sie wirklich jQuery, wenn Sie Vue.js nutzen? Ist Moment.js nötig, oder reicht die native Intl API? Laden Sie eine komplette Icon-Library, obwohl Sie nur 10 Icons verwenden? Prüfen Sie jede Abhängigkeit kritisch. Tools wie bundlephobia.com zeigen die Größe von npm-Paketen.

Code-Splitting und dynamische Imports. Nicht jeder Besucher braucht den Code für die Kontaktseite, wenn er die Startseite besucht. Frameworks wie Nuxt machen Route-basiertes Code-Splitting automatisch. Für große Komponenten innerhalb einer Seite (z.B. eine Kartenansicht oder einen Chart) können Sie dynamische Imports nutzen:

// Komponente wird erst geladen, wenn sie benötigt wird
const LazyMap = defineAsyncComponent(() =>
  import('~/components/MapView.vue')
)

// In Nuxt: Prefix "Lazy" genügt
<LazyContactForm v-if="showForm" />

Third-Party-Scripts optimieren. Google Analytics, Chat-Widgets, Cookie-Banner, Tracking-Pixel: Externe Scripts sind oft die größten Bremsen. Laden Sie sie asynchron oder noch besser: nach der initialen Interaktion des Nutzers. Ein Chat-Widget muss nicht in den ersten 2 Sekunden bereitstehen, wenn der Nutzer noch nicht einmal den ersten Absatz gelesen hat.

Schritt 3: CSS optimieren

CSS blockiert das Rendering. Der Browser kann nichts anzeigen, bis das CSS geladen und verarbeitet ist. Deshalb ist die Größe des CSS und die Art der Auslieferung relevant.

Critical CSS inlinen. Das CSS für den sichtbaren Bereich (above-the-fold) sollte direkt im HTML stehen, damit der Browser sofort rendern kann, ohne auf eine externe Datei zu warten. Tools wie critters (in Nuxt integrierbar) machen das automatisch.

Ungenutztes CSS entfernen. Wenn Sie ein CSS-Framework wie Bootstrap verwenden, laden Sie oft Tausende von Regeln, von denen Sie nur einen Bruchteil nutzen. Tailwind CSS löst das Problem, indem es nur die Klassen generiert, die tatsächlich im Code vorkommen. Wenn Sie ein anderes Framework nutzen, hilft PurgeCSS.

Schritt 4: Caching und Komprimierung

Caching sorgt dafür, dass wiederkehrende Besucher Dateien nicht erneut herunterladen müssen. Komprimierung reduziert die Dateigröße bei der Übertragung.

Brotli-Komprimierung aktivieren. Brotli ist der Nachfolger von Gzip und komprimiert 15-20% besser. Die meisten modernen Server und CDNs unterstützen es. In einer Nginx-Konfiguration sind es wenige Zeilen:

brotli on;
brotli_types text/plain text/css application/json
             application/javascript text/xml
             application/xml image/svg+xml;
brotli_comp_level 6;

Cache-Header setzen. Statische Assets (Bilder, Fonts, CSS, JS) ändern sich selten. Setzen Sie lange Cache-Zeiten (1 Jahr) mit Content-Hashing in den Dateinamen. Nuxt und andere Build-Tools machen das automatisch: app.a1b2c3.js wird bei jeder Änderung umbenannt, sodass der Cache automatisch erneuert wird.

Schritt 5: Server und Hosting

Die schnellste Webseite nützt nichts, wenn der Server langsam antwortet. Die Time to First Byte (TTFB) sollte unter 200 Millisekunden liegen. Wenn Ihr Server länger braucht, hilft auch die beste Frontend-Optimierung nur begrenzt.

CDN nutzen. Ein Content Delivery Network (CDN) verteilt Ihre Dateien auf Server weltweit. Ein Besucher aus München lädt die Seite von einem Server in Frankfurt statt von einem in New York. Cloudflare bietet einen kostenlosen Plan, der für die meisten Webseiten ausreicht.

HTTP/2 oder HTTP/3 verwenden. Moderne Protokolle laden Dateien parallel statt nacheinander. Wenn Ihr Server noch HTTP/1.1 nutzt, verlieren Sie Performance. Die meisten modernen Hosting-Anbieter und CDNs unterstützen HTTP/2 standardmäßig.

Schritt 6: Layout-Stabilität (CLS)

Layout-Verschiebungen passieren, wenn Elemente ihre Größe oder Position ändern, nachdem die Seite schon sichtbar ist. Das ist nervig für Nutzer (man klickt versehentlich auf den falschen Link) und schlecht für den CLS-Score.

Die häufigsten Ursachen: Bilder ohne Größenangabe, nachgeladene Fonts, dynamisch eingefügte Werbebanner, Cookie-Banner, die den Inhalt verschieben. Die Lösung: Immer width und height auf Bildern angeben. Font-Display auf swap setzen. Platzhalter für dynamische Inhalte reservieren. Cookie-Banner als Overlay statt als eingefügtes Element.

Zusammenfassung: Der typische Weg von 40 auf 95

In der Praxis sieht die Reihenfolge so aus. Die Zahlen sind typische Werte aus echten Kundenprojekten:

• Ausgangspunkt: Score 40. 3,5 MB Seitengröße. LCP 4,5s.
• Nach Bildoptimierung: Score 60. 800 KB. LCP 2,5s.
• Nach JS-Optimierung: Score 75. 500 KB. LCP 2,0s.
• Nach CSS und Caching: Score 85. 350 KB. LCP 1,5s.
• Nach CDN und CLS-Fix: Score 95. 350 KB. LCP 1,2s. CLS 0,02.

Das sind keine utopischen Werte. Das ist systematische Arbeit, die bei jedem Projekt möglich ist. Manchmal sogar in wenigen Stunden, wenn die Webseite grundsätzlich sauber gebaut ist. Bei einer komplett vermurksten Codebase dauert es länger, aber das Ergebnis lohnt sich immer.