Wie die Ladezeit die Conversion-Rate Ihrer Landingpage beeinflusst

Wann eine langsame Seite eine Conversion kostet

Wer auf eine Anzeige klickt, erwartet das Angebot, das den Klick ausgelöst hat. Bleibt der erste Bildschirm leer, verlassen manche die Seite, bevor sie etwas lesen. Sieht ein Button aktiv aus und reagiert nicht, tippen sie vielleicht mehrmals darauf. Eine verspätete Bestätigung kann dazu führen, dass dasselbe Formular ein zweites Mal abgeschickt wird: Zwei erfasste Ereignisse stehen dann für nur eine Anfrage.

Die Ladezeit allein sagt keine Verkäufe voraus. Besucher mit schwächeren Smartphones erleben die Seite womöglich langsamer und haben andere Absichten als Desktop-Nutzer. Konvertiert diese Gruppe seltener, prüfen Sie, über welche Kampagnen sie kam und wonach sie sucht, bevor Sie das Ergebnis der Ladezeit zuschreiben. Auch eine schnelle Seite kann ein schwaches Angebot haben. Zu Inhalt und Bedienbarkeit finden Sie mehr im Ratgeber zur Conversion-Optimierung von Landingpages.

Welche Messwerte Sie lesen und was sie aussagen

Google bewertet diese Core-Web-Vitals-Schwellenwerte am 75. Perzentil, kurz p75, getrennt für Mobil und Desktop. Bei jedem Messwert müssen mindestens 75 % der Beobachtungen den Schwellenwert einhalten. Der Median aus drei lokalen Tests beschreibt diese drei Seitenaufrufe unter den Testbedingungen. Ob echte Nutzer die Schwellenwerte erreichen, lässt sich damit nicht feststellen.

In PageSpeed Insights stützt sich der Abschnitt zur Erfahrung echter Nutzer auf den Chrome User Experience Report (CrUX) und umfasst die vergangenen 28 Tage. Prüfen Sie, ob der Bericht die URL oder den Ursprung beschreibt, also alle Seiten mit gleichem Protokoll, gleicher Domain und gleichem Port. Die Daten für https://qreativa.com zum Beispiel decken mehrere Seiten ab, nicht nur diesen Ratgeber. Reichen die Daten nicht aus, tragen Sie „nicht verfügbar“ ein. Ein Lighthouse-Wert kann diese Lücke nicht füllen. Wie die Daten abgedeckt und zusammengefasst werden, erklärt die Dokumentation zu PageSpeed Insights.

Der Laborabschnitt führt Lighthouse unter simulierten Bedingungen aus. Die Total Blocking Time (TBT) hilft, Aufgaben zu erkennen, die den Hauptthread des Browsers belegen und ihn während des Ladens am Reagieren hindern. Sie misst nicht den INP: Ein Formular kann langsam werden, nachdem ein Chat-Widget gestartet ist oder während Eingaben geprüft werden. Googles Erklärung der Unterschiede zwischen Labor- und Felddaten zeigt, warum Sie auch Interaktionen und Layoutverschiebungen über den gesamten Besuch hinweg prüfen müssen.

So sammeln Sie vergleichbare Belege

Führen Sie für eine erste Diagnose drei aufeinanderfolgende Tests mit dem mobilen Profil und drei mit dem Desktop-Profil durch, jeweils vor und nach der Änderung. So entstehen sechs Berichte für den Ausgangszustand und sechs für die Nachkontrolle, zusammen 12. Wiederholte Durchläufe zeigen, wie stark die Ergebnisse unter gleichen Bedingungen streuen. Wie viele Besucher dieselbe Erfahrung machen, sagen sie nicht. Schlägt ein Test fehl, speichern Sie den Fehler und beheben das Problem, bevor Sie den Test wiederholen.

1. Seite und Testbedingungen festhalten

   Notieren Sie die endgültige URL nach allen Weiterleitungen, Datum und Uhrzeit, die Seitenversion, das Gerät oder simulierte Profil, den Browser und die Version des Tools. Halten Sie Netzwerk- und CPU-Einstellungen fest, außerdem, ob Sie Cache und andere Websitedaten gelöscht haben, welche Einwilligung gewählt war und ob der Nutzer angemeldet war. Bewahren Sie Kampagnenparameter auf, die nötig sind, um den Weg nachzustellen, lassen Sie personenbezogene Daten aber aus dem Protokoll heraus.

