Sprachen

Speed Index und SEO

Was der Speed Index misst, was ein guter Wert ist, warum es eine reine Labor-Metrik von Lighthouse ist und kein Core Web Vital oder Ranking-Faktor, und wie man ihn verbessert.

Erstveröffentlicht: 26. Juni 2026 · Zuletzt aktualisiert: 3. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Der Speed Index misst, wie schnell Inhalte während des Seitenladens visuell angezeigt werden – die durchschnittliche Zeit, zu der sichtbare Teile der Seite erscheinen, bewertet in Sekunden (niedriger ist besser). Er wird aus einem Video des Ladevorgangs berechnet, ist also eine reine Labor-Metrik: nicht in CrUX, PageSpeed Insights Felddaten oder Search Console. Er stammt aus WebPageTest (Pat Meenan) und Lighthouse berechnet ihn über das Open-Source-Modul Speedline. Er ist KEIN Core Web Vital und KEIN Ranking-Faktor – er ist eine von fünf Lighthouse-Leistungsmetriken, gewichtet mit 10 % in Lighthouse 10. Mobile Schwellenwerte: Gut ≤ 3,4 s, Verbesserungsbedarf ≤ 5,8 s, Schlecht > 5,8 s (Desktop Gut ≤ ~1,3 s). Er verbessert sich mit denselben Maßnahmen wie FCP und LCP: schnellere Serverantwort und weniger render-blockierende Ressourcen.

Evidence for this claim Lighthouse Speed Index estimates how quickly page contents are visually populated during a lab load. Scope: Lighthouse lab metric; results depend on test environment and viewport. Confidence: high · Verified: Chrome Developers: Speed Index Evidence for this claim Lighthouse documents Speed Index scoring and weighting, which can change between Lighthouse versions. Scope: Current Lighthouse scoring model, not a Google Search ranking factor. Confidence: high · Verified: Lighthouse: Performance scoring

TL;DR — Der Speed Index misst, wie schnell Inhalte während des Seitenladens visuell angezeigt werden – die durchschnittliche Zeit, zu der sichtbare Inhalte erscheinen, bewertet in Sekunden (niedriger ist besser). Er wird aus einem Video des Ladevorgangs berechnet, indem die Fläche über der visuellen Fortschrittskurve summiert wird, was ihn zu einer nur im Labor verwendeten Metrik macht (nicht in CrUX, PSI Felddaten oder Search Console). Er stammt aus WebPageTest (Pat Meenan); Lighthouse berechnet ihn über das Open-Source-Modul Speedline. Er ist keine Core Web Vital und kein Ranking-Faktor – er ist eine von fünf Lighthouse-Metriken, gewichtet mit 10 % in Lighthouse 10. Mobil: Gut ≤ 3,4 s, Verbesserungsbedarf ≤ 5,8 s, Schlecht > 5,8 s; Desktop gut ≤ ~1,3 s. Er kann nicht schneller als FCP sein, er ist viewportabhängig und verbessert sich mit denselben Korrekturen wie FCP/LCP.

Evidence for this claim Lighthouse Speed Index estimates how quickly page contents are visually populated during a lab load. Scope: Lighthouse lab metric; results depend on test environment and viewport. Confidence: high · Verified: Chrome Developers: Speed Index

Was der Speed Index tatsächlich misst

Die Definition von Google ist eine Zeile: “Speed Index measures how quickly content is visually displayed during page load.” Das Schlüsselwort ist visuell. Der Speed Index ist kein einzelner Zeitstempel wie First Contentful Paint und Largest Contentful Paint – er ist ein zusammengesetzter Score, der die durchschnittliche Zeit darstellt, zu der die sichtbaren Teile der Seite angezeigt werden. Niedriger ist besser, und er wird in Sekunden angegeben.

Das mentale Modell, das ich am klarsten finde: Zeichnen Sie ein Diagramm mit Zeit auf der X-Achse und “Prozentsatz der Seite visuell vollständig” auf der Y-Achse, das von 0 % auf 100 % ansteigt. Der Speed Index ist die Fläche über dieser Kurve. Je schneller die Kurve auf 100 % ansteigt, desto kleiner ist die Fläche, desto besser der Score. Eine Seite, die eine Weile leer ist, hinterlässt ein großes Rechteck leerer Fläche über der Linie; eine Seite, die schnell darstellt, hinterlässt fast keine.

