Wenn die Website zu langsam ist:
Drei Tempo-Kennzahlen, an denen Suchmaschinen heute messen

Wenn die Seite zäh wird — was Geschäftsführer zuerst spüren

Die ersten Symptome einer zu langsamen Website tauchen außerhalb der Daten auf. Anfragen über das Kontaktformular gehen leise zurück. Kunden im Telefonat erwähnen, dass „die Seite gestern komisch war". Mitarbeiter sagen, dass das eingebundene Verwaltungs-Tool seit Wochen länger lädt als früher. Niemand bringt das zusammen — bis irgendwann jemand einen Geschwindigkeitstest macht und sich wundert.

Hinter diesen Symptomen laufen zwei parallele Effekte. Der erste ist die direkte Nutzererfahrung: Wer auf einer mobilen Verbindung länger als drei Sekunden auf die Hauptaussage einer Seite wartet, ist statistisch oft schon weg, bevor das letzte Element geladen hat. Der zweite Effekt ist mittelbar: Wenn messbar viele Nutzer die Seite ohne Interaktion verlassen, gewichten Suchmaschinen die Seite langsam, aber spürbar herunter. Tempo wirkt also doppelt — direkt auf Conversion und indirekt auf Sichtbarkeit. Wer den Sichtbarkeits-Pfad vertiefen will, findet im Beitrag Sichtbarkeit eingebrochen — Diagnose und Recovery den vollständigen Diagnose-Pfad.

Die typischen Auslöser für die plötzliche Aufmerksamkeit

• Tempo-Bericht in der Search Console: Eine E-Mail-Benachrichtigung weist darauf hin, dass URLs in den Status „schlecht" oder „verbesserungsbedürftig" gerutscht sind.
• Erkennbarer Rückgang der mobilen Anfragen: Im Webanalyse-Tool zeigt sich, dass mobile Besucher die Anfrage-Strecke seltener abschließen — desktopseitig sieht es stabiler aus.
• Synthetischer Test durch einen externen Beobachter: Ein potenzieller Kunde, ein Bewerber oder ein neuer Mitarbeiter macht einen Geschwindigkeitstest und schickt das Ergebnis als Frage an die Geschäftsführung.

Warum Tempo seit 2021 messbar zum Ranking-Faktor wurde

Suchmaschinen-Algorithmen haben über lange Zeit Tempo als weichen Faktor geführt — vorhanden, aber schwer greifbar. Mit dem sogenannten Page-Experience-Update Mitte 2021 wurden drei konkrete Werte zum verbindlichen Teil der Bewertung gemacht. Im März 2024 wurde einer der drei ursprünglichen Werte (First Input Delay) durch einen aussagekräftigeren Wert (Interaction to Next Paint) ersetzt. Seitdem ist die Kombination aus LCP, INP und CLS der Standard, an dem sich Tempo-Qualität messen lässt.

Der entscheidende Punkt für die Praxis: Die Werte gelten nicht als pauschaler Page-Score, sondern werden pro URL und pro Gerätetyp gemessen. Eine Startseite, die desktopseitig schnell läuft, kann mobil dauerhaft im roten Bereich liegen — und in dem mobilen Profil gewichtet die Suchmaschine sie dann anders als in dem desktopseitigen. Da der Anteil mobiler Aufrufe in den meisten B2B-Geschäften zwischen 40 und 70 Prozent liegt, ist die mobile Bewertung praktisch immer die wichtigere.

Welche Geräte zählen — und welche nicht

Gemessen werden die tatsächlich gemessenen Aufrufe echter Nutzer aus einem anonymen Echtdaten-Bericht. Synthetische Tests aus dem Browser sind hilfreich für die Diagnose, fließen aber nicht in die Bewertung ein. Das bedeutet auch: Wenn die Werte synthetisch schlecht aussehen, der Echtdaten-Bericht aber gute Werte zeigt, ist die Lage ruhiger, als das Diagnose-Werkzeug nahelegt. Umgekehrt gilt das Gleiche.

Die drei Kennzahlen im Klartext

Jeder der drei Werte misst etwas Eigenes. Wer sie auseinanderhält, kann Maßnahmen gezielt setzen — wer sie als „eine Zahl" wahrnimmt, optimiert oft am falschen Ende.

LCP — wie schnell die Hauptaussage da ist

Largest Contentful Paint misst den Moment, in dem das größte sichtbare Inhalts-Element fertig gerendert ist. Typischerweise ist das ein Hero-Bild, ein Hero-Video oder eine große Überschrift. Solange dieses Element fehlt, sieht der Nutzer entweder Weiß oder einen Platzhalter — und die Seite wirkt unfertig, auch wenn alle anderen Teile schon da sind. Der Wert ist deshalb der beste Indikator für den gefühlten Tempo-Eindruck.