2. Bedingungen in allen Durchläufen gleich halten

   Für eine erste Diagnose genügt PageSpeed Insights. Für lokale Tests öffnen Sie die Seite in Chrome und anschließend die DevTools mit F12. Wählen Sie im Bereich „Lighthouse“ den Navigationsmodus und das mobile Profil und starten Sie die Analyse dreimal. Wiederholen Sie das mit dem Desktop-Profil. Verwenden Sie ein Browserprofil ohne Erweiterungen und schließen Sie ressourcenhungrige Anwendungen. Lassen Sie alle Einstellungen gleich, auch die Option, vor jedem Durchlauf die Websitedaten zu löschen. Speichern Sie jeden Bericht über das Exportmenü unter einem Namen wie before-mobile-1. Vergleichen Sie nur Ergebnisse desselben Tools: PageSpeed Insights und lokale Durchläufe arbeiten möglicherweise unter anderen Bedingungen.

3. Den Ablauf auf dem Smartphone testen

   Öffnen Sie den Kampagnenlink, lesen Sie das Angebot, öffnen Sie das Formular und füllen Sie die Felder aus. Lassen Sie ein Pflichtfeld leer, um die Fehlermeldung zu prüfen, senden Sie das Formular dann mit vereinbarten Testdaten ab und kontrollieren Sie die Bestätigung. Wiederholen Sie den Ablauf einmal mit abgelehnter und einmal mit erteilter Einwilligung; das sind zwei getrennte Testbedingungen. Stellen Sie sicher, dass nur eine Anfrage ankommt und das Tracking die Einwilligungsentscheidung respektiert. Halten Sie Verzögerungen und Layoutverschiebungen fest, mit Screenshots oder einer Aufzeichnung aus dem Bereich „Leistung“ der DevTools.

4. Median, Spannweite und Beleg für das Problem aufbewahren

   Sortieren Sie für jedes Profil die drei Werte Ihres gewählten Messwerts und nehmen Sie den mittleren als Median. Bewahren Sie auch Minimum und Maximum auf. Bestimmen Sie das Bild oder den Textblock, der den LCP festlegt, oder die Interaktion, die langsam ist, und hängen Sie den Bericht an, der das zeigt. Wiederholen Sie nach der Veröffentlichung die Testreihe und die Funktionsprüfungen auf der neuen Live-Version.

Um echte Nutzer genau dieser Seite zu messen, kann ein Entwickler die Web Vitals per Real User Monitoring (RUM) erfassen und dabei Seitenversion, Gerät und Zeitraum festhalten. Um Conversions zusammen mit der Leistung auszuwerten, müssen Sie Leistung und Ergebnis desselben Besuchs verknüpfen und dabei die Einwilligungsentscheidungen beachten. Aggregierte CrUX-Berichte sagen nichts über das geschäftliche Ergebnis eines einzelnen Besuchs.

Vom Symptom zur Lösung: was Sie zuerst prüfen

Zeichnen Sie in den DevTools einen Seitenaufruf im Bereich „Leistung“ auf und wählen Sie das LCP-Ereignis aus. In Lighthouse-Berichten sehen Sie sich das LCP-Element und, sofern vorhanden, die Aufschlüsselung der Zeiten an. Verfolgen Sie im Bereich „Netzwerk“ das HTML-Dokument und die wichtigste Ressource. Wenn Sie für weitere Untersuchungen das Tool oder die Bedingungen wechseln, bewahren Sie diese Aufzeichnung getrennt von Ihrer vergleichbaren Testreihe auf.

Liefert das Formular eine Anfrage nicht aus oder sendet es sie doppelt, beheben Sie zuerst diesen Fehler. Bei anderen Verzögerungen überlegen Sie, wie viele Besuche sie betreffen und wie stark sie die gewünschte Handlung behindern. Ein Angebot, das für jeden mobilen Besucher spät erscheint, hat in der Regel Vorrang vor einem langsamen Widget, das nur wenige öffnen. Halten Sie zu jeder Korrektur fest, wer sie umsetzt, was sie voraussichtlich kostet und mit welchem Test Sie prüfen, ob sie das Problem gelöst hat.

Für den LCP unterteilt Googles Optimierungsleitfaden die Zeit in Wartezeit auf das HTML, Verzögerung beim Laden der Ressource, Downloadzeit und Darstellungsverzögerung. Für Interaktionen nutzen Sie die Hinweise zur INP-Fehlersuche. Entfernen Sie doppelte oder unnötige Tags, prüfen Sie nach jeder Änderung aber das Verhalten bei der Einwilligung und die nötigen Ereignisse. Wer die Analytics entfernt, lässt womöglich nur die Daten verschwinden und löst die Verzögerung nicht, die Ihre Kunden erleben.

