Bei uns lädt das Test-Skript asynchron neben der Seite her, ist rund 40 KB groß und hält die Seite nicht an. Ausgeblendet wird nur, was eine Variante im sichtbaren Bereich ändert, und dann höchstens 300 Millisekunden. Und jede Variante muss vor dem Start zeigen, dass sie nicht spürbar langsamer lädt als die Kontrolle.
Was ein modernes Setup anders macht
Asynchron laden
Das Skript steht nicht im Weg, den der Browser zum ersten Anzeigen der Seite braucht. Die Seite baut sich auf, das Test-Tool lädt parallel.
Klein und gecacht
Das Skript kommt aus einem CDN und bleibt im Browser-Cache. Ab dem zweiten Seitenaufruf lädt der Besucher es nicht erneut.
Nur ausblenden, was sich ändert
Ausgeblendet wird nur, wo eine Variante wirklich etwas im sichtbaren Bereich ändert, und dann für einen Sekundenbruchteil. Alles andere zeigt sich sofort.
Der schlechte Ruf von Test-Tools stammt aus der Zeit, als die ganze Seite ausgeblendet wurde, bis der Test geladen war. Google Optimize, 2023 eingestellt, hat dafür bis zu vier Sekunden gewartet. Wie es heute anders geht, zeigt der nächste Abschnitt.
Was Browser heute können
Das Chrome-Team beschreibt in seinen Empfehlungen für flackerfreies Testen im Browser einen Weg ohne die alten Ausblende-Snippets: das Test-Skript im Kopf der Seite mit dem Attribut blocking=“render“ laden, die Variante über CSS schalten und die Ausführungszeit mit einem Budget begrenzen, etwa unter 100 Millisekunden.
Serverseitig, wenn es sein muss
Wo es auf jede Millisekunde ankommt, liefert der Server oder das CDN die Variante direkt aus. Dann gibt es gar kein Test-Skript im Browser. Shopify geht mit Rollouts diesen Weg, mit eigenen Grenzen, die wir in unserem Artikel zu Shopify Rollouts beschrieben haben.
So sieht das bei uns aus
Unser Test-Skript kommt aus einem CDN, lädt asynchron und ist rund 40 KB groß, komprimiert. Der Programmteil bleibt eine Woche im Browser-Cache, die Testkonfiguration wird alle paar Minuten frisch geladen. Das Rendern der Seite blockiert es nicht.
Jede Variante wird vor dem Start gegen die Kontrolle gemessen: Wann ist das größte Element sichtbar, und verschiebt sich etwas im Layout? Ist die Variante dabei spürbar schlechter, startet sie nicht. Page Speed prüfen wir vor dem Test, damit danach niemand darüber diskutieren muss.
Woran Sie ein modernes Setup erkennen
- Das Test-Skript ist mit async eingebunden oder kommt über den Tag Manager, der ohnehin asynchron lädt.
- Im Quelltext steht kein Snippet, das den ganzen body auf opacity: 0 setzt. Falls doch, prüfen Sie das Zeitlimit. Ein paar hundert Millisekunden sind in Ordnung, mehrere Sekunden sind ein Überbleibsel.
- Die Konfiguration enthält nur laufende Tests. Beendete Tests und Entwürfe haben im Paket nichts verloren, das jeder Besucher herunterlädt.
- Wer es genau wissen will, lädt dieselbe Seite 20 Mal mit und 20 Mal ohne Test-Skript. In den Chrome DevTools lässt sich die Domain des Tools dafür blockieren. Maßstab ist das Largest Contentful Paint, also der Zeitpunkt, an dem das größte Element sichtbar ist. Google nennt 2,5 Sekunden als Grenze für einen guten Wert.
Was am Ende zählt
Page Speed ist eine Kennzahl, Umsatz pro Besuch die andere. Mit einem sauberen Setup müssen Sie sich zwischen beiden nicht entscheiden. Die Tests laufen, und der Shop bleibt schnell.
Im 14-Tage Proof of Value zeigen wir das in Ihrem Shop, bevor Sie sich entscheiden.
Quellen
- Chrome-Team, Modern Web Guidance: Flicker-free client-side A/B testing
- Andy Davies: The Case Against Anti-Flicker Snippets, 16.11.2020, zum Vier-Sekunden-Standard von Google Optimize
- web.dev: Web Vitals, Grenzwert für ein gutes Largest Contentful Paint
Zuletzt aktualisiert:
