Kostenlos und datenschutzfreundlich

Website-Performance-Simulator

Zuletzt aktualisiert:

Core-Web-Vitals-Werte eingeben, um einen gewichteten Performance-Score und Risiken zu modellieren.

Läuft lokal im Browser. Es werden keine Daten übertragen.

Wobei dieses Tool hilft

Wobei dieses Tool hilft

Nutzen Sie dieses Tool, bevor Sie Lighthouse ausführen oder einen vollständigen Performance-Audit beauftragen. Geben Sie die gemessenen (oder erwarteten) Core Web Vitals ein und modellieren Sie, wie verschiedene Geräte- und Netzwerkbedingungen den simulierten Gesamt-Score verändern: um Optimierungsarbeit auf die Faktoren zu priorisieren, die für Ihre am schlechtesten versorgten Nutzer den Unterschied machen.

Eingabewerte

Ergebnisse

Wie die Simulationsausgabe zu interpretieren ist

Der Score ist ein Richtungsmodell: er spiegelt wider, wie die eingegebenen Metriken unter dem gewählten Profil interagieren, und ersetzt keine gemessenen Felddaten. Für die Priorisierung verwenden, dann mit Lighthouse oder CrUX validieren.

  • LCP hat das höchste individuelle Gewicht im Modell, da es die Ladedauer des größten Inhalts widerspiegelt: seine Verbesserung bewegt den Score in der Regel am stärksten.
  • INP-Strafen werden unter Low-End-CPU-Profilen prominenter, wo die JavaScript-Task-Länge die Verzögerung verstärkt.
  • CLS trägt weniger zum Score bei als LCP oder INP, kann aber trotzdem eine Randseite unter einen Schwellenwert drücken.
  • Das Netzwerkprofil multipliziert die effektive Ladezeit: eine Seite, die auf Lab/Kabelgebunden gut abschneidet, kann auf Mobil 3G deutlich schlechter werden.
  • Die Simulation auf mehreren Seiten ausführen, Produktdetailseiten, Artikelseiten und Kategorieseiten, nicht nur auf der Homepage, die meist die schnellste ist.

Annahmen

  • Eingaben sind synthetische Werte und ersetzen keine tatsächlichen Feldmessungen aus CrUX oder RUM-Daten.
  • Score-Schwellenwerte sind Näherungen der Lighthouse-Scoring-Methodik und stimmen möglicherweise nicht exakt überein.

Nächster Schritt

Nächsten Schritt entdecken

Core-Web-Vitals-Werte eingeben, um einen gewichteten Performance-Score und Risiken zu modellieren.

Redaktionelle Prüfung

So wurde diese Seite aufgebaut

Diese Seite kombiniert den Live-Rechner, Eingabehinweise, Beispielrechnungen und typische Grenzen, damit Website-Performance-Simulator nicht nur schnell, sondern auch nachvollziehbar genutzt werden kann.

Zuletzt im Klartext-Tools-Review auf Basis des aktuellen Website-Performance-Simulator-Setups am 2026-02-24 geprüft.

Zuletzt aktualisiert:

Bitte beachten

Annahmen

  • Eingaben sind synthetische Werte und ersetzen keine tatsächlichen Feldmessungen aus CrUX oder RUM-Daten.
  • Score-Schwellenwerte sind Näherungen der Lighthouse-Scoring-Methodik und stimmen möglicherweise nicht exakt überein.

Seitenüberblick

Was diese Seite abdeckt

  • So verwenden Sie dieses Tool
  • Beispielwerte und Szenarien
  • Wie die Simulationsausgabe zu interpretieren ist
  • Einsatzfälle
  • Best Practices
  • Warum das wichtig ist
  • Was dieses Tool macht

Praxisbeispiele

Gut optimierte Desktop-Seite

Gute Core Web Vitals auf einer kabelgebundenen Verbindung mit High-End-Gerät: eine Ausgangslage für eine schnell ladende Marketing-Seite.

FCP
0,9 s
LCP
1,8 s
INP
80 ms
CLS
0,02
Netzwerk
Lab / Kabelgebunden
CPU
High-End-Gerät

Hoher Performance-Score: nützlich als Referenzpunkt vor dem Anwenden mobiler Drosselung.

Nach dem Laden auf Mobil 3G und Einstiegs-Gerät umstellen, um zu sehen, wie der Score für dieselben Metriken sinkt.

Langsame Mobile-Seite mit hohem LCP

Eine Seite mit schwerem Hero-Bild und langsamer Server-Antwortzeit, getestet auf einem Mittelklasse-Gerät mit 3G-Drosselung.

FCP
3,2 s
LCP
5,8 s
INP
320 ms
CLS
0,14
Netzwerk
Mobil 3G
CPU
Mittelklasse-Gerät

Niedriger Performance-Score: zeigt, wie LCP über 4 Sekunden die stärkste Verschlechterung unter eingeschränkten Bedingungen verursacht.

LCP auf 2,5 s reduzieren und andere Eingaben konstant lassen, um den LCP-Beitrag zur Score-Verbesserung zu isolieren.

