Website-Performance testen mit Lighthouse und Window Performance

Wer nach "Website-Performance testen" sucht, landet meistens bei zwei Lagern. Die einen starren auf den Lighthouse-Score und jagen verbissen die 100. Die anderen ziehen sich ein paar Werte aus window.performance und glauben, damit sei das Thema erledigt. Beides ist zu kurz gedacht.

Lighthouse liefert dir eine saubere Laboraufnahme. Damit findest du schnell ungenutztes JavaScript, render-blockierende Ressourcen, schwere Bilder oder klare Regressionen zwischen zwei Releases. Das Window Performance API zeigt dir dagegen, was im Browser tatsächlich passiert: welche Requests bremsen, wann das erste sichtbare Element erscheint und ob der Main Thread nach außen zwar "fertig" wirkt, intern aber noch dicht ist.

Gerade für SEO ist diese Kombination stark. Denn schlechte Performance ist nicht nur ein Entwicklerproblem. Langsames LCP, ruckelige Interaktionen oder instabile Layouts drücken auf Rankings, Absprungrate und Conversion zugleich.

Warum ein Tool allein meistens nicht reicht

Lighthouse ist hervorragend, um eine URL schnell zu bewerten. Was es nicht kann: jeden echten Nutzerkontext nachbilden. Dein Publikum sitzt nicht geschlossen am MacBook im Büro-WLAN. Da sind Mittelklasse-Smartphones, schwankende Mobilfunknetze, Third-Party-Skripte, Cookie-Banner und Fonts, die im Labor noch harmlos aussahen.

Genau hier wird window.performance interessant. Plötzlich kannst du Fragen beantworten, die im Alltag wirklich zählen:

• Ist der Flaschenhals die Server-Antwort oder ein nachgeladener Drittanbieter?
• Kommt das langsame LCP vom Hero-Bild, vom Font oder vom Render-Blocking?
• Ist die Seite visuell da, aber technisch noch nicht reaktionsfähig?

Das ist der Unterschied zwischen "wir haben eine Zahl" und "wir haben eine Diagnose".

Lighthouse richtig nutzen, statt nur Punkte zu sammeln

Der schnellste Einstieg läuft über Chrome DevTools. URL öffnen, F12, Reiter Lighthouse, Gerät wählen, Analyse starten. Für wiederholbare Vergleiche oder CI eignet sich zusätzlich das CLI.

Wenn du vorab schon einen groben Überblick willst, schick die Seite durch den SEO Analyzer. Das ersetzt Lighthouse nicht, hilft aber dabei, problematische Seiten und mobile Schwachstellen schneller zu priorisieren.

Wichtiger als der Gesamtscore sind meistens die Detailhinweise:

• zu viel ungenutztes JavaScript
• blockierende CSS- oder Script-Ketten
• zu schwere Bilder im Above-the-fold-Bereich
• Third-Party-Code, der TBT unnötig in die Höhe treibt

Wenn du Lighthouse so liest, wird der Report vom Schulzeugnis zum Arbeitsplan.

Diese Metriken solltest du zuerst lesen

Du musst nicht jedes Kürzel auswendig kennen. Für SEO und User Experience würde ich zuerst diese Werte prüfen:

1. LCP: Wann erscheint der wichtigste sichtbare Inhalt?
2. INP: Wie schnell reagiert die Seite auf echte Eingaben?
3. CLS: Bleibt das Layout stabil oder springt es?
4. FCP: Wann verschwindet der leere Bildschirm?
5. TBT: Sehr guter Labor-Hinweis darauf, ob der Main Thread blockiert ist.

Ältere Guides reden oft noch viel über TTI oder FID. Als historische Referenz okay. Für die heutige Priorisierung bringen dir LCP, INP, CLS und TBT aber deutlich mehr.

Was dir das Window Performance API zusätzlich verrät

Hier gehst du eine Ebene tiefer. Mit performance.getEntriesByType('navigation') bekommst du Navigationsdaten. Mit resource findest du langsame Dateien. Mit paint kannst du prüfen, wann überhaupt etwas Sinnvolles erscheint. Für moderne Signale wie LCP, CLS oder Long Tasks solltest du PerformanceObserver nutzen.

1const nav = performance.getEntriesByType('navigation')[0];
2const resources = performance.getEntriesByType('resource');
3
4console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd);
5console.log('Load event:', nav.loadEventEnd);
6console.log(
7  'Top 5 slowest resources:',
8  resources.sort((a, b) => b.duration - a.duration).slice(0, 5)
9);

1const observer = new PerformanceObserver((list) => {
2  for (const entry of list.getEntries()) {
3    console.log(entry.entryType, entry.startTime, entry.duration || entry.value);
4  }
5});
6
7observer.observe({ type: 'largest-contentful-paint', buffered: true });
8observer.observe({ type: 'layout-shift', buffered: true });
9observer.observe({ type: 'longtask', buffered: true });

Wenn du INP in Produktion belastbar messen willst, solltest du das an deine RUM-Strecke oder eine web-vitals-Implementierung koppeln. Freihändig geraten bringt hier wenig.

Genau solche Vergleiche über verschiedene Netzwerkprofile sind Gold wert. Erst dort siehst du, wie schnell eine scheinbar stabile Seite auf einem normalen Mobilgerät auseinanderfällt.

Ein Workflow, der in echten Teams funktioniert

Ich würde Performance-Tests nicht romantisieren. Man braucht keinen perfekten Prozess, sondern einen belastbaren:

1. Lighthouse für den ersten Befund und die Priorisierung.
2. window.performance für Ursachenanalyse auf Ressourcen- und Timing-Ebene.
3. Abgleich mit Felddaten oder Search Console, damit Laborprobleme nicht mit echten Nutzerproblemen verwechselt werden.
4. Fix ausrollen, erneut unter denselben Bedingungen messen, nicht unter bequemeren.

Wenn der Report auf schwere Assets zeigt, kannst du vor dem Deploy zusätzlich mit dem JavaScript Compressor, dem CSS Compressor oder dem HTML Compressor aufräumen. Das ersetzt keine saubere Architektur, senkt aber unnötigen Ballast.

Fazit: Weg vom Bauchgefühl, hin zu belastbaren Ursachen

Gute Performance-Arbeit beginnt nicht bei einer hübschen Zahl. Sie beginnt in dem Moment, in dem du sauber sagen kannst, warum eine Seite langsam ist, welcher Teil des Stacks bremst und welche Änderung am meisten bringt.

Lighthouse ist dein schneller Warnmelder. Window Performance ist das Instrument für die eigentliche Fehlersuche. Zusammen liefern sie genau das, was man für bessere Rankings und bessere Nutzererlebnisse braucht. Wenn du einen ersten Gesamtcheck willst, starte mit einer URL-Prüfung in SeoSpeedup und geh von dort in die tiefe Analyse.