Ein Beispiel: den LCP von 4,0 auf 2,4 Sekunden senken

Angenommen, eine mobile Landingpage lädt ihr Hauptbild per JavaScript. Der Trace zeigt, dass die Anfrage spät startet und die Datei größer ist als nötig. Ein Entwickler nimmt das Bild ins erste HTML auf, entfernt das Lazy Loading und liefert eine kleinere Datei aus. Text, Angebot und Formular bleiben gleich.

Angenommen, die drei mobilen Tests ergeben vor der Änderung LCP-Werte von 3,9 / 4,0 / 4,2 Sekunden und danach 2,3 / 2,4 / 2,6 Sekunden. Der Median sinkt von 4,0 auf 2,4 Sekunden, also um 1,6 Sekunden oder 40 % des Ausgangswerts (1,6 / 4,0 × 100). Die mediane TBT bleibt bei 180 ms und der mediane CLS bei 0,02. Das LCP-Element erscheint in den Labortests jetzt früher. Interaktionen und die Core Web Vitals echter Nutzer brauchen weiterhin die oben beschriebenen Prüfungen.

Bestätigt die Live-Seite diese Zeiten und funktioniert das Formular weiterhin, können wir die Änderung beibehalten. Im gezeigten Seitenaufruf vergehen zwischen dem Ende des Downloads und dem Erscheinen des Bildes allerdings noch 1,1 Sekunden. Als Nächstes klären Sie, was es zurückhält. Wartet es auf JavaScript, bringt eine noch kleinere Datei das Bild womöglich nicht früher auf den Bildschirm.

So beurteilen Sie die Wirkung auf Conversions

Legen Sie vorab fest, was als Conversion zählt. Bei einer Seite zur Leadgenerierung können Sie Nutzer zählen, die mindestens eine erfolgreich eingegangene Anfrage senden. Zwei Anfragen derselben Person zählen als eine Conversion. Teilen Sie diese Nutzer durch alle Nutzer im Vergleich und multiplizieren Sie mit 100, um die Rate zu erhalten. Werten Sie nur mobilen Traffic aus, müssen beide Zahlen diese Zielgruppe und denselben Zeitraum betreffen. Ein Klick auf einen Button belegt allein nicht, dass die Anfrage angekommen ist.

Prüfen Sie außerdem, wie viele dieser Nutzer nach den Kriterien Ihres Vertriebs zu qualifizierten Leads werden oder einen Kauf abschließen. Geben Sie jeder Anfrage gleich viel Zeit zur Bewertung. Sonst wirken jüngere Anfragen schlechter, nur weil sie noch niemand geprüft hat.

Wenn Sie im selben Zeitraum zwei gleichwertige Versionen ausspielen können, weisen Sie Nutzer zufällig A oder B zu und lassen Sie sie bei Rückkehr auf derselben Version. Ändern Sie nur das Bündel technischer Verbesserungen, das Sie bewerten wollen. Stellen Sie sicher, dass weder Caching noch der Server noch der Experimentcode beiden Gruppen dieselbe Optimierung oder eine andere Verzögerung verschafft. Legen Sie Stichprobengröße, Dauer, primären Messwert und Entscheidungsregel fest, bevor Sie starten. Der Ratgeber zur Conversion-Optimierung erklärt, wie Sie einen A/B-Test aufsetzen.

Reicht der Traffic für einen A/B-Test nicht aus oder betrifft die Änderung einen Server, den beide Versionen teilen, können Sie sie ausrollen und beobachten, was passiert. Halten Sie Änderungen an Budget, Zielgruppe, Anzeigengestaltung, Angebot und Tracking fest, denn sie könnten eine Veränderung der Conversions erklären. Ein schrittweises Ausrollen ohne zufällige Zuweisung beseitigt dieses Problem nicht. Der web.dev-Leitfaden zum Zusammenhang zwischen Ladezeit und Geschäftskennzahlen behandelt, wie Sie die Kennzahlen verknüpfen und Experimente einsetzen.

Angenommen, Sie beobachten dieselbe Landingpage 14 Tage vor und 14 Tage nach der Korrektur. Jeder Zeitraum umfasst 5.000 mobile Nutzer. Zählen Sie jeden Nutzer einmal und bewerten Sie Anfragen innerhalb von sieben Tagen nach Eingang.

