Dieser kostenlose Website-Speed-Test führt ein vollständiges Google-Lighthouse-Audit für jede öffentlich erreichbare URL aus und liefert vier Scores von 0 bis 100 — Performance, Barrierefreiheit, Best Practices und SEO — sowie Labor-Core-Web-Vitals wie LCP und CLS. Wählen Sie mobil oder Desktop, jeder Lauf ist neu. Ohne Anmeldung, ohne Kreditkarte: Geben Sie oben eine URL ein.
Geprüft von Charles Duncan, Co-founder & CTOIm Hintergrund fordert das Tool von Googles PageSpeed-Insights-API ein Audit der eingegebenen URL an und stellt den zurückgelieferten Lighthouse-Bericht im offiziellen Lighthouse Viewer dar — dieselbe Engine und dieselbe Bewertung wie in den Chrome DevTools, ausgeführt auf Googles Infrastruktur statt auf Ihrem Rechner.
Fügen Sie eine öffentlich erreichbare URL ein — Startseite, Produktseite oder Blogbeitrag. Kein Konto, keine Domain-Verifizierung, kein Tag zum Einbauen.
Mobil läuft auf einem gedrosselten Mittelklasse-Smartphone-Profil, Desktop auf einer schnellen Kabelverbindung — die beiden Läufe sind nicht vergleichbar. Wählen Sie den, der zu Ihrem Traffic passt, und haken Sie die gewünschten Kategorien an.
Der komplette Lighthouse-Bericht öffnet sich auf der Seite: vier Scores, die zugrunde liegenden Labormetriken und eine sortierte Liste von Optimierungen mit der jeweils geschätzten Zeitersparnis.
Alles in diesem Raster läuft sofort, ohne Konto. Die markierten Funktionen schalten Sie mit einem kostenlosen SEOmator-Konto frei.
Performance, Barrierefreiheit, Best Practices und SEO werden im selben Lauf bewertet — eine schnelle Seite, die bei der Barrierefreiheit durchfällt, kann sich nicht hinter einer Zahl verstecken.
LCP und CLS liefert jeder Lauf mit, dazu Total Blocking Time — den Laborersatz für INP, das sich nur an echten Besuchern messen lässt.
Mobil wird bewusst gedrosselt, Desktop nicht. Testen Sie beides — die Lücke zwischen den Werten zeigt meist, wo das eigentliche Problem sitzt.
Lighthouse schätzt, wie viel Ladezeit jede Maßnahme zurückgibt. So arbeiten Sie die Liste von oben ab, statt zu raten.
Der Bericht listet jede einzelne Lighthouse-Prüfung mit Ergebnis und Erklärung auf — nicht nur den Gesamtwert und eine Marketing-Zusammenfassung.
Jeder Test startet ein neues Audit gegen die Live-Seite. Nichts stammt aus einem Wert, den jemand anderes vor einem Monat erzeugt hat.
Verfolgen Sie, wie sich die Performance von Release zu Release entwickelt, statt selbst Screenshots zu vergleichen.
Erfahren Sie sofort, wenn ein Release eine Seite verlangsamt — statt es Wochen später im Ranking-Bericht zu entdecken.
Lassen Sie alle 251 Audit-Regeln über Ihre gesamte Website laufen, mit nach Wirkung priorisierten Problemen statt URL für URL.
Erstellen Sie ein kostenloses SEOmator-Konto, um die Ladezeit dauerhaft zu verfolgen, bei Verschlechterungen benachrichtigt zu werden und jede Seite statt einer zu prüfen.
Kostenlos registrieren
Geprüft vonCharles Duncan · Co-founder & CTOIch verantworte hier Crawler und Audit-Engine und lese entsprechend viele Lighthouse-Berichte. Dieses Tool gibt Ihnen Googles eigenes Urteil — den echten Lighthouse-Bericht, mit Googles Bewertung, in einem Klick und ohne Konto. Als wir am 1. Oktober 2026 115 Ergebnisse von Googles erster Seite durch dieselbe Engine geschickt haben, lag der mobile Median bei 45, und die Position hing messbar nicht mit dem Score zusammen. Die ehrliche Einschränkung: Es sind Labordaten, also ein simulierter Seitenaufruf von Googles Infrastruktur und nicht das, was Ihre Besucher tatsächlich erlebt haben. Nutzen Sie den Wert als Diagnose und bestätigen Sie die Verbesserung mit Felddaten in der Google Search Console, bevor Sie jemandem sagen, die Seite sei schneller geworden.
Charles Duncan · Co-founder & CTOVon 115 Ergebnissen der ersten Google-Seite, die wir am 1. Oktober 2026 getestet haben, zeigten nur 8,7 % ihren Hauptinhalt im Labor innerhalb von 2,5 Sekunden – und LCP plus Total Blocking Time tragen 55 % des Performance-Scores. Wenn Sie nur eine Sache beheben, beheben Sie das, was zuletzt gerendert wird.
Lighthouse drosselt Mobilgeräte bewusst stark. Eine 94 auf dem Desktop neben einer 41 auf dem Smartphone ist normal, kein Fehler — und die mobile Version ist die, die Google indexiert.
INP hat First Input Delay im März 2024 als Core Web Vital abgelöst und lässt sich nur an echten Besuchern messen. TBT ist der nächstliegende Laborwert: Ist TBT hier hoch, sollten Sie INP im Feld prüfen.
Jede Optimierung trägt eine geschätzte Ersparnis in Sekunden. Setzen Sie den obersten Punkt um, testen Sie erneut und prüfen Sie, ob die Schätzung gehalten hat. Zwei, drei kurze Durchgänge schlagen eine spekulative Komplettüberarbeitung.
Die Scores sind in Bänder eingeteilt: 0–49 schlecht, 50–89 verbesserungswürdig, 90–100 gut. Von 92 auf 98 merkt weder Nutzer noch Crawler etwas. Von 38 auf 72 verändert alles.
Startseiten sind meist die am besten optimierte Seite einer Website. Testen Sie stattdessen eine Produktseite oder einen langen Artikel — dort stecken die Hero-Bilder ohne Größenangabe und das vierte Analytics-Skript.
Lassen Sie die Seite mit Lighthouse im Mobil-Profil laufen und lesen Sie den Performance-Score zusammen mit den Messwerten darunter. Genau das macht der Test oben: Er schickt Ihre URL an die PageSpeed-Insights-Engine von Google und öffnet den vollständigen Lighthouse-Bericht auf dieser Seite – dieselbe Engine, die auch die Chrome DevTools nutzen.
Vier Werkzeuge decken fast jede praktische Frage ab, und sie messen unterschiedliche Dinge:
| Werkzeug | Was es misst | Wofür Sie es nutzen |
|---|---|---|
| Dieser Speed-Test | Ein Lighthouse-Laborlauf, mobil oder Desktop | Eine einzelne Seite diagnostizieren |
| PageSpeed Insights | Derselbe Laborlauf plus 28 Tage Chrome-Felddaten | Sehen, was echte Besucher erlebt haben |
| Core-Web-Vitals-Bericht der Search Console | Felddaten, gruppiert nach URL-Mustern | Probleme auf der ganzen Website finden |
| Performance-Panel der Chrome DevTools | Ein vollständiger Trace auf Ihrem Rechner | Eine einzelne langsame Interaktion debuggen |
Die Gewohnheit, die Sie ablegen sollten: einen einzelnen Lighthouse-Score als Urteil zu lesen. Er ist ein simulierter Seitenaufruf. Die anderen drei Werkzeuge zeigen, ob dieser Aufruf dem entspricht, was Ihre Besucher tatsächlich erleben.
Langsamer, als die meisten Speed-Ratgeber nahelegen. Am 1. Oktober 2026 haben wir mobiles Lighthouse (Version 13.5, simulierte Drosselung, die Konfiguration dieses Tests) auf 115 Ergebnisse der ersten Seite für 15 kommerzielle US-Keywords angewendet, von CRM-Software bis Saugroboter. Der Median des Performance-Scores lag bei 45. Nur 7,8 % erreichten 90 oder mehr, 59,1 % lagen unter 50 – dem Bereich, den Lighthouse als schlecht einstuft.
| Mobiler Lighthouse-Score | Anteil der 115 Ergebnisse von Seite 1 |
|---|---|
| 90–100 (gut) | 7,8 % |
| 50–89 (verbesserungswürdig) | 33,0 % |
| 0–49 (schlecht) | 59,1 % |
Die Labor-Werte für den Largest Contentful Paint waren ebenso ernüchternd: ein Median von 10,0 Sekunden, und nur 8,7 % der Seiten zeigten ihren Hauptinhalt innerhalb von 2,5 Sekunden. Lesen Sie das mit dem Vorbehalt, der dazugehört: Es sind Laborläufe von einem Rechner, jeweils zwei parallel, unter Lighthouses simuliertem langsamem Mobilprofil. Absolute Zeiten fallen daher höher aus als auf einer schnellen Verbindung.
Wir haben die Methode an Googles eigenen Zahlen geprüft. Unsere Startseite erreichte auf dieselbe Weise 67 Punkte bei einem LCP von 7,8 Sekunden; PageSpeed Insights gab ihr am selben Morgen 63 Punkte und 8,1 Sekunden. Der Aufbau folgt Googles Bewertung also eng. Er schmeichelt nur niemandem, uns eingeschlossen.
Ja, als ein Signal unter vielen, und unsere Daten zeigen, wie klein es neben der Relevanz ist. Google schreibt ausdrücklich: „Core Web Vitals are used by our ranking systems“ – und im selben Dokument: „Google Search always seeks to show the most relevant content, even if the page experience is sub-par“ (Google Search Central).
Unsere Prüfung vom 1. Oktober passt dazu. Über die 115 Ergebnisse hinweg hingen Position und Lighthouse-Score nicht zusammen (Spearmans ρ = 0,04, statistisch nicht signifikant). Ergebnisse auf den Plätzen 1–3 hatten einen Median von 44, auf den Plätzen 8–10 von 43. Das Ergebnis auf Platz 1 war nur bei einem von 14 Keywords die schnellste Seite seiner Ergebnisseite – seltener, als der Zufall erwarten ließe.
Erwarten Sie also keinen Ranking-Sprung, wenn aus 70 Punkten 95 werden. Der größere Gewinn liegt beim Besucher. Vodafone testete in einem A/B-Test eine Landingpage, deren LCP im Feld 31 % besser war, und erzielte 8 % mehr Verkäufe (web.dev-Fallstudie). Geschwindigkeit zahlt sich zuerst bei den Conversions aus und erst mit großem Abstand beim Ranking – und der Ranking-Effekt zeigt sich vor allem, wenn eine Seite sehr langsam ist, nicht wenn sie bloß durchschnittlich ist. Die ausführliche Fassung dieses Arguments lesen Sie unter wie sich die Ladezeit auf SEO auswirkt.
Jede Kategorie wird mit 0–100 bewertet, und die Bereiche sind bei allen vier gleich: 0–49 ist schlecht, 50–89 verbesserungswürdig, 90–100 gut.
Performance ist eine gewichtete Mischung aus fünf Labor-Messwerten. Seit Lighthouse 10 sind die Gewichte fest (Chrome for Developers):
| Messwert | Was er erfasst | Gewicht |
|---|---|---|
| Total Blocking Time | Wie lange der Main-Thread zu beschäftigt war, um zu reagieren | 30 % |
| Largest Contentful Paint | Wann der Hauptinhalt erschien | 25 % |
| Cumulative Layout Shift | Wie stark das Layout gesprungen ist | 25 % |
| First Contentful Paint | Wann überhaupt etwas erschien | 10 % |
| Speed Index | Wie schnell sich die sichtbare Seite füllte | 10 % |
Daraus folgt zweierlei. TBT und LCP tragen zusammen 55 % des Scores – dort liegen die Punkte. Und eine Seite kann schnell rendern und trotzdem schlecht abschneiden, wenn schweres JavaScript den Main-Thread danach blockiert.
Barrierefreiheit, Best Practices und SEO sind Checklisten statt Zeitmessungen. Die SEO-Kategorie prüft Grundlagen, die ein Crawler braucht – etwa einen Title, eine Meta-Description, einen crawlbaren Statuscode und lesbare Links. Eine 100 dort bedeutet, dass auf dieser Ebene nichts kaputt ist. Über das Ranking der Seite sagt sie nichts.
Für Google zählen die Felddaten; die Labordaten zeigen Ihnen, warum. Google bewertet die Core Web Vitals anhand echter Besuche, und web.dev formuliert die Messlatte klar: „a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices“ (web.dev).
Googles Schwellenwerte sind ein LCP innerhalb von 2,5 Sekunden, eine Interaction to Next Paint unter 200 Millisekunden und ein Cumulative Layout Shift unter 0,1. Dieser Test ist ein Laborlauf und meldet LCP und CLS daher direkt. INP braucht einen echten Menschen, der klickt und tippt – das kann ein Laborlauf nicht. Die Total Blocking Time ist der nächstliegende Ersatzwert: Ist TBT hier hoch, sollten Sie INP im Feld prüfen.
Widersprechen sich beide, vertrauen Sie dem Feld. Ein Laborlauf auf einer schnellen Seite kann ein langsames Drittanbieter-Skript übersehen, das nur bei manchen Besuchern lädt, und ein langsamer Laborlauf kann eine Seite schlechter darstellen, deren echtes Publikum schnelle Verbindungen hat. Felddaten erscheinen in PageSpeed Insights und der Search Console erst, wenn eine Seite oder Website genug Chrome-Traffic hat. Bei einer ruhigeren Seite ist der Laborlauf der Beleg, den Sie haben.
Weil ein großer Teil der Schwankung nicht vom Test stammt. Googles eigene Dokumentation sagt: „a lot of the variability in your overall Performance score and metric values is not due to Lighthouse“ – Netzwerk-Routing, Serverlast, A/B-Tests, wechselnde Werbung und Drittanbieter-Skripte ändern sich von Lauf zu Lauf.
Wir haben es an unserer eigenen Startseite gesehen: 63 Punkte in PageSpeed Insights und 67 in unserem eigenen Lauf, dieselbe Seite, derselbe Morgen. Eine Differenz von vier Punkten ist normal.
Drei Gewohnheiten machen die Zahl brauchbar:
Beheben Sie zuerst, was das größte Element verzögert – dort gehen sowohl der Score als auch die Geduld der Besucher verloren. Arbeiten Sie diese Reihenfolge ab:
fetchpriority="high", und 16,3 % luden ausgerechnet das Bild lazy, das über ihren LCP entschied. Unser Leitfaden zum Largest Contentful Paint behandelt die Korrekturen Element für Element.Für unsere eigenen Seiten gilt dieselbe Liste. Als wir seomator.com durch diesen Test geschickt haben, standen ganz oben im Bericht 253 KiB ungenutztes JavaScript und render-blockierende Anfragen mit geschätzten 150 ms Einsparung. Das sind die ersten beiden Punkte auf unserer eigenen Liste.
Fünf ehrliche Grenzen, damit Sie wissen, wann Sie zu etwas anderem greifen sollten.
Was Ihre Besucher tatsächlich erlebt haben. Das hier ist ein Laborlauf. Für Felddaten nutzen Sie PageSpeed Insights oder den Core-Web-Vitals-Bericht der Search Console. Fällt eine Seite dort immer wieder durch, hilft unser Leitfaden zu einer nicht bestandenen Core-Web-Vitals-Bewertung.
Alles hinter einem Login oder nach einer Interaktion. Der Test lädt eine öffentliche URL ein einziges Mal. Checkout-Schritte, Dashboards und Menüs, die sich per Klick öffnen, erreicht er nicht.
Interaction to Next Paint. Dafür braucht es echte Eingaben. Die Total Blocking Time ist ein Ersatzwert, keine Messung.
Die Ladezeit aus einem bestimmten Land. Der Lauf findet auf Googles Infrastruktur statt, und den Standort können Sie nicht wählen.
Den Rest Ihrer Website. Eine URL ist eine URL. Ein vollständiges Site-Audit prüft jede Seite, und der Mobile-Friendly-Test zeigt, wie eine Seite auf dem Smartphone dargestellt wird.
Die Website eines Interessenten wirkt langsam, aber er will Belege statt Meinungen. Testen Sie die wichtigste Landingpage mobil vor seinen Augen und lassen Sie Googles eigenen Bericht argumentieren.
Testen Sie vor dem Release das geänderte Template und vergleichen Sie es mit der aktuellen Live-Seite. Eine Verschlechterung jetzt zu finden kostet Minuten, später Wochen.
Ihr bester Artikel verliert Positionen. Prüfen Sie erst, ob die Seite schlicht schwerer geworden ist — ein neues Embed, ein Hero-Bild ohne Größenangabe — bevor Sie funktionierenden Text neu schreiben.
Der Bericht ist die echte Lighthouse-Ausgabe aus Googles PageSpeed Insights, dargestellt im offiziellen Viewer — dieselbe Bewertung wie in den Chrome DevTools.
Der vollständige Bericht öffnet sich direkt auf der Seite. Wir halten Ihren Wert nicht gegen eine E-Mail-Adresse zurück.
Jede Prüfung, jede Diagnose, jede Optimierung steht zum Nachlesen da — statt drei ausgewählter Metriken und eines Upsells.
Mobil und Desktop sind getrennte Läufe, denn ein Desktop-Wert sagt fast nichts über den Traffic aus, den Google tatsächlich indexiert.
Die Zahlen zur ersten Ergebnisseite auf dieser Seite stammen aus unseren eigenen Lighthouse-Läufen über 115 rankende Ergebnisse (1. Oktober 2026), datiert und wiederholbar – kein geliehener Branchendurchschnitt. Dasselbe Team baut SEOmators Site-Audit.
Eines von 29 kostenlosen SEO-Tools, vom kompletten Site-Audit bis zum Mobile-Friendly-Test.
Die Ladezeit ist eines der ersten Dinge, die Besucher beurteilen — meist bevor sie ein Wort gelesen haben. Und hier fallen die meisten Seiten durch: Als wir am 1. Oktober 2026 115 Ergebnisse von Googles erster Seite durch mobiles Lighthouse geschickt haben, lagen 59,1 % unter 50 Punkten, und nur 8,7 % zeigten ihren Hauptinhalt innerhalb von 2,5 Sekunden.
Die Website-Geschwindigkeit ist ein Ranking-Faktor in Googles Suchalgorithmus, daher rankt eine schnellere Website mit höherer Wahrscheinlichkeit weiter oben in den Suchergebnissen. Zudem kann eine langsam ladende Website zu höheren Absprungraten und geringerem Engagement führen, was sich negativ auf Ihr SEO auswirken kann.
Zu den häufigen Ursachen für eine langsame Website-Geschwindigkeit zählen große Bilddateien, schlechte Code- und Server-Optimierung sowie eine hohe Zahl an Anfragen an den Server.
Es gibt mehrere Tools zum Testen der Geschwindigkeit Ihrer Website, darunter Google PageSpeed Insights, GTmetrix und WebPageTest. Diese Tools liefern Ihnen verschiedene Performance-Metriken, etwa Ladezeit, Time to First Byte und die Anzahl der an den Server gestellten Anfragen.
Es gibt mehrere Möglichkeiten, die Geschwindigkeit Ihrer Website zu verbessern, darunter das Optimieren von Bildern und anderen Elementen, das Reduzieren der Anzahl der an den Server gestellten Anfragen und das Einrichten von Browser-Caching. Außerdem können Sie die Geschwindigkeit Ihrer Website verbessern, indem Sie Ihren Code und Server optimieren und ein Content Delivery Network (CDN) nutzen.
Core Web Vitals sind eine Reihe von Metriken, die die Nutzererfahrung einer Website messen — konkret Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität. Sie gelten als wichtige Indikatoren für die Gesamt-Performance einer Website. Google kündigte im Mai 2021 an, Core Web Vitals als Ranking-Signal zu verwenden; der Metriksatz hat sich seitdem geändert: Interaction to Next Paint löste im März 2024 First Input Delay ab.
Die praktische Antwort sind Googles Core-Web-Vitals-Schwellenwerte: Largest Contentful Paint unter 2,5 Sekunden, Interaction to Next Paint unter 200 Millisekunden und Cumulative Layout Shift unter 0,1 — jeweils gemessen am 75. Perzentil echter Seitenaufrufe. Wer alle drei erreicht, liegt im Bereich "gut". Die Hürde ist höher, als sie klingt: In unserem Labortest vom 1. Oktober 2026 zeigten nur 8,7 % von 115 Ergebnissen der ersten Google-Seite ihren Hauptinhalt mobil innerhalb von 2,5 Sekunden.
Lighthouse teilt seine Werte von 0 bis 100 in drei Bänder: 0–49 schlecht (rot), 50–89 verbesserungswürdig (orange) und 90–100 gut (grün). Ziel sind 90 und mehr, aber das Band zählt weit mehr als die exakte Zahl — der Sprung von 38 auf 72 ist für Nutzer spürbar, der von 92 auf 98 kaum. Da das Audit Netzwerk- und CPU-Bedingungen simuliert, schwanken die Werte zwischen zwei Läufen derselben URL um einige Punkte; vergleichen Sie deshalb Bänder statt Nachkommastellen.
Der Speed Index misst, wie schnell sich der sichtbare Teil der Seite beim Laden füllt. Lighthouse wertet ihn mobil bei 0–3,4 Sekunden grün und auf dem Desktop bei 0–1,3 Sekunden; über 5,8 Sekunden mobil oder 2,3 Sekunden auf dem Desktop wird er rot. Er trägt 10 % zum Performance-Score bei – ein schwacher Speed Index lohnt also die Korrektur, ist aber selten der Hauptgrund für einen niedrigen Score.
Largest Contentful Paint misst, wie lange das größte sichtbare Element zum Rendern braucht — also die Ladegeschwindigkeit. Interaction to Next Paint misst, wie schnell die Seite über den gesamten Besuch hinweg auf Taps und Klicks reagiert — die Reaktionsfähigkeit; die Metrik löste im März 2024 First Input Delay als Core Web Vital ab. Cumulative Layout Shift misst, wie stark Inhalte während des Ladens verspringen — die visuelle Stabilität. INP lässt sich nur an echten Besuchern messen, daher weist ein Labortest wie dieser die Total Blocking Time als nächstliegenden Ersatzwert aus.
Labordaten. Jeder Lauf ist ein einzelner simulierter Seitenaufruf von Googles Infrastruktur — ein gedrosseltes Mittelklasse-Smartphone im Mobil-Modus, eine schnelle Kabelverbindung im Desktop-Modus. Genau das macht die Ergebnisse wiederholbar und zwei Versionen einer Seite vergleichbar. Es ist aber nicht das, was Ihre Besucher erlebt haben. Dafür brauchen Sie Felddaten: den Core-Web-Vitals-Bericht in der Google Search Console oder den Chrome User Experience Report, beide aus echten Chrome-Besuchen der letzten 28 Tage. Nutzen Sie den Laborbericht zum Finden und Beheben, die Felddaten zur Bestätigung.
Vertiefende Beiträge aus dem SEOmator-Blog zu dem, was dieses Tool misst.
Die Seitenladegeschwindigkeit beeinflusst direkt SEO-Rankings und Nutzerengagement. Erfahren Sie, wie Core Web Vitals (LCP, INP, CLS) Ihre Suchsichtbarkeit beeinflussen, warum 53% der mobilen Besucher langsame Seiten verlassen und bewährte Optimierungsstrategien.
Die mediane Latenz unter Last liegt bei 257 ms — das INP-Budget bei 200 ms. Bevor Ihr JavaScript eine einzige Zeile ausführt, hat das Netzwerk die gesamte Zeit bereits verbraucht. Die Zahlen, die Ihre Core Web Vitals wirklich entscheiden.
Largest Contentful Paint (LCP) mit frischen Daten: Von 115 Google-Ergebnissen auf Seite 1 schafften im Oktober 2026 nur 8,7 % 2,5 s. Das sollten Sie beheben.
Verbessern Sie Ihre Online-Präsenz mit unserem Tool: Werden Sie gefunden, kommen Sie voran
