Speed Index

Der Speed Index gibt an, wie schnell sich der sichtbare Bereich einer Seite während des Ladens mit Inhalt füllt. Er bewertet also keinen einzelnen Zeitpunkt, sondern den gesamten Bildaufbau, so wie ihn Besucher auf dem Bildschirm erleben. Dieser Leitfaden erklärt, wie der Wert zustande kommt, welche Grenzwerte Lighthouse ansetzt und mit welchen Maßnahmen Sie den Speed Index senken.

Aus den Messungen von PerfDelta: Im mobilen Labortest erreichen 5 % von 4.097 Startseiten bei Speed Index einen guten Wert, 77 % liegen im schlechten Bereich. Der Median liegt bei 8631 ms, die mittlere Hälfte zwischen 6014 ms und 12316 ms. Mehr dazu im Datenblock unten.

Speed Index misst den visuellen Fortschritt im Viewport

Lighthouse zeichnet während des Tests eine Bildfolge des Ladevorgangs auf, einen sogenannten Filmstreifen aus Screenshots des Viewports. Jedes Einzelbild wird mit dem Endzustand der Seite verglichen. Daraus ergibt sich, zu wie viel Prozent der sichtbare Bereich zu diesem Zeitpunkt fertig aussieht. Trägt man diesen Anteil über die Zeit auf, entsteht eine Kurve des visuellen Fortschritts. Der Speed Index entspricht der Fläche oberhalb dieser Kurve. Je länger der Bildschirm unvollständig bleibt und je größer der unfertige Anteil ist, desto höher fällt der Wert aus. Angegeben wird er in Sekunden, und ein niedriger Wert ist besser.

Rechenbeispiel mit zwei gleich schnellen Seiten

Zwei Seiten sind nach vier Sekunden vollständig geladen. Trotzdem unterscheidet sich ihr Speed Index deutlich:

• Seite A bleibt vier Sekunden lang weiß und zeigt dann alles auf einmal. Sie ist vier Sekunden lang zu 0 % fertig, der Speed Index liegt bei 4,0 s.
• Seite B zeigt nach einer Sekunde Navigation, Überschrift und Text, der Viewport ist damit zu 60 % fertig. Nach zwei Sekunden folgt ein Teaserbild (90 %), nach vier Sekunden ein Logo-Band im unteren Bereich (100 %). Die Rechnung lautet 1 × 1 + 1 × 0,4 + 2 × 0,1 = 1,6 s.

Die Gesamtladezeit ist identisch, der Eindruck für Besucher aber völlig verschieden. Genau diesen Unterschied bildet der Speed Index ab. Er belohnt Seiten, die den oberen Bildschirmbereich früh weitgehend füllen, auch wenn einzelne Details später nachkommen.

Gute Speed-Index-Werte in Lighthouse

Lighthouse bewertet mobile und Desktop-Tests mit unterschiedlichen Schwellen. Der mobile Test simuliert eine gedrosselte Verbindung und eine langsamere CPU, deshalb liegen die Grenzen dort höher:

Testprofil	Gut	Verbesserungswürdig	Schlecht
Mobil	bis 3,4 s	3,4 bis 5,8 s	über 5,8 s
Desktop	bis 1,3 s	1,3 bis 2,3 s	über 2,3 s

Gewichtung im Lighthouse-Score: 10 %

Im Performance-Score von Lighthouse zählt der Speed Index 10 %, genauso viel wie First Contentful Paint. Largest Contentful Paint und Cumulative Layout Shift gehen mit je 25 % ein, Total Blocking Time mit 30 %. Ein schlechter Speed Index drückt den Score also spürbar, entscheidet ihn aber selten allein. Sein eigentlicher Nutzen liegt in der Diagnose des Bildaufbaus.

Speed Index ist eine reine Laborkennzahl

Für den Speed Index gibt es keine Felddaten. Der Chrome UX Report erfasst ihn nicht, weil echte Browser keinen Filmstreifen jedes Seitenaufrufs aufzeichnen. In PageSpeed Insights finden Sie den Wert deshalb nur im Lighthouse-Abschnitt, nie im Block mit den Nutzerdaten. Zu den Core Web Vitals gehört er nicht und fließt damit auch nicht direkt in Googles Bewertung der Seitenerfahrung ein.

Zusammenhang mit FCP und LCP