Wie er berechnet wird

Lighthouse zeichnet ein Video des Seitenladens auf und berechnet den visuellen Fortschritt zwischen den Frames. Jedes Zeitintervall wird danach gewichtet, wie unvollständig die Seite in diesem Moment noch ist – ein vollständig leeres Frame zählt zu 100 %, ein größtenteils gerendertes Frame zählt nur wenig. Die ursprüngliche WebPageTest-Formel lautet:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

Ein durchgerechnetes Beispiel macht es konkret. DebugBear führt einen Ladevorgang wie folgt durch:

  • 0 % vollständig (0–253 ms) → 253,0 ms Beitrag
  • 43 % vollständig (253–403 ms) → 85,5 ms Beitrag
  • 98 % vollständig (403–536 ms) → 2,7 ms Beitrag
  • 99 % vollständig (536–653 ms) → 1,2 ms Beitrag
  • Gesamt: 342,3 ms

Beachten Sie den ersten Abschnitt: Solange nichts sichtbar ist, trägt die gesamte Zeit in voller Höhe bei. Deshalb kann der Speed Index nie schneller sein als der First Contentful Paint – jede Millisekunde vor dem ersten sichtbaren Inhalt wird zu 100 % gezählt.

Lighthouse verwendet hier keine eigene Implementierung. Es führt das Open-Source- Modul Speedline aus (ursprünglich von Paul Irish), das dieselbe Methodik des visuellen Fortschritts aus Videos anwendet wie WebPageTest und mit Chrome-DevTools- Traces mit aktivierten Screenshots arbeitet. Speedline kann einen standardmäßigen Speed Index (Histogrammdifferenz zwischen aktuellem und finalem Frame) oder eine perzeptuelle Variante mittels SSIM berechnen; die Standardvariante ist die, die Sie normalerweise sehen.

Was ist ein guter Wert

Lighthouse 10 bewertet den Speed Index anhand von Daten realer Websites aus dem HTTP Archive, und die Schwellenwerte unterscheiden sich deutlich je nach Gerät, da Lighthouse standardmäßig ein mittelklassiges mobiles Gerät mit Drosselung simuliert:

Speed IndexMobilDesktop
Gut (grün)0 – 3,4 s0 – 1,3 s
Verbesserung nötig (orange)3,4 – 5,8 s1,3 – 2,3 s
Schlecht (rot)> 5,8 s> 2,3 s

Falls Sie den alten Richtwert „unter 1,000 ms ist gut“ gesehen haben, handelt es sich dabei um veraltete WebPageTest-Empfehlungen für eine bestimmte Ära und ein bestimmtes Verbindungsprofil – nicht um die aktuelle mobile Lighthouse-Messlatte. Wissen Sie immer, welches Tool und welche Geräte-/Netzwerkeinstellungen den Wert erzeugt haben, den Sie betrachten, denn dieselbe Seite schneidet unterschiedlich ab in Lighthouse, WebPageTest und GTmetrix.

Wo es im Lighthouse-Score steht

Der Speed Index ist eine von fünf Metriken im Lighthouse-10-Performance-Score und ist mit 10 % gewichtet – gleichauf mit FCP für das niedrigste Gewicht:

MetrikLighthouse-10-Gewicht
First Contentful Paint10 %
Speed Index10 %
Largest Contentful Paint25 %
Cumulative Layout Shift25 %
Total Blocking Time30 %

Die praktische Schlussfolgerung: Den Speed Index isoliert zu optimieren, bringt wenig. Total Blocking Time (30 %) sowie LCP und CLS (je 25 %) bewegen den Gesamtscore deutlich stärker. Es sei denn, der Speed Index ist das spezifische Problem – in der Regel erzielen Sie mehr, indem Sie LCP und TBT beheben, und der Speed Index verbessert sich ohnehin als Nebeneffekt. In PageSpeed Insights finden Sie den Speed Index im Lab-Abschnitt (Lighthouse), nicht im Felddaten-Abschnitt oben.

