Server-Side-Rendered-Architekturen (SSR) haben sich etabliert. Schneller wahrgenommene Ladezeiten durch schnelleren FCP, eine bessere SEO-Performance und gleichzeitig eine stabile User Experience gehören mit zu den Hauptgründen, die für eine solche Architektur sprechen. So haben die meisten Single Page Applications (SPA) wie React.js, Vue.js oder Svelte ein SSR-Äquivalent auf dem Markt – oder zumindest eine Mischform aus statischer Generierung (SSG) und clientseitigen Updates (Hydration).

Doch was bedeutet das für Experimentation im Kontext von A/B-Testing und Personalisierungskampagnen? Wer mit den bisher klassischen clientseitigen Ansätzen vertraut ist, fragt sich oft, wie solche Tests in einer SSR-Umgebung am besten umgesetzt werden können. Genau darum geht es in dieser zweiteiligen Reihe.

In Teil 1 werfen wir einen Blick auf die DOM-Manipulation und beleuchten, welche Implikationen sie in SSR-Setups hat. Dabei werden wir feststellen, dass der Begriff inzwischen ein deutlich breiteres Anwendungsgebiet hat und mehr als nur “client-side” als Attributs-Präfix verdient. In Teil 2 verlassen wir die DOM-Manipulation und bewegen uns in die Bereiche der Produktivumgebung, den nativen und unkomprimierten Code.

Für wen ist dieser Beitrag gedacht?

Für Techies oder technisch affinere, die bereits erste Erfahrung mit SSR-Frameworks wie Next.js, Nuxt.js oder SvelteKit haben oder sich gerade in solche Umgebungen einarbeiten und überlegen, wie sie Experimentation in diesen Umgebungen realisieren können oder es bereits schon tun. Aber auch für jene, die gerade einen eigenen Ansatz für SSR verfolgen oder noch in älteren Architekturen unterwegs sind lohnt es sich weiterzulesen.

What’s in it for you?

1. Du bekommst ein Gespür dafür, wie klassische DOM-Manipulation in SSR-Setups funktioniert und welche alternativen Vorgehensweisen es gibt.
2. Eine Übersicht und Entscheidungshilfe, wie du Testing in deiner SSR-Umgebung angehen kannst.

 Begriffsabgrenzung

• SSR (Server-Side Rendering): Deine Anwendung oder Webseite wird bereits auf dem Server gerendert und als fertiges HTML ausgeliefert. Das verbessert meist Performance und SEO.
• SPA (Single-Page Application): Die gesamte App läuft größtenteils im Browser. Seitenwechsel finden “virtuell” statt, ohne die komplette Seite neu zu laden. Beispiele: React mit clientseitigem Routing, Vue mit Vue Router etc.
• DOM (Document-Object-Model): Repräsentiert den semantischen Aufbau der Seite
• CST (Client-Side Testing) – bisher: Oberbegriff für verschiedene Verfahren, bei denen Experimente bereits clientseitig via DOM-Manipulation umgesetzt werden.
• SST (Server-Side Testing) – bisher: Oberbegriff für verschiedene Verfahren, bei denen Experimente bereits serverseitig vorbereitet oder sogar vollständig ausgespielt werden.
• SSG (Static Site Generation): Serverseitiges Caching fester Seiten. HTML, CSS und Javascript werden für spezifische Seiten, welche meist nur sehr wenig Seitenlogik haben, einmal vorgerendert und immer wieder verwendet.

Die Generalisierung der DOM-Manipulation: Ein Historischer Rückblick

Ende der 2000er Jahre, als die heutige Thematik des A/B-Testing noch in den Kinderschuhen steckte, setzten viele Tools fast ausschließlich auf clientseitige DOM-Manipulation. Dabei genügte es, ein JavaScript-Snippet in den Header der Seite einzubinden. Sobald die Seite im Browser aufgebaut ist, wird vom Testing-Tool geprüft, ob Nutzer:innen zum Beispiel Variante A oder Variante B sehen sollen. Die entsprechenden Änderungen wurden dann direkt am DOM vorgenommen. Die damaligen Gegebenheiten:

