Langsamere Website und sinkende Conversion-Rate: So finden Sie die Änderung dahinter

Kann eine langsamere Website die Conversion-Rate senken?

Ja, aber die Verlangsamung ist nur dann die Ursache, wenn sie vor dem Rückgang begann und genau die Seiten und Geräte traf, auf denen die Conversions gesunken sind. Ladezeitprobleme kommen selten allein: Das Release, das die Seiten schwerer gemacht hat, hat oft auch Layout, Formular oder Tracking verändert.

Die Ladezeit zählt, weil Besucher, die auf den Hauptinhalt warten oder auf einen Button tippen und keine Reaktion sehen, abspringen, bevor sie den Checkout oder das Lead-Formular erreichen. Google misst diese Momente mit drei Core Web Vitals: Largest Contentful Paint (LCP) für das Laden, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität.

Dieser Artikel verspricht keine Zahl verlorener Verkäufe pro Sekunde Verzögerung. Veröffentlichte Werte schwanken je nach Website und stammen oft aus Anbieterstudien. Was Sie tun können: mit Ihren eigenen Daten zeigen, dass eine datierte Änderung die Seiten verlangsamt hat und die Conversions zur selben Zeit auf denselben Seiten gesunken sind. Die allgemeine Methode für jeden Rückgang finden Sie im Ratgeber einen Conversion-Rückgang gegenüber Kunden erklären.

Welche Änderungen machen eine Website typischerweise langsamer?

Die meisten Geschwindigkeitseinbrüche gehen auf eine Änderung zurück, die jemand veröffentlicht hat, nicht auf Google oder den Hoster. Die üblichen Verdächtigen sind neue Skripte, schwerere Medien und Code-Releases.

Googles Leitfaden zu Tags erklärt, dass Zeit auf dem Hauptthread für das Auswerten und Ausführen des JavaScripts im Tag-Manager und in den Tags selbst anfällt, und die Autoren berichten von einem Zusammenhang zwischen größeren Containern und schlechterem INP. Doppelte Tags, etwa ein fest im HTML eingebautes Pixel, das zusätzlich über GTM ausgespielt wird, kosten Ladezeit ohne zusätzliche Daten. Haben Sie ein Tag im Verdacht, beginnen Sie mit dem Versionsverlauf in GTM.

Wie prüfe ich, ob die Website wirklich langsamer geworden ist?

Vergleichen Sie Felddaten echter Nutzer vor und nach der verdächtigen Änderung und nutzen Sie Labortests nur, um die Ursache zu finden. Ein einzelner Lighthouse-Wert ist kein Beweis: Google weist darauf hin, dass Laborergebnisse zwischen Durchläufen schwanken, etwa wegen Netzwerk, Hardware und Ressourcenkonkurrenz.

Google bewertet jede Kennzahl am 75. Perzentil der Seitenaufrufe. Drei Tools decken die meisten Fälle ab:

• PageSpeed Insights zeigt Felddaten aus dem Chrome UX Report für die vorangegangenen 28 Tage, auf URL-Ebene oder, wenn die URL zu wenige Daten hat, auf Ebene des Ursprungs, dazu einen Lighthouse-Labortest.
• Der Core Web Vitals-Bericht in der Search Console fasst ähnliche URLs zu Gruppen zusammen und zeigt, wie viele in den letzten 28 Tagen gut, verbesserungswürdig oder schlecht sind. Gruppen ohne ausreichende Daten fehlen.
• Ihr eigenes Real-User-Monitoring, falls vorhanden, ist die einzige Quelle, die am Tag des Releases einen täglichen Sprung zeigt.

Das 28-Tage-Fenster ist für die Datierung wichtig. Da PageSpeed Insights jeden Tag die vorangegangenen 28 Tage zusammenfasst, erscheint eine Verlangsamung, die an einem Dienstag begann, als allmählicher Anstieg über die folgenden Wochen, nicht als Stufe. Lesen Sie das Datum ab, an dem die Kurve abknickt, und bestätigen Sie es mit Labortests der alten und der neuen Version.

Wie isoliere ich, welche Änderung die Verlangsamung und den Rückgang verursacht hat?

Legen Sie alle Änderungen aus der Woche vor dem Rückgang auf eine Zeitachse, schließen Sie zuerst das Tracking aus und testen Sie dann die Ladezeit-Hypothese auf den langsameren Seiten. Ein Rückgang der gemessenen Conversions kann auch von einem defekten Tag kommen. Prüfen Sie daher, ob das Conversion-Tag in der neuen Version noch auslöst, bevor Sie die Ladezeit verantwortlich machen.