Ist der Speed Index eine Core Web Vital oder ein Ranking-Faktor?

Nein auf beide Fragen, und der Unterschied ist wichtig, wenn Sie einen Bericht gegenüber einem Stakeholder erklären.

  • Er ist keine Core Web Vital. Die Core Web Vitals sind LCP, INP und CLS, gemessen an echten Nutzern über CrUX. Der Speed Index gehört nicht zu dieser Gruppe und erscheint nicht im Core-Web-Vitals-Bericht der Google Search Console.
  • Er ist kein direkter Ranking-Faktor. Das Page-Experience-Signal von Google verwendet Felddaten der Core Web Vitals. Der Speed Index ist eine reine Labordiagnose, die Google nicht von echten Nutzern erhebt, daher gibt es keinen direkten Weg von Ihrem Speed-Index-Wert zu Rankings.

Die Beziehung zu Rankings ist indirekt: Die Probleme, die zu einem schlechten Speed Index führen – langsames TTFB, renderblockierendes CSS/JS, unsichtbarer Text während des Fontwechsels – sind dieselben, die zu einem schlechten FCP und LCP führen. Beheben Sie sie, und ein besserer Speed Index geht in der Regel mit einem besseren LCP einher, was der Teil ist, den Google tatsächlich belohnt.

Warum es nur im Labor verfügbar ist

Der Speed Index benötigt ein Frame-für-Frame-Video des Seiten-Renderings und anschließend Bildverarbeitung, um die visuelle Vollständigkeit jedes Frames zu berechnen. Das ist viel zu teuer, um es bei jedem echten Besucher auszuführen, daher existiert er nur in synthetischen/Lab-Tools – Lighthouse, WebPageTest, GTmetrix. Real User Monitoring und der CrUX-Datensatz enthalten ihn schlicht nicht. Wenn Sie Feld-Leistungsdaten benötigen, verwenden Sie Core Web Vitals; der Speed Index dient der Diagnose des Renderings in einem kontrollierten Test.

Woher er stammt

Der Speed Index entstand in WebPageTest, das Pat Meenan 2008 erstellte und als Open Source veröffentlichte (die Metrik selbst wurde um 2012 hinzugefügt). Er wurde entwickelt, um eine echte Lücke in den damaligen Metriken zu schließen:

  • Render-Start konnte bei einem einzelnen Pixel oder einer Hintergrundfarbe auslösen – nicht bei bedeutungsvollem Inhalt.
  • Document complete (onload) umfasst Inhalte unterhalb des Falzes und irrelevante Ressourcen.

Der Speed Index überbrückte den Unterschied, indem er die visuelle Vollständigkeit oberhalb des Falzes im Zeitverlauf misst – ein besserer Proxy für das, was ein Benutzer tatsächlich wahrnimmt. Lighthouse übernahm diese Methodik später über das Speedline-Modul, weshalb die WebPageTest- und Lighthouse-Zahlen eine gemeinsame Abstammung haben, auch wenn sich ihre Drosselung unterscheidet.

So verbessern Sie ihn

Es gibt keinen spezifischen Speed-Index-Trick – Googles eigene Anleitung besagt, dass alles, was Sie tun, um die Seitenladegeschwindigkeit zu verbessern, auch Ihren Speed-Index-Score verbessert. In der Praxis:

  • Serverantwortzeit (TTFB) reduzieren. Jede Millisekunde vor dem ersten Byte ist Leerseitenzeit, die voll gewichtet wird.
  • Render-blockierendes CSS und JavaScript eliminieren. Diese verzögern den ersten Paint, der der teuerste Teil der Kurve ist. Kritisches CSS inline einbetten, den Rest aufschieben.
  • Schriftladen beheben. Während eines Font-Swaps kann Text unsichtbar sein – was für diesen Zeitraum als 0 % vollständig zählt. font-display: swap (oder optional) hält Text sichtbar. Dies ist einer der Audits, die Lighthouse explizit für den Speed Index kennzeichnet.
  • Main-Thread-Arbeit minimieren und JavaScript-Ausführungszeit reduzieren – die anderen beiden Diagnosen, die Lighthouse als besonders wirkungsvoll für den Speed Index nennt.
  • Inhalte oberhalb des Falzes priorisieren. Der Speed Index kümmert sich nur um den sichtbaren Viewport, daher ist es das ganze Spiel, den ersten Bildschirm schnell zu malen.