Die drei Ladekennzahlen beschreiben verschiedene Punkte derselben Fortschrittskurve. Der First Contentful Paint markiert den Moment, in dem die Kurve zu steigen beginnt. Bis dahin ist der Viewport zu 0 % fertig, ein später FCP treibt den Speed Index also unmittelbar nach oben. Der Largest Contentful Paint zeigt, wann das größte Element erscheint. Ist das ein Hero-Bild, das die halbe Bildschirmfläche einnimmt, bleibt bis zu seinem Eintreffen ein großer Teil unvollständig.

Maßnahmen für FCP und LCP senken deshalb in aller Regel auch den Speed Index. Bleibt er trotz guter FCP- und LCP-Werte hoch, verändert sich der sichtbare Bereich meist noch lange, nachdem der Hauptinhalt bereits da ist.

Ursachen eines hohen Speed Index

• Renderblockierendes CSS und JavaScript. Stylesheets und synchrone Skripte im Kopf verhindern, dass der Browser überhaupt etwas zeichnet.
• Spät geladene Webschriften. Bleibt Text unsichtbar, bis die Schriftdatei eintrifft, gelten große Textflächen als unfertig, obwohl das HTML längst vorliegt.
• Große Hero-Bilder. Ein schweres Bild, das viel Fläche belegt und spät lädt, hält diesen Bereich leer.
• Clientseitiges Rendering. Enthält das HTML nur einen leeren Container, erscheint Inhalt erst, wenn das JavaScript-Bundle geladen und ausgeführt ist.
• Animationen und Slider. Wechselnde Slides, Einblendeffekte und animierte Banner verändern den Viewport laufend. Da jedes Bild mit dem Endzustand verglichen wird, gilt ein bewegter Bildschirm nie als fertig.
• Ladeanimationen. Ein Spinner erscheint zwar früh, ähnelt der fertigen Seite aber kaum und bringt daher wenig visuellen Fortschritt.

Speed Index senken

Kritischen Renderpfad freiräumen

Das CSS für den oberen Bildschirmbereich gehört inline in den Kopf, der Rest lädt ohne Blockade nach. Skripte, die für die erste Darstellung nicht nötig sind, erhalten das Attribut defer. Die Vorgehensweise im Detail beschreibt der Leitfaden zu renderblockierenden Ressourcen.

<style>/* kritisches CSS für Kopfbereich und Hero */</style>
<link rel="preload" href="/css/main.css" as="style" onload="this.rel='stylesheet'">
<script src="/js/app.js" defer></script>

Inhalte im sichtbaren Bereich priorisieren

Was den ersten Bildschirm füllt, sollte der Browser zuerst anfordern. Das Hero-Bild bekommt eine hohe Abrufpriorität, wird nie verzögert geladen und passend zur Viewport-Breite ausgeliefert. Bilder weiter unten dürfen dagegen verzögert laden, damit sie keine Bandbreite abziehen.

<img src="/img/hero-1200.webp"
     srcset="/img/hero-800.webp 800w, /img/hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="600"
     fetchpriority="high" alt="Produktübersicht">

Text mit font-display sofort anzeigen

Mit font-display: swap erscheint Text zunächst in einer Ersatzschrift. Zusätzlich lohnt es sich, die ein oder zwei Schriften vorzuladen, die im oberen Bereich tatsächlich verwendet werden.

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
}

Inhalte serverseitig rendern

Liefert der Server fertiges HTML mit dem sichtbaren Inhalt aus, kann der Browser zeichnen, bevor JavaScript läuft. Die Interaktivität wird anschließend per Hydration ergänzt. Bei Single-Page-Anwendungen ist das oft der wirksamste Einzelschritt.

Animationen während des Ladens vermeiden

Slider starten am besten mit einem statischen ersten Bild und beginnen erst nach dem Laden zu wechseln. Einblendeffekte für den Hauptinhalt sollten entfallen, und ganzseitige Ladeanimationen ersetzen Sie durch den echten, serverseitig gerenderten Inhalt.

window.addEventListener('load', () => {
  setTimeout(() => slider.start(), 3000);
});

Hinweise für WordPress, Shopify und Next.js