• harte Seitenwechsel: Bei Seitenwechseln sah man oft kurz einen weißen Bildschirm, bevor die neue Seite geladen wurde. Die Test-Varianten wurden (falls korrekt eingerichtet) direkt oder leicht verzögert angezeigt.
• jQuery-Dominanz: Lastiges jQuery vereinfachte komplexere Logik-Aufgaben. Ansonsten reichten einfache Event-Listener oder einfache Polling-Mechanismen, um auf Veränderungen der Seite innerhalb des DOMs zu reagieren.

Mit dem Aufkommen von SPAs änderte sich jedoch einiges. Weil nicht mehr jede Seitenansicht einen echten Seitenwechsel darstellt, sondern der Content dynamisch “virtuell” gerendert wird, müssen entweder Testing-Tools komplexe Lifecycle-Events beobachten, um DOM-Änderungen zur richtigen Zeit einzuspielen und in den meisten Fällen im Variantencode zusätzliche Logiken zur Observierung des reaktiven Verhaltens einer Webseite mitgeliefert werden. Das machte die Umsetzung von A/B-Tests in SPAs komplexer und aufwendiger.

Außerdem gewann das Thema SEO weiter an Bedeutung, sodass viele Unternehmen begannen, ihre JS-Applikationen serverseitig vorrendern zu lassen (SSR), um neben dem Performance-Boost bei Google & Co. besser gefunden zu werden. Somit schlussfolgerte sich auch der Bedarf, ausgespielte Experimente schon serverseitig auszuliefern und nicht erst verspätet beim Nutzer im Browser.

Client-Side DOM-Testing (CSDT) + SSR

JavaScript ist mächtig geworden, viel mächtiger als es anfangs geplant gewesen ist. Inzwischen kann es sich problemlos gegen die Funktionalität von JQuery und dessen zusätzliche Lasten behaupten. Und auch wenn jQuery immer noch in vielen Seiten steckt, so ist der Umgang mit JS der favorisierte Ansatz, um Tests zu bauen, den vermutlich die meisten bereits kennen und verwenden. Das Testing-Tool wird mitsamt globalem Skript in die Seite eingebunden. Nach dem Server-Side-Rendering der Originalseite findet die Varianten-Ausspielung mithilfe von CSS- und/oder JavaScript-Manipulationen ausschließlich im Browser des Besuchers statt.

Ablauf

1. Auslieferung des SSR-HTML: Der Server rendert die Grundseite (z.B. in Next.js).
2. Testing-Tool-Snippet: Ein Tracking- oder Testing-Tool (z.B. Adobe Target, Optimizely, etc.) ist in den Header eingebunden.
3. Virtueller Seitenwechsel: Bei SPAs wird kein vollständiger Reload mehr durchgeführt, sondern nur Teile des DOMs neu gerendert. Das Testing-Tool muss sich daher entweder auf Lifecycle-Events und SPA-Router verlassen, um zur richtigen Zeit die Änderungen durch den Varianten-spezifischen Code auszuführen oder seine eigene Observierungslogik implementieren.

Vorteile (Pro)

• Geringer initialer Mehraufwand: Gerade kleine oder CSS-basierte Tests lassen sich schnell umsetzen.
• Autonomie: Das Experimentation-Team braucht kein umfangreiches Server-Know-how und kann sich bei Bedarf von den Deployment-Zyklen loslösen.
• Unterstützung durch viele Tools: Nahezu alle seriösen Testing-Tools sind auf diesen klassischen Ansatz der DOM-Manipulation ausgelegt.

Nachteile (Contra)