Ein guter LCP-Wert liegt unter 2,5 Sekunden, ab 4 Sekunden gilt der Wert als schlecht. Die häufigste Ursache für schlechte LCP-Werte sind zu große oder ungünstig eingebundene Hero-Bilder — gefolgt von blockierenden Skripten, die das Rendering verzögern, und langsamen Servern, die mit der ersten Antwort warten lassen.

INP — wie reaktiv die Seite ist

Interaction to Next Paint misst die Verzögerung zwischen einem Klick, Tastaturanschlag oder Touch und der nächsten sichtbaren Reaktion der Seite. Im Unterschied zum früheren Wert wird hier nicht nur der erste Klick, sondern jede Interaktion über den gesamten Besuch hinweg ausgewertet — die schlechteste Reaktionszeit gewinnt.

Gut: weniger als 200 Millisekunden. Mittel: bis 500 Millisekunden. Darüber wird die Seite spürbar träge. Der Wert leidet vor allem unter zu viel JavaScript, das den Browser im Moment der Interaktion beschäftigt — etwa weil ein Tag-Manager im Hintergrund Dutzende Tracking-Skripte ausführt oder weil das eigene Skript-Bundle nicht aufgeteilt ist.

CLS — wie ruhig das Layout bleibt

Cumulative Layout Shift misst, wie stark sich das Layout während des Ladens noch verschiebt. Jeder Sprung zählt: Bilder, die ohne reservierte Höhe nachladen und den darunter liegenden Text wegschieben. Web-Schriften, die das Schriftbild beim Erscheinen austauschen und Zeilenumbrüche verändern. Ein Cookie-Banner, der vom unteren Rand einfährt und das Layout darüber komprimiert. Jeder dieser Sprünge wird mit Gewicht versehen und summiert.

Gut: unter 0,1. Mittel: bis 0,25. Darüber leidet die Lesbarkeit deutlich, und Nutzer klicken oft auf das falsche Element, weil sich das richtige im Moment des Klicks verschoben hat. CLS ist die am häufigsten unterschätzte Kennzahl — sie fühlt sich wie ein optisches Detail an, ist aber direkt mit Frust und Fehlklicks verknüpft.

Wo Tempo verschwindet — sieben typische Quellen

In der Praxis kommen die meisten Tempo-Verluste aus einer überschaubaren Zahl wiederkehrender Quellen. Wer die kennt, hat in den meisten Fällen schon nach einer halben Stunde ein klares Bild, wo die Substanz zu optimieren ist.

Was sich messen lässt — die zwei Quellen, die nichts beschönigen

Bevor irgendeine Maßnahme sinnvoll ist, müssen Zahlen auf den Tisch — und zwar Echtdaten aus tatsächlichen Nutzungen, nicht nur synthetische Tests aus dem Browser eines einzigen Entwicklers.

Echtdaten aus dem Tempo-Bericht der Search Console

Die Search Console der Suchmaschine zeigt die echten gemessenen Werte aller Besucher, gruppiert nach URL-Typen und Gerätekategorien. Drei Status sind dokumentiert: „gut", „verbesserungsbedürftig", „schlecht". Wichtig ist die Aufschlüsselung: Welche URL-Gruppen sind betroffen, welche Werte sind das Problem, ist es ein Desktop- oder ein Mobil-Problem? Diese Aufschlüsselung ersetzt jede Hypothese, weil sie konkret zeigt, wo der Schmerz tatsächlich liegt.

Synthetische Diagnose aus dem Browser

Moderne Browser bringen ein eingebautes Diagnose-Werkzeug mit, das eine einzelne URL prüft und detaillierte Empfehlungen ausgibt: welche Bilder zu groß sind, welche Skripte das Rendering blockieren, welche Elemente die Layout-Sprünge verursachen. Das Ergebnis ist eine Momentaufnahme — sehr nützlich für die Suche nach Ursachen, weniger aussagekräftig für die Frage, wie der Wert im Schnitt der echten Nutzer aussieht. Sinnvoll ist die Kombination: Echtdaten zeigen, wo es weh tut; synthetische Diagnose zeigt, was konkret zu tun ist.

Real-User-Monitoring als optionale dritte Stufe

Wer Tempo dauerhaft im Blick behalten will, kann ein schlankes Real-User-Monitoring einbauen, das die drei Kennzahlen direkt aus dem Browser jedes Besuchers misst und in eine eigene Auswertung schreibt. Für kleinere Setups oft überdimensioniert; für Seiten mit umsatzkritischem Funnel eine sinnvolle Ergänzung.

Maßnahmen, die wirklich wirken — sortiert nach Aufwand und Wirkung

Tempo-Optimierung ist eine Frage der Reihenfolge: erst die Maßnahmen mit hoher Wirkung und geringem Aufwand, dann die mittleren, zuletzt die architektonischen Eingriffe. Wer umgekehrt vorgeht, investiert oft in Strukturen, die ohne die einfachen Korrekturen ohnehin nicht greifen.

Sofort-Maßnahmen mit geringem Aufwand