1. Notieren Sie den Tag des Rückgangs und wo er auftrat: mobiler Checkout, eine Landingpage oder die ganze Website.
2. Listen Sie alle Änderungen der 7 bis 14 Tage davor auf: Releases, Theme- oder Plugin-Updates, GTM-Versionen, neue Skripte und Änderungen an der Einwilligung, dazu Änderungen in den Anzeigen wie Gebote, Budgets und finale URLs.
3. Markieren Sie, welche Änderungen die betroffenen Seiten berührt haben. Ein neues Skript auf allen Seiten und ein Rückgang nur im mobilen Checkout deuten auf die Reaktionsfähigkeit auf Mobilgeräten.
4. Testen Sie alte und neue Version der Seite im Labor und suchen Sie das Skript oder die Datei, die am meisten Zeit kostet.

Beispiel: Ein Online-Möbelhändler fragt, warum die mobilen Verkäufe am Dienstag eingebrochen sind, während Desktop stabil blieb. Die Änderungen nebeneinander zeigen ein am Freitag in GTM hinzugefügtes Chat-Tag, ein neues Hero-Video auf den Produktseiten am Samstag und keine Änderungen in den Anzeigen. Labortests zeigen, dass das Video jetzt das LCP-Element ist und deutlich später lädt als das alte Bild. Das Team ersetzt das Video durch ein Standbild, und die mobilen Verkäufe erholen sich in der Woche darauf. Namen und Zahlen sind fiktiv.

Mit allen Änderungen auf einer Zeitachse sähen Sie, dass das Video drei Tage vor dem Rückgang live ging, auf genau dem Template, auf dem die mobilen Verkäufe sanken. In Changeline erfassen Sie jedes Release, jedes Tag und jede Änderung an der Einwilligung mit Datum, verantwortlicher Person und Grund, und Änderungen in Google Ads werden automatisch importiert. So existiert die Liste aus Schritt 2 bereits, wenn die Frage kommt.

Wie belege ich, dass die Verlangsamung und nicht etwas anderes die Conversions gesenkt hat?

Sie belegen es, indem Sie zeigen, dass drei Dinge zusammenpassen: Die Verlangsamung begann mit der Änderung, die Conversions sanken nur auf den betroffenen Seiten und Geräten, und sie erholten sich, als die Änderung zurückgenommen oder behoben wurde.

1. Auslösen des Trackings prüfen
2. Verlangsamung in Felddaten datieren
3. Betroffene und andere Seiten vergleichen
4. Änderung zurücknehmen oder beheben
5. Erholung der Conversions verfolgen

• Nach Gerät und Seite segmentieren. Blieb die Conversion-Rate auf Desktop stabil, sank sie mobil, und betrifft die Verlangsamung vor allem Mobilgeräte, ist das ein starkes Indiz. Ein Rückgang auf allen Geräten und Seiten deutet woandershin.
• Den Traffic-Mix prüfen. Eine neue Kampagne, Zielgruppe oder ein neues Budget kann am selben Tag weniger kaufbereite Besucher bringen. Sehen Sie sich die Conversion-Rate nach Quelle an, bevor Sie der Ladezeit die Schuld geben. Die übrigen Ursachen finden Sie unter warum die Conversion-Rate sinkt.
• Eine Kontrollgruppe nutzen. Seiten ohne das neue Skript oder die neue Datei sind Ihre Kontrollgruppe. Blieben sie stabil, ist die Änderung die wahrscheinlichere Ursache.
• Zurücknehmen und beobachten. Das Skript zu entfernen oder das Release zurückzurollen ist der sauberste Test. Erfassen Sie die Rücknahme als eigene Änderung, damit auch die Erholung datiert ist.

Halten Sie die Belege schriftlich fest: die Änderung, das Datum, die Labormessungen vorher und nachher sowie die Conversion-Rate auf betroffenen und übrigen Seiten. Genau das wird der Kunde oder Ihre Führungskraft verlangen, und es verhindert, dass dieselbe Diskussion einen Monat später wieder beginnt.

Wie verhindere ich, dass die Verlangsamung zurückkommt?

Machen Sie die Ladezeit zum Teil jedes Releases und jedes neuen Tags, und dokumentieren Sie, was wann live ging. Die meisten Regressionen kehren zurück, weil ein Skript erneut eingebaut wird oder niemand mehr weiß, warum es entfernt wurde.

Google empfiehlt, ungenutzte Tags zu pausieren oder zu entfernen, statt sie mit einer Trigger-Ausnahme zu blockieren, weil ein blockiertes Tag seinen Code weiterhin im Container mitliefert. Ein gemeinsames Marketing-Änderungsprotokoll gibt Entwicklern und Marketing eine einzige Quelle zum Nachschlagen, und das Änderungsprotokoll für die Website behandelt die Website-Seite ausführlicher.