In WordPress sind Slider-Plugins und Page-Builder mit Einblendanimationen häufige Bremsen. Ein statisches Hero-Element, deaktivierte Animationen im oberen Bereich und ein Performance-Plugin, das kritisches CSS erzeugt und Skripte verzögert, bringen hier die meiste Wirkung. Testen Sie danach Menüs und Formulare, weil zu aggressives Verzögern Funktionen stören kann.

Bei Shopify bremsen Slideshow-Sektionen auf der Startseite und von Apps eingefügte Skripte den Bildaufbau. Ein einzelnes Bildbanner statt einer automatisch wechselnden Slideshow hilft, ebenso das Entfernen nicht mehr genutzter Apps, deren Code oft im Theme verbleibt.

Eine rein clientseitig gerenderte React-Anwendung zeigt bis zur Ausführung des Bundles ein leeres Wurzelelement. Next.js rendert standardmäßig auf dem Server oder beim Build. Halten Sie Komponenten im sichtbaren Bereich aus rein clientseitigen Codepfaden heraus und nutzen Sie die Bildkomponente des Frameworks mit Priorität für das Hero-Bild.

Typische Fehler beim Speed Index

• Das Hero-Bild wird verzögert geladen und fehlt damit genau dort, wo der Speed Index am stärksten reagiert.
• Die gesamte Seite bleibt per Opacity-Übergang unsichtbar, bis das JavaScript fertig ist.
• Ein einzelner Testlauf wird als Maßstab genommen, obwohl Laborwerte zwischen Läufen schwanken.
• Nur die Startseite wird optimiert, während andere Vorlagen weiter mit Slidern oder clientseitigem Rendering arbeiten.

Speed Index prüfen mit Filmstreifen und PerfDelta

Im Lighthouse-Bericht von PageSpeed Insights zeigt der Filmstreifen unterhalb der Kennzahlen, ob der Bildschirm leer bleibt, sich schrittweise füllt oder ständig wechselt. Noch genauer wird es im Performance-Panel der Chrome DevTools mit aktivierten Screenshots, dort lässt sich der Aufbau Bild für Bild verfolgen. Vergleichen Sie nach jeder Änderung die Filmstreifen und nicht nur die Zahl.

PerfDelta testet mehrere Seiten Ihrer Website mobil und am Desktop und stellt Labor- und Felddaten nebeneinander. So sehen Sie, ob ein hoher Speed Index eine einzelne Seite oder ganze Vorlagen betrifft. Die Lighthouse-Empfehlungen erscheinen dort mit geschätzter Einsparung und den betroffenen Dateien, jeweils verlinkt mit dem passenden Leitfaden.

Häufige Fragen

Welcher Speed Index ist gut?

Lighthouse wertet mobil einen Speed Index bis 3,4 Sekunden als gut und über 5,8 Sekunden als schlecht. Am Desktop gelten bis 1,3 Sekunden als gut und über 2,3 Sekunden als schlecht.

Wie wird der Speed Index berechnet?

Lighthouse zeichnet einen Filmstreifen des Ladevorgangs auf und vergleicht jedes Bild mit dem Endzustand der Seite. Der Speed Index ist die Fläche oberhalb der daraus entstehenden Fortschrittskurve und wächst, je länger der Viewport unfertig bleibt.

Gehört der Speed Index zu den Core Web Vitals?

Nein. Der Speed Index ist eine Laborkennzahl und geht mit 10 % in den Lighthouse-Performance-Score ein. Im Chrome UX Report gibt es keine Felddaten dazu.

Warum ist der Speed Index hoch, obwohl FCP und LCP gut sind?

Meist verändert sich der sichtbare Bereich nach dem Erscheinen des Hauptinhalts weiter. Wechselnde Slider, Einblendeffekte und Ladeanimationen verhindern, dass der Bildschirm dem Endzustand entspricht.

Wie senke ich den Speed Index?

Renderblockierende Ressourcen aus dem kritischen Pfad entfernen, Inhalte im sichtbaren Bereich priorisieren, Webschriften mit font-display: swap einbinden, sichtbare Inhalte serverseitig rendern und Animationen während des Ladens vermeiden.

Warum schwankt der Speed Index zwischen zwei Tests?

Laborläufe hängen von Netzbedingungen, Serverantwort und Inhalten von Drittanbietern ab. Vergleichen Sie mehrere Läufe und prüfen Sie im Filmstreifen, ob sich der Bildaufbau tatsächlich verändert hat.