So verwenden Sie dieses Tool

Geben Sie die Core Web Vitals aus einem aktuellen Lighthouse-Lauf oder aus CrUX-Felddaten ein. Echte Messungen statt Standardwerte verwenden, um richtungsweisende Ergebnisse zu erhalten.

  1. FCP und LCP in Sekunden, INP in Millisekunden und CLS als Dezimalzahl eingeben.

  2. Das Netzwerkprofil wählen, das die Zielgruppe am besten repräsentiert. Lab/Kabelgebunden für Desktop-Benchmarks, Mobil 4G oder 3G für realistische Feldbedingungen.

  3. Das CPU-Profil wählen, das dem Geräteklasse entspricht, die am meisten interessiert.

  4. Simulation ausführen und den Haupt-Score sowie die Metrik-Status-Indikatoren notieren.

  5. Einen Eingabewert nach dem anderen ändern, um zu ermitteln, welche Metrik unter dem gewählten Profil am meisten zur Score-Verschlechterung beiträgt.

Beispielwerte und Szenarien

Ein gut optimiertes Szenario und ein degradiertes Mobile-Szenario ausprobieren, um zu verstehen, wie das Scoring-Modell die einzelnen Metriken gewichtet.

Gut optimierte Desktop-Seite

Gute Core Web Vitals auf einer kabelgebundenen Verbindung mit High-End-Gerät: eine Ausgangslage für eine schnell ladende Marketing-Seite.

Beispielwerte

FCP
0,9 s
LCP
1,8 s
INP
80 ms
CLS
0,02
Netzwerk
Lab / Kabelgebunden
CPU
High-End-Gerät

Beispielausgabe: Hoher Performance-Score: nützlich als Referenzpunkt vor dem Anwenden mobiler Drosselung.

Nach dem Laden auf Mobil 3G und Einstiegs-Gerät umstellen, um zu sehen, wie der Score für dieselben Metriken sinkt.

Langsame Mobile-Seite mit hohem LCP

Eine Seite mit schwerem Hero-Bild und langsamer Server-Antwortzeit, getestet auf einem Mittelklasse-Gerät mit 3G-Drosselung.

Beispielwerte

FCP
3,2 s
LCP
5,8 s
INP
320 ms
CLS
0,14
Netzwerk
Mobil 3G
CPU
Mittelklasse-Gerät

Beispielausgabe: Niedriger Performance-Score: zeigt, wie LCP über 4 Sekunden die stärkste Verschlechterung unter eingeschränkten Bedingungen verursacht.

LCP auf 2,5 s reduzieren und andere Eingaben konstant lassen, um den LCP-Beitrag zur Score-Verbesserung zu isolieren.

Warum das wichtig ist

Die meisten Performance-Optimierungsentscheidungen werden mit unvollständigen Daten getroffen: ein Lighthouse-Score von einer schnellen Verbindung, ein Waterfall von einem Testlauf oder ein subjektives Gefühl vom Entwickler-Laptop. Ein Simulator ermöglicht zu modellieren, wie verschiedene Kombinationen aus Asset-Größe, Server-Antwortzeit und Verbindungstyp die Ladeerfahrung über die tatsächliche Nutzerverteilung hinweg beeinflussen: nicht nur den Median. Nutzen Sie das, um Prioritäten zu setzen, bevor Tests durchgeführt werden, und konzentrieren Sie Änderungen auf die Faktoren, die für Ihre langsamsten Nutzersegmente den Unterschied machen.

Best Practices

  • Time to First Byte priorisieren, bevor Asset-Größen optimiert werden. Server-Antwortzeit beeinflusst alle anderen Metriken nachgelagert.
  • Simulierten Load auf repräsentativen Inhaltsseiten testen, nicht nur auf der Homepage. Produkt- und Artikelseiten laden oft deutlich mehr Assets.
  • Verbindungs-Presets verwenden, die der tatsächlichen Traffic-Verteilung entsprechen, nicht nur dem schnellsten Tier.

Einsatzfälle

  • Schätzen Sie Materialmengen vor dem Kauf, um Projektverlust zu reduzieren.
  • Vergleichen Sie Szenarien direkt vor Ort und passen Sie Mengen in Echtzeit an.
  • Erstellen Sie klarere Projektpläne mit nachvollziehbarer Rechenlogik.

Website-Health-Audit fortsetzen

Leitfäden

  • So validieren Sie robots.txt vor einem Website-Launch

    Die meisten robots-Fehler beim Launch sind vermeidbar. Das Problem ist nicht, dass robots.txt schwer waere. Das Problem ist, dass Teams die Datei zu spät prüfen, zu wenig testen oder einige funktionierende URLs mit einer sicheren Crawl-Richtlinie verwechseln.

  • So prüfen Sie hreflang vor einem mehrsprachigen Seitenstart

    hreflang-Fehler sind kostspielig, weil sie Lokalisierungsarbeit nach dem Seitenstart entwerten. Ein mehrsprachiger Release kann strukturell vollständig wirken und trotzdem beim Sprach-Targeting scheitern, wenn gegenseitige Verlinkungen, URL-Zuordnungen oder die Seitenverfügbarkeit nicht vor der Veröffentlichung geprüft werden.

