Lighthouse 100 für deine bestehende Website

Warum deine Website langsam ist

Langsame Websites haben fast immer dieselben Grundursachen. Die Werkzeuge unterscheiden sich, die Symptome sind identisch. Dieses Muster sehe ich bei Magento-Shops, WordPress-Blogs, Wix-Seiten und Custom Builds:

• Zu grose JavaScript-Bundles, die der Browser parsen muss, bevor etwas sichtbar wird. Jede unnotige Library zahlt.
• Render-blockierende Ressourcen: CSS oder Skripte im <head>, die das Zeichnen der Seite blockieren.
• Bilder ohne Kompression, ohne WebP-Konvertierung, ohne korrektes Sizing pro Viewport.
• Hohe TTFB (Time to First Byte) durch einen langsamen Server, fehlende Cache-Schichten oder eine Datenbankabfrage bei jeder Anfrage.
• Third-Party-Skripte, die asynchron laden, aber trotzdem den Main Thread belegen: Google Tag Manager, Chat-Widgets, Consent-Banner, Social Embeds.

Die meisten Websites haben drei oder vier davon gleichzeitig. Das ist kein Zufall. Plattformen wie Wix und fruhe WordPress-Themes wurden für Funktionalität gebaut, nicht für Geschwindigkeit. Die technische Schuld wachst, solange niemand sie aktiv im Blick hat.

Was Core Web Vitals wirklich messen

Google misst drei Signale für Nutzererfahrung. LCP (Largest Contentful Paint) misst, wie schnell das groste sichtbare Element geladen ist. Das ist fast immer ein Hero-Bild oder eine grose Uberschrift. Alles über 2,5 Sekunden ist schlecht. Alles über 4 Sekunden ist sehr schlecht.

INP (Interaction to Next Paint) misst, wie schnell die Seite auf einen Klick oder Tastenanschlag reagiert. Es ersetzte 2024 definitiv den First Input Delay und ist jetzt das wichtigste Reaktivitäts-Signal. CLS (Cumulative Layout Shift) misst, wie stabil die Seite während des Ladens ist. Schaltflachen, die verschieben, Text, der durch spat ladende Werbung hochrutscht: das sind CLS-Quellen.

Google nutzt diese drei als Ranking-Signale in den Suchergebnissen. Aber abseits von SEO: Eine Seite mit 4 Sekunden LCP verliert durchschnittlich 7% Conversion pro zusatzlicher Sekunde Verzogerung. Das sind keine abstrakten Statistiken. Das sind Bestellungen, Anfragen und Kontaktformulare, die nie ankommen.

Mein Audit-Ansatz

Ein Performance-Audit ohne Daten ist Raten. Ich messe immer zwei Dinge gleichzeitig: Lab-Daten und Field-Daten. Lab-Daten kommen aus Lighthouse und der PSI API, ausgefuhrt gegen deine URL unter kontrollierten Bedingungen. Field-Daten kommen aus dem Chrome User Experience Report (CrUX), den echten Messwerten deiner Besucher über die letzten 28 Tage.

• PSI-API-Lauf auf allen kritischen Seiten: Homepage, Kategorienseite, Produktseite, Kontaktseite. Jede Seite separat, da Probleme selten einheitlich sind.
• Network-Waterfall-Analyse in Chrome DevTools: welche Ressource was blockiert, welche Anfragen sequenziell sind, die parallel laufen konnten.
• Treeshake-Check auf JavaScript-Bundles: welche Abhangigkeiten geladen, aber teilweise oder gar nicht genutzt werden.
• Bild-Audit: Format, Kompressionsverhaltnis, Dimensionen versus Anzeigegrosse, Lazyload-Implementierung.
• Third-Party-Impact-Messung: wie viel Main-Thread-Zeit Skripte außerhalb deiner Domain beanspruchen.

Das Ergebnis ist eine priorisierte Liste von Engpassen, sortiert nach Auswirkung. Nicht alle Probleme sind gleich schwer. Ich beginne dort, wo der groste Gewinn liegt.

Was ich typischerweise behebe

Nach dem Audit implementiere ich die Fixes. Auf den meisten Websites handelt es sich um eine Kombination folgender Eingriffe:

• Next.js Image-Komponente: automatische WebP-Konvertierung, korrektes Sizing via srcset, Lazy Load für Elemente außerhalb des Viewports, Eager Load für das LCP-Bild.
• ISR-Cache-Konfiguration: Seiten werden gerendert und als statische Dateien gecacht, sodass der Server pro Besucher nichts berechnen muss.
• Font-display: swap auf Webfonts setzen, damit die Seite Text anzeigt, während die Schrift ladt, statt eines unsichtbaren Flackerns.
• CSS-Blocking entfernen: kritisches CSS inline, nicht-kritisches CSS deferred oder via Preload mit Media Queries.
• Third-Party-Skripte deferred laden: Google Analytics, GTM und Consent-Banner nach dem First Contentful Paint, nicht davor.
• Kritische Bilder vorladen: die LCP-Ressource im <head> anmelden, damit der Browser sie früher abruft.

Welche Fixes zutreffen, hängt von deinem Stack ab. Bei einer Magento-Installation ziehe ich andere Hebel als bei einer WordPress-Seite oder einer Next.js-Anwendung. Der Ansatz ist immer spezifisch für das, was die Daten zeigen.

Was ich nicht mache

Es gibt Abkurzungen, die einen Lighthouse-Score nach oben treiben, ohne die Nutzererfahrung zu verbessern. Ich verwende sie nicht.

• Ressourcen vorladen, die nicht auf dem kritischen Pfad liegen, nur um den Score zu erhohen.
• Font-display: optional setzen, damit Fonts weggelassen werden, wenn sie nicht schnell genug laden. Scored besser, sieht schlechter aus.
• Bilder entfernen oder verbergen, um CLS zu senken, ohne die Grundursache zu beheben.
• Content Security Policy Header so anpassen, dass Third-Party-Skripte kaputtgehen, um ihre Auswirkungen zu verbergen.
• Lighthouse-Bots eine leichtere Seite anzeigen als echten Besuchern. Google erkennt das.

Ein Score von 100 auf einer Seite, die niemand besucht, ist wertlos. Ich optimiere die Seiten, die Traffic bringen, mit Fixes, die unter echten Nutzern auf echten Netzwerken standhalten.

Tools, die ich verwende

Der Kern meines Werkzeugkastens: die PSI API für reproduzierbare Lab-Scores auf jeder URL, Chrome DevTools für Network Waterfall und Main-Thread-Profiling, WebPageTest für Multi-Step- und geographisches Testing, sowie Lighthouse CI in der Build-Pipeline, damit Regressionen fruh erkannt werden. Für Field-Daten verwende ich das CrUX-Dashboard und den Google Search Console Core Web Vitals-Bericht.

Bei Magento-spezifischer Arbeit nutze ich zudem Blackfire für PHP-Profiling langsamer Backend-Prozesse sowie das Magento Performance Toolkit für Lastmuster. Auf Next.js-Stacks analysiere ich Bundle-Output via @next/bundle-analyzer und trace Server-Side-Rendering-Engpasse mit dem integrierten Next.js Trace Viewer.

Weiterlesen