• Keine direkte SEO-Optimierung bei 100% Ausspielungen: Änderungen werden erst nachträglich im Browser sichtbar, Nicht alle Suchmaschinen verstehen JavaScript und wenn sie es tun, oft nicht vollständig. Selbst dann ist weiterhin der Nachteil gegeben, dass die korrekte Indexierung nur verzögert stattfindet, da JS-spezifische Änderung erstmal in der Render-Queue von Google landen. Bei 100%-Ausspielung oder Personalisierungskampagnen sollte man dies berücksichtigen. ()
• Potenzielle Performance-Einbußen: Da kontinuierlich das DOM beobachtet werden muss, kann bei zu geringem Erfahrungsgrad mit dessen Umgang die Performance leiden. Besonders bei langsameren Geräten.
• Zunehmende Komplexität bei User-Journey-Tests: Wenn sich Tests über mehrere Schritte erstrecken, werden Code und Konfiguration oft schnell unübersichtlich.
• Moderate Beschränkung im logischen Handlungsfeld: Besonders bei SPAs sind Events wie Add2Cart, Gutscheine einlösen oder übergreifende Logiken tief mit der inneren Architektur verwebt und in einem nicht mehr lesbaren Code-Salat versteckt. Im Rahmen der DOM-Manipulation bleiben einem, mit ein paar Ausnahmen, allerdings sonst nicht mehr Möglichkeiten als einem Nutzer sonst auch zur Verfügung stehen. Funktionen müssen bereits vorhanden sein und dürfen sich nicht ausschließlich im Bereich des aktuellen Chunks befinden.

Serverseitige Manipulation (Server-Side Hydrated Testing, SSHT) + SSR

Eine wichtige Erkenntnis: “DOM-Manipulation” ist nicht zwangsläufig eine clientseitige Aufgabe. In SSR-Umgebungen kann man bereits auf dem Server Veränderungen in das pregerenderte HTML einfügen, bevor es an den Nutzer ausgeliefert wird. Die Idee dahinter:

“Tue (fast) alles schon vorher, damit der Nutzer (und auch Google) die Seite rechtzeitig in der gewünschten Variante erhält, ohne nachträglichen clientseitigen Aufwand.”

Ablauf mit 2 Beispiel-Szenarien

Du verwendest ein Framework wie z.B. Next.js, SvelteKit oder Nuxt.js.

1. Die direkte Manipulation: Anstatt im Browser DOM-Elemente zu ändern, manipulierst du das gerenderte HTML direkt im Server-Kontext (z.B. mit Cheerio in Node.js).
2. Die unmittelbare Manipulation: Diverse Toolanbieter ermöglichen die Auslieferung fertiger HTML-Templates. Teilweise erstellbar über die direkte Benutzeroberfläche, die du nicht nur clientseitig, sondern auch serverseitig bereits in dein Dokument einfügen kannst.

Vorteile (Pro)

• Performance-Boost: Du überbrückst die clientseitige Evaluierung der Variante und lieferst die Ergebnisse direkt mit aus
• Unabhängig vom SPA-Lifecycle: Du musst dich nicht mehr so stark um clientseitige Lifecycle-Events kümmern, da die Testausspielung nun durch serverseitige Logik übernommen werden kann.
• Autonomie: Je nach Setup kann das Experimentation-Team weitgehend autark agieren, ohne bei jedem Test die gesamte DevOps-Kette anstoßen zu müssen.

Nachteile (Contra)

• Komplexe Integration: Für eine saubere Implementierung braucht es für eine Architektur oft maßgeschneiderte Lösungen (z.B. Cheerio oder andere Libraries). Dieser Stitching-Prozess kann besonders aufwändig sein. Besonders bei der direkten Manipulation
• Third-Party-Abhängigkeit: Manche Tools oder Features erfordern AJAX-Calls, um ihre Daten zu laden. Diese müssen serverseitig verfügbar sein. Das kann Latenzen mit sich bringen und erfordert daher eine entsprechende Behandlung (z.B. Batch Jobs zur Ausfallsicherheit).
• Beschränkungen im logischen Handlungsfeld: Besonders bei SPAs sind Events wie Add2Cart, Gutscheine einlösen oder übergreifende Logiken tief mit der inneren Architektur verwebt und in einem nicht mehr lesbaren Code-Salat versteckt. Im Rahmen der DOM-Manipulation bleiben einem, mit ein paar Ausnahmen,  meist nicht mehr Möglichkeiten, als einem regulären Nutzer sonst auch zur Verfügung stehen. Funktionen müssen bereits vorhanden sein und dürfen sich nicht ausschließlich im Bereich des aktuellen Chunks befinden. Gerade bei neueren Seitentypen kann beispielsweise nicht immer ein Add2Cart Schnelleinstieg implementiert werden, wenn dieser vorher auch nicht schon dagewesen ist