Diese überschneiden sich fast vollständig mit der FCP- und LCP-Optimierung – genau deshalb behandle ich den Speed Index als bestätigendes Signal und nicht als separate To-do-Liste. Bevor Sie auf eine einzelne Zahl reagieren, schauen Sie sich das Lade-Filmstrip an (Lighthouse und WebPageTest generieren beide eines), um zu bestätigen, was tatsächlich früh versus spät gemalt wird, und vergleichen Sie mehrere wiederholte, gleichartige Läufe statt eines einzelnen Tests – siehe Hinweis zur Lauf-zu-Lauf-Variabilität unten.

Einschränkungen, die Sie kennen sollten

  • Nur im Labor – es spiegelt nie die Erfahrung eines echten Nutzers wider, sondern nur die der Testumgebung.
  • Abhängig vom Viewport – es misst den sichtbaren Bereich, daher liefern Mobilgeräte und Desktop sehr unterschiedliche Ergebnisse (daher auch die sehr unterschiedlichen Schwellenwerte).
  • Blinder Fleck bei SPA/AJAX – Single-Page-Apps können künstlich schnell wirken: Die Hülle rendert schnell, während der eigentliche Inhalt später ohne Seitenaktualisierung nachgeladen wird.
  • Karussells, Autoplay-Videos und Consent-Overlays – alles, was nach dem Laden des eigentlichen Inhalts weiterhin Pixel verändert, kann dafür bestraft werden, dass es weiterhin als „unvollständig“ registriert wird – derselbe Mechanismus, der auch automatisch rotierende Karussells bestraft.
  • Keine Metrik für „vollständig geladen“ – es misst den visuellen Fortschritt oberhalb der Falz, nicht wann jedes Skript, Bild oder Element unterhalb der Falz fertig geladen ist. Die separate Metrik Visually Complete von WebPageTest (immer ≥ Speed Index) ist diejenige, die ein spät nachgeladenes Lazy-Loaded-Widget erfasst.
  • Visueller Fortschritt ist kein Beweis für Nutzbarkeit. Der Speed Index misst nur Pixelveränderungen gegenüber einem Endframe – er weiß nicht, ob das, was auf dem Bildschirm ist, lesbar, korrekt angeordnet, barrierefrei oder tatsächlich interaktiv ist. Ein schnell rendendes Skelett oder eine Hülle kann gut abschneiden, während der eigentliche Inhalt (und die Möglichkeit, ihn zu nutzen) später kommt; das ist derselbe Fehlermodus wie das oben beschriebene Anti-Pattern „bedeutungsloses frühes Rendering“, nur aus der Perspektive der Metrik beschrieben.
  • Variabilität zwischen Läufen. Da der Speed Index aus einem einzelnen aufgezeichneten Ladevorgang abgeleitet wird, schwankt er mit den Testbedingungen – Googles eigene Bewertungsrichtlinien nennen Geräteunterschiede, Browsererweiterungen, Antivirensoftware und sogar Änderungen durch Werbung oder A/B-Tests als Quellen für Score-Schwankungen, die nichts mit Ihrem Code zu tun haben. Vergleichen Sie Verteilungen aus wiederholten, gleichartigen Läufen, nicht einzelne Zahlen.

Verwandte Metriken

Der Speed Index gehört zum selben Web-Performance-Cluster wie der Core Web Vitals-Hub und seine Nachbarn. Er steht First Contentful Paint am nächsten (der Speed Index kann FCP nicht unterbieten) und Largest Contentful Paint (gleiche Fixes, gleiche Ursachen), liegt im Lighthouse-Score neben Total Blocking Time, und Sie begegnen ihm in Lighthouse und PageSpeed Insights. Für die Feldmetriken, die tatsächlich Rankings beeinflussen, starten Sie im Core Web Vitals-Hub.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.