Die Anfragequote steigt von 200 / 5.000 × 100 = 4,0 % auf 230 / 5.000 × 100 = 4,6 %. Das sind 0,6 Prozentpunkte mehr, relativ zur Ausgangsquote also 15 %: (4,6 − 4,0) / 4,0 × 100. Auch die Zahl der Nutzer mit angenommener Anfrage steigt, von 120 auf 140. Bei 5.000 Nutzern je Zeitraum wächst diese Quote von 2,4 % auf 2,8 %. Lesen Sie die Ergebnisse sieben Tage nach Ende jedes Zeitraums ab, damit auch die letzten Anfragen das volle Bewertungsfenster hatten.

Nehmen wir nun an, dass sich zu Beginn des zweiten Zeitraums auch die Anzeigengestaltung geändert hat. Die 30 zusätzlichen Nutzer mit Anfrage können auf die schnellere Seite, die neue Anzeige oder beides zurückgehen. Die bereits geprüfte technische Korrektur können Sie behalten, doch diesen Anstieg um 15 % für eine Verkaufsprognose heranzuziehen, wäre nicht gerechtfertigt. Ein Test zwischen Gruppen im selben Zeitraum bleibt, sofern machbar, die aussagekräftigere Methode, um die Wirkung der Ladezeit zu schätzen. Mehr Vorher-nachher-Daten helfen bei der Beobachtung, können die Effekte anderer Änderungen aber nicht für sich allein trennen.

Wenn Besucher gehen, bevor das Tag startet, entgehen Ihrer Messung womöglich gerade die langsamsten Besuche. Legen Sie offen, woher Ihre Zahlen stammen: vom Server empfangene Seitenanfragen, von der Analytics erfasste Besuche oder Nutzer, die eingewilligt haben. Teilen Sie die Conversions einer Gruppe nie durch die Besuche einer anderen. Der Ratgeber zur Messung der Landingpage-Leistung erklärt Ereignisse und Datenqualität ausführlicher.

Vorher-nachher-Protokoll und Entscheidung zur Freigabe

Kopieren Sie diese Vorlage für jede Seite und jede Änderung. Bewahren Sie die ursprünglichen Berichte und die Aufzeichnungen des Problems auf. Halten Sie am Ende fest, ob die Korrektur die Verzögerung verringert hat und, getrennt davon, was die Conversion-Daten zeigen.

Endgültige URL und Seitenversionen vorher/nachher:
Datum und Uhrzeit, Profil mobil/Desktop, Browser und Version des Tools:
Netzwerk- und CPU-Einstellungen, Löschen von Websitedaten, Einwilligung und Anmeldestatus:
Beobachtetes Problem, Element oder Interaktion, angehängter Bericht oder Aufzeichnung:
Vermutete Ursache, geplante Änderung und verantwortliche Person:
Mobil vorher: Durchläufe 1 / 2 / 3; Median, Minimum und Maximum je Messwert
Mobil nachher: Durchläufe 1 / 2 / 3; Median, Minimum und Maximum je Messwert
Desktop vorher: Durchläufe 1 / 2 / 3; Median, Minimum und Maximum je Messwert
Desktop nachher: Durchläufe 1 / 2 / 3; Median, Minimum und Maximum je Messwert
Jeder Durchlauf: LCP in Sekunden, TBT in Millisekunden und CLS; Bericht anhängen
Felddaten: Quelle, URL oder Ursprung, Zeitraum, Gerät und 75. Perzentil;
falls nicht vorhanden, „nicht verfügbar“ eintragen
Test auf dem Smartphone: Angebot, Formular, Fehlermeldungen, Absenden, Bestätigung und Einwilligung
Conversions: Zeitraum, einbezogene Zielgruppe, Datenquelle und Zählregeln;
alle Nutzer und Nutzer mit mindestens einer gültigen Anfrage
Leadqualität: Nutzer mit angenommener Anfrage oder Kauf und Zeit bis zur Bewertung
Andere Änderungen an Kampagne oder Seite, Fehler und fehlende Daten:
Technisches Ergebnis: Änderung beibehalten, überarbeiten oder zurücknehmen, mit Begründung
Geschäftliches Ergebnis: was Sie daraus schließen können und wann Sie erneut prüfen:

Funktioniert das Formular nach der Änderung nicht mehr, beheben Sie das oder stellen Sie die vorherige Version wieder her. Funktioniert alles und sinkt die Verzögerung unter gleichen Testbedingungen, können Sie die Korrektur beibehalten und weiter echte Besuche beobachten. Bleiben die Zeiten im Bereich, den Sie vorher festgehalten haben, zeigt der Test keine klare Verbesserung. Sehen Sie sich dann die Aufzeichnung des Problems an, bevor Sie die Tests wiederholen.