Zusammenfassung

• Klassische (clientseitige) DOM-Manipulation bleibt eine valide Möglichkeit, um kleinere Tests schnell und ohne großen Integrationsaufwand umzusetzen. Vor allem bei “mal eben was ausprobieren” oder wenn das umsetzende Experimentation-Team keine tiefe SSR-Kompetenz hat, ist dies weiterhin attraktiv.
• Server-Side-Hydrated-Testing (SSHT) ermöglicht, viele Änderungen schon vor Auslieferung an den Client einzuspielen. Das kommt der SEO und Performance zugute, erhöht allerdings oft die Komplexität der Implementierung und erfordert SSR-spezifisches Know-how.

Wir vergleichen diese weiteren Ansätze anhand von Pro/Contra, Use Cases und Integrationstipps, sodass du einen ganzheitlichen Überblick bekommst, wie du Testing einer SSR- oder Hybrid-Architektur optimal angehen kannst.

Pro/Contra im Überblick

DOM Manipulation ist kein Hexenwerk und das bleibt auch so!

Client-Side-DOM-Testing (CSDT) bleibt ein bewährter Klassiker im Bereich Testing und funktioniert, mit einigen Anpassungen, auch in SSR-Umgebungen. Er birgt aber Limitierungen in puncto Performance und Aufwand, vor allem, wenn reaktive Architekturen wie  SPAs im Einsatz sind und umfangreiche Aufgaben entlang der User-Journey durchgeführt werden sollen.

Mit Server-Side Hydrated Testing (SSHT) kann man viele dieser Probleme umgehen, zahlt dafür jedoch mit einem höheren Komplexitätsgrad bei der Implementierung. Jedes Team muss also abwägen, ob es ein schnelles “Hack & Play” (Client-Side) oder eine tiefere Integration (Server-Side) anstrebt.

Blick auf heute

Der Begriff des Client-Side-Testings ist zu einem Missverständnis geworden. Es gibt ihn noch. So ist aber die DOM-Manipulation nicht mehr dessen einvernehmlicher Inhaber, sondern nur noch Teilhaber, wie wir später herausfinden. Auf der anderen Seite kann die Manipulation des DOMs genauso unter den Begriff des Server-Side Testings fallen, wenn sie backend-seitig ihre Anwendung findet. CST und SST sind in ihrem alten Kontext nicht mehr zeitgemäß und  daher eher neu zu betrachten. Durch ihre Anwendungen in nun neuen Architekturen vergrößerte sich auch deren Aufgabengebiet. Der Begriff entfremdete sich und wurde umgangssprachlich verwischt. Ihre Begriffe dienen nun oft nur noch als grobe Schablone, unter der sich nun auch diverse andere Möglichkeiten unterordnen. Es geht nicht mehr darum, wo die Entscheidung des Tools fällt, sondern darum, wo die Entscheidung tatsächlich umgesetzt wird, welche als Kriterium bei SSR-Umgebungen eine relevante Rolle spielt.

Zu diesem Beitrag wird es einen Folgebeitrag geben (Testing  in einer SSR-Architektur – weitere Ansätze), in dem wir uns zwei weitere Ansätze anschauen, bei denen die Entscheidung im nativen Umfeld umgesetzt werden – und wie sie sich auf mitunter Performance und DevOps-Prozesse auswirken.

Bleib also dran, wenn du mehr darüber erfahren möchtest, wie man SSR und Testing optimal kombiniert und dabei auch komplexe Use Cases und ohne Limits bei der Machbarkeit abdecken kann.