• Bilder neu generieren: Hero-Bilder und große Inhaltsbilder in moderne Formate konvertieren (WebP oder AVIF), passende Auflösungen für Desktop und Mobil bereitstellen, das Hero-Bild mit Preload-Hinweis ausstatten.
• Bild-Maße verbindlich setzen: Jedes Bild im Markup mit width- und height-Attribut oder per aspect-ratio-CSS festlegen — der Browser reserviert dann den Platz und vermeidet Layout-Sprünge beim Nachladen.
• Web-Schriften lokal hosten: Statt vom externen Dienst zu laden, die nötigen Schnitte als Datei mitliefern, mit Anzeige-Strategie „swap" und einer Fallback-Schrift, deren Maße der Web-Schrift nahekommen.
• Cookie-Banner stabilisieren: Banner mit fester Position einbauen, sodass er das darunter liegende Layout nicht verschiebt — oder den Platz darunter reservieren, falls der Banner inline erscheint.

Mittlere Maßnahmen — meist eine bis drei Personentage

• Tag-Manager-Bestand entrümpeln: Jedes ungenutzte Skript raus, jeden Tracker auf Notwendigkeit prüfen, schwere Drittanbieter durch leichtere Alternativen ersetzen. Wirkt direkt auf INP, oft mit deutlich messbarem Sprung.
• Critical CSS inline einbinden: Das CSS, das für die erste sichtbare Bildschirmfläche nötig ist, direkt in den HTML-Kopf schreiben, den Rest asynchron nachladen. Wirkt auf LCP.
• Kompression und Cache-Header serverseitig setzen: Brotli- oder Gzip-Kompression aktivieren, sinnvolle Cache-Anweisungen für statische Ressourcen vergeben. Wirkt auf LCP und auf alle Folgebesuche.
• HTTP/2 oder HTTP/3 prüfen: Wenn der Server noch HTTP/1.1 ausliefert, ist der Wechsel auf eine neuere Protokoll-Version eine niedrig-hängende Frucht — vor allem für Seiten mit vielen Ressourcen.

Größere Maßnahmen — architektonische Eingriffe

• Wechsel zu vorgenerierter Auslieferung: Wenn die Inhalte sich selten ändern, kann der Wechsel von einer dynamisch erzeugten Seite zu einer statisch vorgenerierten Auslieferung den Tempo-Eindruck deutlich verbessern — der Server schickt fertige Dateien aus, nichts muss pro Aufruf neu berechnet werden.
• Hosting nah am Zielmarkt: Für eine deutschsprachige Zielgruppe ist ein Hosting in Mitteleuropa praktisch immer schneller als die transatlantische Variante. Wirkt vor allem auf die erste Antwortzeit und damit auf LCP.
• Architektur-Refactoring: Wenn das JavaScript-Bundle zu groß ist und nicht gesplittet ausgeliefert wird, hilft auf Dauer nur eine saubere Trennung — Komponenten lazy laden, ungenutzten Code entfernen, Bundles pro Seitentyp generieren. Wirkt auf INP, ist aber aufwendig.

Was sich oft nicht lohnt — typische Fehlinvestitionen

Genauso wichtig wie die Frage, was hilft, ist die Frage, was als Lösung verkauft wird, aber selten etwas verändert. Sechs Muster tauchen in fast jedem Tempo-Audit auf.

Wann ein Profi nötig ist — und woran man ihn erkennt

Vieles davon lässt sich intern angehen, wenn jemand mit ruhiger Hand am Front-End arbeitet. Es gibt drei Konstellationen, in denen externe Hilfe meist schneller ans Ziel kommt.

• LCP bleibt nach mehreren Eigenversuchen über 4 Sekunden: Wenn Bild-Optimierung, Preload und Critical CSS bereits gesetzt sind und der Wert nicht in den grünen Bereich kommt, liegt das Problem tiefer — Server-Antwortzeit, Render-Architektur oder Drittanbieter-Skripte, die nicht offensichtlich sichtbar sind.
• INP-Werte sind diffus oder nicht reproduzierbar: Wenn synthetische Tests gute Werte zeigen, aber der Echtdaten-Bericht „schlecht" meldet, fehlt der Blick auf die tatsächlich gemessenen Interaktionen — das ist ohne Real-User-Monitoring schwer zu klären.
• Das System ist ein gewachsenes CMS mit vielen Erweiterungen: Wenn niemand mehr genau weiß, welche Erweiterung welche Skripte lädt und welche davon noch nötig sind, ist eine systematische Inventur die schnellere Lösung — und braucht meistens externe Augen.

Ein seriöser Tempo-Audit beginnt mit Echtdaten und einer Diagnose pro URL-Gruppe, nicht mit einer pauschalen Empfehlung. Wer „in der ersten Sitzung das Caching-Plugin empfiehlt" oder ein „Tempo-Paket" verkauft, ohne den Echtdaten-Bericht angeschaut zu haben, optimiert auf Verdacht — und das ist selten das, was am Ende wirkt.