Leitfäden durchsuchen

Vergleiche

  • Robots.txt-Prüfer vs Robots.txt-Tester

    Diese Tools überschneiden sich, beantworten aber unterschiedliche Launch-Fragen. Robots.txt-Prüfer ist stärker, wenn Sie die gesamte Datei als Richtlinie prüfen wollen. Robots.txt-Tester ist stärker, wenn Sie für eine konkrete URL und einen bestimmten Bot ein klares Ja-oder-Nein brauchen.

  • Kostenlose vs. kostenpflichtige SEO-Launch-Tools für kleine Teams

    Kleine Teams stehen vor einem Launch oft an einem Entscheidungspunkt: Reichen kostenlose browserbasierte Tools aus, oder rechtfertigt dieser Release eine kostenpflichtige SEO-Suite? Die ehrliche Antwort hängt weniger von Überzeugungen ab als von Skalierung, Verantwortlichkeit und dem Risikogehalt des Release-Fensters.

Vergleiche durchsuchen

Tools und Themen

Geprüft von Klartext Tools

  • Mit dem Klartext-Tools-Reviewprozess für praktische Browser-Workflows geprüft.
  • Annahmen und Grenzen stehen direkt auf der Seite vor den Entscheidungshilfen.
  • Beispiele und FAQ sind enthalten, damit das Ergebnis gegen ein zweites Szenario geprüft werden kann.

Häufig gestellte Fragen

Ist das ein Lighthouse-Ersatz?
Nein. Es ist eine Richtungssimulation für Planung und Priorisierung. Für schnelle Szenarioplanung verwenden, dann mit Lighthouse oder CrUX-Felddaten validieren, sobald Änderungen deployt sind.
Welche Metrik schadet in der Regel am meisten?
LCP und INP dominieren oft die wahrgenommene Geschwindigkeit und Reaktionsfähigkeit. LCP reagiert am stärksten auf Bildgröße und Render-blockierende Ressourcen; INP am stärksten auf lange JavaScript-Tasks und Main-Thread-Überlastung.
Was ist der Unterschied zwischen Netzwerk- und CPU-Profil?
Das Netzwerkprofil simuliert Verbindungsgeschwindigkeit und Latenz, es beeinflusst, wie schnell Assets laden. Das CPU-Profil simuliert die Geräteverarbeitungsleistung, es beeinflusst, wie schnell der Browser parsen, JavaScript ausführen und auf Nutzerinteraktionen reagieren kann. Ein Mittelklasse-Gerät auf 4G kann trotzdem hohen INP produzieren, wenn der Main Thread mit JavaScript-Tasks überlastet ist.
Warum bewirkt eine FCP-Verbesserung weniger als eine LCP-Verbesserung?
FCP markiert, wann der erste Inhalt erscheint, aber LCP markiert, wann das größte sichtbare Element fertig geladen ist: was viel enger mit der wahrgenommenen Ladeabschluss-Erfahrung zusammenhängt. Das Scoring-Modell gewichtet LCP stärker, weil es das Empfinden des Nutzers, ob die Seite bereit zur Nutzung ist, besser widerspiegelt.
Welchen CLS-Wert sollte ich anstreben?
Googles Schwellenwert für einen guten CLS-Score liegt bei 0,1 oder darunter. Werte zwischen 0,1 und 0,25 gelten als verbesserungsbedürftig. Über 0,25 ist schlecht. Häufige Ursachen für hohen CLS sind Bilder ohne explizite Abmessungen, dynamisch injizierte Banner und Web Fonts, die beim Einwechseln Layout-Verschiebungen verursachen.
Was zeigt Website-Performance-Simulator genauer als ein einfacher website-performance-simulator online?
Website-Performance-Simulator ist auf einen klar begrenzten Anwendungsfall ausgelegt: Core-Web-Vitals-Werte eingeben, um einen gewichteten Performance-Score und Risiken zu modellieren. Das Tool liefert dafür klare, reproduzierbare Ergebnisse direkt im Browser.
Welche Eingaben beeinflussen das Ergebnis am stärksten?
Beginnen Sie mit FCP (Sekunden), LCP (Sekunden), INP (ms). Schon kleine Änderungen an diesen Feldern verschieben das Ergebnis oft deutlich, deshalb lohnt sich mindestens ein zweites Vergleichsszenario.
Eignet sich Website-Performance-Simulator für schnelle Szenariovergleiche?
Ja. Website-Performance-Simulator ist für schnelle Was-wäre-wenn-Vergleiche gedacht, damit Sie Annahmen direkt im Browser prüfen und Varianten ohne Umwege vergleichen können.

Kategorie-übergreifende Empfehlungen

Wenn das Problem über diese Kategorie hinausgeht, helfen diese Tools aus anderen Bereichen beim nächsten Schritt.