Lighthouse-Score über 95: Page Speed Optimierung die funktioniert

Jede Sekunde Ladezeit kostet dich Besucher. Amazon hat berechnet, dass 100 Millisekunden mehr Ladezeit 1% weniger Umsatz bedeuten. Für kleine Unternehmen ist der Effekt proportional noch größer — weil du weniger Vertrauensvorschuss hast als Amazon.

Lighthouse Audit: So findest du heraus, wo das Problem liegt

Lighthouse ist Googles offizielles Tool zur Performance-Analyse. Es ist in Chrome integriert (F12 → Lighthouse Tab) und auch über PageSpeed Insights (web.dev/measure) erreichbar.

Ein Lighthouse Audit gibt dir Scores in vier Kategorien: Performance, Accessibility, Best Practices und SEO. Für die Ladezeit ist der Performance-Score entscheidend.

So liest du den Lighthouse Report:

1. 01Öffne PageSpeed Insights und gib deine URL ein
2. 02Warte auf die Ergebnisse — der Test dauert 15–30 Sekunden
3. 03Oben: Reale Nutzerdaten (CrUX) — das ist was Google für das Ranking nutzt
4. 04Unten: Lab-Daten — simulierter Test unter kontrollierten Bedingungen
5. 05Scrolle zu 'Opportunities' — hier stehen konkrete Verbesserungen mit geschätztem Zeitgewinn
6. 06Dann 'Diagnostics' — technische Details zu Problemen

Wichtig: Teste immer im Mobile-Modus. Google rankt basierend auf Mobile-Performance, nicht Desktop. Ein Score von 95 auf Desktop und 45 auf Mobile hilft dir nicht.

Bildformate: WebP, AVIF und warum JPEG veraltet ist

Bilder machen im Durchschnitt 50% des Seitengewichts aus. Das richtige Format spart massiv Bandbreite:

• JPEG: Der Klassiker. Gute Kompression für Fotos, aber 25–35% größer als WebP bei gleicher Qualität.
• PNG: Verlustfrei, groß. Nur für Grafiken mit Transparenz, nie für Fotos.
• WebP: Von Google entwickelt. 25–35% kleiner als JPEG, unterstützt Transparenz. 2026 von 97% aller Browser unterstützt.
• AVIF: Noch besser als WebP — 30–50% kleiner als JPEG. Aber langsamere Encoding-Zeit und 2026 noch Lücken bei älteren Android-Geräten (ca. 90% Support).

Die Empfehlung: WebP als Standard, AVIF als Progressive Enhancement mit dem picture-Element. So bekommen moderne Browser AVIF und alle anderen WebP.

Font Loading: Der unsichtbare Performance-Killer

Webfonts sind einer der häufigsten Gründe für langsame Ladezeiten — und die meisten Website-Betreiber wissen es nicht. Eine einzige Google Fonts Einbindung kann drei Probleme verursachen:

1. 01DNS-Lookup zu fonts.googleapis.com — kostet 50–100ms
2. 02CSS-Download vom Font-Server — nochmal 50–100ms
3. 03Font-Dateien Download (pro Schriftschnitt 20–80KB) — 100–300ms

Die Lösung ist ein Drei-Stufen-Ansatz:

• Preconnect: <link rel="preconnect" href="https://fonts.googleapis.com"> im Head — startet DNS und TLS parallel
• Display Swap: &display=swap im Google Fonts URL — zeigt sofort Fallback-Schrift, tauscht nach Laden
• Self-Hosting: Noch besser — Fonts lokal hosten eliminiert den externen Request komplett. Next.js macht das mit next/font automatisch.

CSS und JavaScript: Weniger ist schneller

Jedes Kilobyte CSS und JavaScript muss heruntergeladen, geparst und ausgeführt werden. Auf Desktop ist das kaum spürbar — auf einem Mittelklasse-Android-Smartphone kann das Parsen von 500KB JavaScript eine volle Sekunde dauern.

Konkrete Optimierungen:

• Code-Splitting: Lade nur das JavaScript, das die aktuelle Seite braucht. Next.js macht das automatisch pro Route.
• Tree Shaking: Entferne ungenutzten Code. Moderne Bundler (Webpack 5, Turbopack) machen das automatisch — aber nur wenn du ES Modules nutzt.
• CSS Purging: Entferne ungenutztes CSS. Tailwind CSS v4 macht das automatisch.
• Minification: Entferne Whitespace und verkürze Variablennamen. Spart 20–30%.
• Compression: Brotli (statt Gzip) spart nochmal 15–20% Transfergröße.

Ein WordPress-Plugin wie Elementor lädt 300–600KB CSS und 400–800KB JavaScript — auf jeder einzelnen Seite, egal ob die Funktionen genutzt werden. Eine gut gebaute Next.js Seite kommt mit 50–100KB CSS und 80–150KB JavaScript für die gesamte Seite aus.

Server Response Time: TTFB unter 200ms

Time to First Byte (TTFB) misst, wie lange es dauert bis der Server den ersten Byte der Antwort sendet. Alles über 200ms ist zu langsam.

Häufige Ursachen für langsame TTFB:

• Shared Hosting: 20 Websites auf einem Server. Wenn einer der Nachbarn Traffic-Spitze hat, leidet deine Seite mit.
• Kein Caching: Jede Anfrage generiert die Seite neu aus der Datenbank.
• Zu viele Datenbankabfragen: WordPress mit 30 Plugins macht pro Seitenaufruf 50–200 Datenbankabfragen.
• Kein CDN: Der Server steht in den USA, der Nutzer in Lörrach — 150ms allein für den Hin- und Rückweg.
• PHP statt Node.js: PHP muss bei jedem Request neu starten. Node.js hält die Verbindung offen.

Next.js löst viele dieser Probleme von Haus aus: Server-Side Rendering mit Caching, automatische statische Optimierung, und Edge Functions die nahe am Nutzer ausgeführt werden.

Caching und CDN: Inhalte näher am Nutzer

Caching bedeutet: Inhalte werden einmal generiert und dann aus dem Speicher ausgeliefert statt jedes Mal neu berechnet. Es gibt mehrere Ebenen:

• Browser-Cache: Der Browser speichert Dateien lokal. Bei wiederholten Besuchen muss nichts neu geladen werden.
• Server-Cache: Der Server speichert fertige HTML-Seiten. Statt Datenbank → PHP → HTML passiert nur Cache → HTML.
• CDN-Cache: Ein Content Delivery Network speichert deine Inhalte auf Servern weltweit. Ein Nutzer in Freiburg bekommt die Seite vom CDN-Knoten in Frankfurt statt vom Server in den USA.

Cache-Header richtig setzen ist entscheidend: Statische Assets (CSS, JS, Bilder) sollten cache-control: public, max-age=31536000, immutable haben — das heißt: 1 Jahr cached, nie nachfragen. Für HTML-Seiten: cache-control: public, max-age=0, must-revalidate — immer beim Server nachfragen ob sich was geändert hat.

Render-Blocking Resources eliminieren

Render-Blocking Resources sind CSS- und JavaScript-Dateien, die den Browser daran hindern, die Seite anzuzeigen bis sie vollständig geladen sind. Der Browser sagt: 'Ich kann nichts anzeigen, bevor ich dieses CSS interpretiert habe.'

Lösungen:

• Critical CSS inlinen: Das CSS für den sichtbaren Bereich (Above the Fold) direkt in den HTML-Head schreiben. Der Rest wird asynchron nachgeladen.
• JavaScript defer/async: <script defer> lädt das Script parallel und führt es nach dem HTML-Parsing aus. <script async> führt es sofort nach dem Download aus — nur für unabhängige Scripts.
• Font Display Swap: Zeigt sofort den Fallback-Font, tauscht nach dem Laden.
• Preload: <link rel="preload"> für kritische Resources die der Browser sonst erst spät entdeckt.

PageSpeed und SEO: Der direkte Zusammenhang

Seit 2021 sind Core Web Vitals ein offizieller Google Ranking-Faktor. Das heißt: Bei gleicher Inhaltsqualität rankt die schnellere Seite höher.

In der Praxis ist der Effekt moderat — Content und Backlinks sind immer noch die stärksten Faktoren. Aber Page Speed ist der Tiebreaker: Wenn zehn Ergebnisse für 'Friseur Lörrach' ähnlich relevant sind, gewinnt die schnellste Seite.

Noch wichtiger als das direkte Ranking-Signal ist der indirekte Effekt: Schnelle Seiten haben niedrigere Bounce Rates (weil Nutzer nicht abspringen), höhere Verweildauer und mehr Seitenaufrufe pro Besuch. All das sind positive Nutzersignale, die Google erkennt.

Page Speed Optimierung ist kein einmaliges Projekt — es ist ein laufender Prozess. Jedes neue Bild, jedes neue Script, jeder neue Tracker verschlechtert die Performance. Deshalb gehört ein monatlicher Lighthouse-Check zu jeder Website-Wartung. Bei 24HWEB ist das Teil unseres 49€/Monat Wartungspakets.