Visuelles Testen mit Svelte und SvelteKit: Warum das aufstrebende Framework eine Strategie fuer visuelles Testen braucht
Kernaussagen
- Svelte kompiliert Ihre Komponenten zu Vanilla-JavaScript, was das Virtual DOM eliminiert, aber nicht die visuellen Regressionen
- SvelteKit kombiniert SSR, Pre-Rendering und clientseitige Navigation und erzeugt dieselben visuellen Herausforderungen wie andere Full-Stack-Frameworks
- Das Svelte-spezifische Oekosystem fuer visuelles Testen ist im Vergleich zu React noch unreif, was ein framework-agnostisches Tool unverzichtbar macht
- Visuelles Testen erfasst das Endergebnis im Browser, unabhaengig vom zugrunde liegenden Kompilierungsmechanismus
Visuelles Testen bezeichnet laut der Definition des ISTQB (International Software Testing Qualifications Board) „die Verifikation, dass die Benutzeroberflaeche einer Software gemaess den erwarteten visuellen Spezifikationen angezeigt wird, durch Vergleich von Referenz-Screenshots mit dem aktuellen Zustand der Anwendung" (ISTQB Glossary, Visual Testing).
Svelte ist dabei, die Karten der Frontend-Entwicklung neu zu mischen. Die State of JS Survey 2024 platziert es regelmaessig unter den am meisten geschaetzten Frameworks von Entwicklern, mit einer Zufriedenheitsrate, die seit drei aufeinanderfolgenden Jahren die von React uebertrifft. SvelteKit, sein Full-Stack-Framework, ist seit 2023 in stabiler Version und zieht immer mehr Teams an, die eine Alternative zu den Schwergewichten React und Next.js suchen.
Aber hier ist das Problem, das in Svelte-Tutorials niemand erwaehnt: Das Oekosystem der Test-Tools ist noch im Aufbau. Und visuelles Testen insbesondere ist der grosse Vergessene. Die meisten Artikel ueber das Testen einer Svelte-Anwendung konzentrieren sich auf Unit-Tests mit Vitest und Integrationstests mit Playwright. Visuelles Testen — die Verifikation, dass Ihre Oberflaeche fuer Ihre Nutzer korrekt angezeigt wird — wird als sekundaeres Anliegen behandelt.
Das ist ein Fehler. Und dieser Artikel erklaert warum.
Svelte kompiliert, aber Kompilierung schuetzt Ihre UI nicht
Das Hauptargument von Svelte ist die Kompilierung. Im Gegensatz zu React oder Vue wird Svelte nicht im Browser ueber eine Runtime ausgefuehrt. Ihr Svelte-Code wird beim Build zu Vanilla-JavaScript kompiliert. Es gibt kein Virtual DOM, kein algorithmisches Diffing, keine Framework-Runtime, die sich zwischen Ihren Code und das reale DOM stellt.
Dieser Ansatz hat unbestreitbare Vorteile in Bezug auf Performance. Die Bundles sind kleiner. Die Ausfuehrungszeit ist schneller. Die Interaktion ist fluessiger. Rich Harris, der Schoepfer von Svelte, hat diese Vorteile in seinen Konferenzen ueberzeugend demonstriert, und die Benchmarks bestaetigen: Svelte produziert leichteren und performanteren Code als React in der Mehrheit der Szenarien.
Aber Kompilierung loest keine visuellen Probleme. CSS ist immer noch CSS. Flexbox- und Grid-Layouts koennen immer noch auf subtile Weise brechen. Media Queries koennen immer noch unerwartete Ergebnisse an bestimmten Breakpoints liefern. Web Fonts koennen immer noch verspaetet laden und einen Text-Reflow verursachen. Bilder koennen immer noch ihre Groesse aendern und den umgebenden Inhalt verschieben.
Die Tatsache, dass Svelte Ihre Komponenten zu optimiertem JavaScript kompiliert, aendert nichts am endgueltigen visuellen Ergebnis. Dieses Ergebnis haengt vom CSS, dem generierten HTML, den geladenen Ressourcen und deren Interaktion im Browser ab. Und diese Interaktion kann visuelle Regressionen erzeugen, die nur ein Bildvergleich erkennen kann.
Anders ausgedrueckt: Svelte loest das Performance-Problem zur Laufzeit. Es loest nicht das Problem der visuellen Verifikation. Das sind zwei verschiedene Probleme, und sie erfordern zwei verschiedene Loesungen.
SvelteKit: Die Full-Stack-Komplexitaet tritt hinzu
Wenn Svelte ein Komponentencompiler ist, ist SvelteKit ein vollwertiges Full-Stack-Framework. Und wie jedes moderne Full-Stack-Framework fuehrt es eine Rendering-Komplexitaet ein, die den Bedarf an visuellem Testen verstaerkt.
Das hybride Rendering von SvelteKit
SvelteKit unterstuetzt mehrere Rendering-Strategien. Pre-Rendering generiert HTML zum Build-Zeitpunkt, wie eine statische Website. Server-Side Rendering (SSR) generiert HTML bei jeder Anfrage. Clientseitige Navigation (CSR) uebernimmt nach dem initialen Laden die Navigation zwischen Seiten ohne vollstaendiges Neuladen.
Jeder dieser Modi kann ein subtil unterschiedliches visuelles Ergebnis liefern. Pre-gerendertes HTML kann zum Build-Zeitpunkt eingefrorene Daten verwenden. Server-gerendertes HTML verwendet die aktuellen Daten. Und die clientseitige Navigation kann visuelle Transitionen ausloesen — Skeleton-Loader, Fade-Effekte, Ladezustaende — die beim ersten Laden nicht existieren.
SvelteKit erlaubt sogar das Mischen dieser Modi innerhalb derselben Anwendung. Einige Seiten sind pre-gerendert, andere in SSR, weitere deaktivieren SSR fuer vollstaendiges clientseitiges Rendering. Diese Flexibilitaet ist wertvoll fuer die Architektur, aber sie vervielfacht die Rendering-Pfade, die Sie visuell ueberpruefen muessen.
Das Hydratationsproblem bei Svelte
Svelte erfordert wie React einen Hydratationsschritt fuer serverseitig gerenderte Seiten. Das HTML wird auf dem Server generiert, an den Browser gesendet, dann „reaktiviert" Svelte die Komponenten clientseitig, um sie interaktiv zu machen.
Theoretisch sollte das HTML vor und nach der Hydratation visuell identisch sein. In der Praxis existieren Abweichungen. Komponenten, die vom Browser-Kontext abhaengen (Bildschirmgroesse, Systempraeferenzen wie Dark Mode, Scroll-Zustand) zeigen nach der Hydratation unterschiedliche Inhalte an. Dynamisch berechnete Inline-Styles sind nicht immer dieselben auf Server- und Clientseite. Animationen, die bei der Hydratation starten, verursachen eine visuelle Aenderung im Moment, in dem der Nutzer die Seite sieht.
Svelte 5 verbessert mit seinem Runes-System und seiner feingranularen Reaktivitaet die Hydratations-Performance. Aber es beseitigt nicht das grundsaetzliche Problem: Server und Client sind zwei verschiedene Umgebungen und koennen visuell unterschiedliche Renderings erzeugen.
Native Transitionen und Animationen
Svelte integriert ein Transitions- und Animationssystem direkt in die Sprache. Direktiven wie transition:fade, animate:flip oder in:fly ermoeglichen visuelle Effekte mit einer eleganten deklarativen Syntax.
Diese Transitionen sind ein Gewinn fuer die Nutzererfahrung, aber eine Herausforderung fuer visuelles Testen. Ein Screenshot, der mitten in einer Transition aufgenommen wird, spiegelt weder den Anfangs- noch den Endzustand wider. Und die Transitionsdauer kann je nach Browser- und Maschinenperformance variieren.
Visuelles Testen muss mit diesem Nicht-Determinismus umgehen. Die Loesung besteht darin, Seiten in einem stabilen Zustand zu erfassen — nach dem Ende aller Transitionen — oder Transitionen in der Testumgebung zu deaktivieren. Dazu kommen wir noch.
Das Svelte-Test-Oekosystem: Ein Terrain noch im Aufbau
Seien wir offen: Das Svelte-spezifische Test-Oekosystem hinkt dem von React hinterher. Das ist keine Kritik — es ist die Realitaet eines juengeren Frameworks mit einer kleineren Community.
Was es gibt
Fuer Unit-Tests ist Vitest mit Testing Library Svelte die Standardkombination. Sie funktioniert gut fuer die Verifikation des Verhaltens Ihrer Komponenten: Loest dieser Button die richtige Aktion aus, validiert dieses Formular die richtigen Daten.
Fuer Integrations- und End-to-End-Tests ist Playwright die von der offiziellen SvelteKit-Dokumentation empfohlene Wahl. Es navigiert in einem echten Browser, interagiert mit Ihrer Anwendung und ueberprueft, ob funktionale Ablaeufe von Anfang bis Ende funktionieren.
Fuer isoliertes Komponententesten unterstuetzt Storybook Svelte, aber die Unterstuetzung ist weniger ausgereift als fuer React. Dekoratoren, Add-ons und Drittanbieter-Integrationen sind weniger zahlreich. Und vor allem profitiert Storybook fuer Svelte nicht vom reichen Oekosystem fuer visuelles Testen, das fuer React ueber Chromatic existiert.
Was fehlt
Was im Svelte-Oekosystem schmerzlich fehlt, ist ein integriertes und zugaengliches Tool fuer visuelles Testen. Es gibt kein Aequivalent zu Chromatic, das speziell fuer Svelte entwickelt wurde. Die existierenden Loesungen sind entweder generisch (Playwright mit Screenshot-Vergleich) oder an das React-Oekosystem gebunden (Chromatic ueber Storybook, Percy).
Diese Luecke ist paradox. Svelte produziert Oberflaechen mit fluessigen Animationen, eleganten Transitionen und ausgefeilten Layouts — genau die Art von UI, bei der visuelle Regressionen am wahrscheinlichsten und am schwierigsten manuell zu erkennen sind. Aber die Tools zur automatischen Erkennung dieser Regressionen sind seltener als fuer React.
Genau diese Luecke macht ein framework-agnostisches Tool fuer visuelles Testen nicht nur nuetzlich, sondern unverzichtbar fuer Svelte-Teams.
Warum framework-agnostisches visuelles Testen der richtige Ansatz fuer Svelte ist
Framework-agnostisches visuelles Testen funktioniert, indem Screenshots Ihrer Seiten in einem echten Browser erfasst und zwischen Versionen verglichen werden. Es kuemmert sich nicht darum, ob Ihre Anwendung mit Svelte, React, Vue oder sogar statischem HTML erstellt wurde. Es ueberprueft das Endergebnis — das, was der Nutzer sieht.
Fuer Svelte hat dieser Ansatz drei entscheidende Vorteile.
Unabhaengigkeit vom unreifen Oekosystem
Sie muessen nicht darauf warten, dass ein Svelte-spezifisches Tool fuer visuelles Testen die Reife von Chromatic erreicht. Sie muessen nicht von einer Storybook-Unterstuetzung abhaengen, die noch nicht auf dem Niveau von React ist. Sie verwenden ein Tool, das mit dem Ergebnis Ihres Builds arbeitet, nicht mit den internen Mechanismen Ihres Frameworks.
Wenn Svelte 6 die Kompilierungsarchitektur radikal aendert (wie Svelte 5 es mit den Runes getan hat), bleibt Ihre visuelle Teststrategie intakt. Der Compiler aendert sich, das Ergebnis im Browser wird auf dieselbe Weise ueberprueft.
Abdeckung vollstaendiger Seiten
Isoliertes Testen von Komponenten in Storybook bedeutet, die Puzzleteile zu ueberpruefen. Vollstaendige Seiten zu testen bedeutet, zu ueberpruefen, dass das zusammengesetzte Puzzle das erwartete Bild ergibt. Fuer eine SvelteKit-Anwendung mit verschachtelten Layouts, dynamischen Slots und geteilten Komponenten ist die zusammengesetzte Seite das, was zaehlt.
Eine Header-Komponente, die in Storybook perfekt funktioniert, kann den Hauptinhalt ueberlagern, wenn sie mit einem bestimmten Layout und einem bestimmten Inhaltsvolumen verwendet wird. Eine Sidebar-Komponente, die isoliert gut aussieht, kann einen unerwuenschten horizontalen Scroll erzeugen, wenn sie mit einem MainContent kombiniert wird, der breite Bilder enthaelt. Nur der Test der vollstaendigen Seite enthuellt diese Interaktionen.
Operationelle Einfachheit
Keine Stories zu schreiben. Keine Playwright-Skripte zu pflegen. Keine framework-spezifische Konfiguration. Sie konfigurieren die URLs Ihrer Anwendung, die zu erfassenden Viewports, und visuelles Testen wird automatisch in Ihrer CI/CD-Pipeline ausgefuehrt.
Fuer ein Team, das Svelte wegen seiner Einfachheit und seines „weniger Boilerplate"-Ansatzes gewaehlt hat, ist diese operationelle Einfachheit konsistent mit der Philosophie des Frameworks.
Delta-QA: Visuelles Testen fuer Svelte-Teams entwickelt
Delta-QA ist ein No-Code-Tool fuer visuelles Testen, das Ihre realen Seiten in einem echten Browser erfasst und visuelle Regressionen zwischen Versionen erkennt. Es funktioniert unabhaengig von Ihrem Framework, was es zu einer sofort einsatzbereiten Loesung fuer Svelte- und SvelteKit-Anwendungen macht.
Wie Delta-QA mit SvelteKit funktioniert
Die Funktionsweise ist direkt. Sie deployen Ihre SvelteKit-Anwendung in einer Preview-Umgebung — ob auf Vercel, Netlify, Cloudflare Pages oder Ihrem eigenen Server. Delta-QA erfasst Screenshots Ihrer Seiten in dieser Umgebung und vergleicht sie mit den Baselines Ihrer Produktionsversion.
Delta-QA wartet auf das vollstaendige Laden der Seite, bevor es erfasst: Das HTML ist gerendert, das CSS angewendet, die Fonts geladen, die Hydratation abgeschlossen. Was Delta-QA erfasst, ist genau das, was Ihr Nutzer sehen wird.
Die visuellen Unterschiede werden in einer Review-Oberflaeche praesentiert, in der Sie beabsichtigte Aenderungen genehmigen und Regressionen melden koennen. Keine False Positives durch Runtime-Unterschiede zwischen Storybook und Ihrer realen Anwendung, weil Sie die reale Anwendung testen.
Svelte-Spezifika verwalten
Die nativen Transitionen von Svelte sind elegant, muessen aber fuer visuelles Testen stabilisiert werden. Delta-QA ermoeglicht das Deaktivieren von CSS-Animationen bei der Erfassung, was garantiert, dass Ihre Screenshots den endgueltigen stabilen Zustand jeder Seite zeigen.
Das Pre-Rendering von SvelteKit generiert perfekt vorhersagbare statische Seiten — das ist das ideale Szenario fuer visuelles Testen. SSR-Seiten erfordern eine Stabilisierung dynamischer Daten, die Delta-QA ueber konfigurierbare Ausschlusszonen verwaltet.
Die Layouts von SvelteKit teilen visuelle Elemente (Header, Sidebar, Footer) zwischen mehreren Seiten. Eine Aenderung in einem geteilten Layout betrifft potenziell Dutzende von Seiten. Delta-QA erkennt diese Auswirkung automatisch, indem es alle betroffenen Seiten erfasst und zeigt, welche von der Aenderung betroffen sind.
Die visuellen Fallen, die Sie bei Svelte ueberwachen muessen
Svelte hat einzigartige Eigenschaften, die spezifische visuelle Risiken erzeugen.
Scoped CSS und seine Seiteneffekte
Svelte scoped automatisch das CSS jeder Komponente, indem beim Build eine eindeutige Klasse hinzugefuegt wird. Das verhindert Stilkonflikte zwischen Komponenten — in der Theorie. In der Praxis koennen globale Styles, zu generische Selektoren im globalen Scope und CSS-Vererbung immer noch unerwartete visuelle Effekte verursachen.
Die klassische Falle: Sie aendern einen globalen Style (eine CSS-Variable, einen Reset, eine Font-Face) und realisieren nicht, dass diese Aenderung Komponenten betrifft, die durch das Scoping geschuetzt schienen. Visuelles Testen auf vollstaendigen Seiten enthuellt diese Seiteneffekte sofort.
Stores und Reaktivitaet
Svelte Stores ermoeglichen geteilten State zwischen Komponenten. Wenn sich ein Store aendert, aktualisieren sich alle abonnierten Komponenten. Wenn dieses Update eine Layout-Aenderung ausloest — eine Komponente, die erscheint oder verschwindet, ein Inhalt, der seine Groesse aendert — ist das eine potenzielle Quelle visueller Regression.
Visuelles Testen muss Seiten in einem deterministischen Store-Zustand erfassen. Wenn Ihre Anwendung unterschiedliche Inhalte anzeigt, je nachdem ob der Nutzer angemeldet ist oder nicht, muessen Sie beide Zustaende erfassen. Delta-QA ermoeglicht die Konfiguration mehrerer Szenarien pro Seite, jedes mit seinem eigenen Anfangszustand.
Actions und Custom Events
Svelte Actions (use:action) ermoeglichen das Anhaengen wiederverwendbaren Verhaltens an DOM-Elemente. Einige Actions aendern den Style oder die Position von Elementen — eine tooltip-Action beispielsweise fuegt ein absolut positioniertes Element beim Hover hinzu. Diese Aenderungen sind nur in bestimmten Seitenzustaenden sichtbar.
Visuelles Testen muss diese interaktiven Zustaende fuer kritische Interaktionen abdecken. Delta-QA ermoeglicht die Definition von Szenarien, die Interaktionen (Klick, Hover) vor der Erfassung ausloesen, was die Ueberpruefung des Erscheinungsbilds Ihrer Tooltips, Dropdown-Menues und anderer interaktiver Elemente ermoeglicht.
Visuelles Testen in Ihre SvelteKit-Pipeline integrieren
Der empfohlene Workflow
Fuer eine SvelteKit-Anwendung folgt der optimale Workflow fuer visuelles Testen diesem Pfad. Sie pushen Ihren Code auf einen Branch. Ihre CI baut die SvelteKit-Anwendung. Die Anwendung wird in einer Preview-Umgebung deployed. Delta-QA erfasst Screenshots der Preview-Umgebung. Die Ergebnisse werden in Ihren Merge Request integriert. Ihr Team reviewt die visuellen Unterschiede.
Dieser Workflow funktioniert unabhaengig von Ihrem Hosting-Anbieter. SvelteKit unterstuetzt Deployment auf Vercel, Netlify, Cloudflare Pages oder ueber einen Node.js-Adapter auf jedem Server. Delta-QA passt sich jeder Konfiguration an.
Die anzustrebende Abdeckung
Fuer eine mittelgrosse SvelteKit-Anwendung (20 bis 50 Seiten) streben Sie folgende Abdeckung an. Erfassen Sie alle oeffentlichen Seiten in mindestens drei Viewports: Mobil (375px), Tablet (768px) und Desktop (1440px). Fuegen Sie die kritischen Zustaende Ihrer dynamischen Seiten hinzu: Seite mit geladenem Inhalt, Seite mit leerem Zustand, Seite mit Fehlerzustand. Decken Sie geteilte Layouts ab, indem Sie mindestens eine Seite pro Layout testen.
Mit Delta-QA laesst sich diese Abdeckung in wenigen Minuten Konfiguration einrichten. Es gibt keine Skripte zu schreiben, keine Stories zu synchronisieren, keine CSS-Selektoren zu pflegen.
FAQ
Ist visuelles Testen wirklich noetig fuer Svelte, wenn CSS pro Komponente gescoped ist?
Ja, absolut. Das CSS-Scoping von Svelte verhindert Klassennamenskonflikte zwischen Komponenten, aber es schuetzt nicht vor allen visuellen Problemen. Globale Styles, CSS-Vererbung, berechnete Eigenschaften, Media Queries und vor allem die Interaktion zwischen Komponenten auf einer realen Seite koennen visuelle Regressionen erzeugen, die das Scoping nicht verhindert. Visuelles Testen ueberprueft das zusammengesetzte Endergebnis, nicht die einzelnen Komponenten.
Funktioniert Delta-QA mit SvelteKit-Adaptern (Node, Vercel, Netlify, Static)?
Ja. Delta-QA erfasst Screenshots Ihrer Seiten in einem Browser, unabhaengig davon, wie sie ausgeliefert werden. Ob Ihre SvelteKit-Anwendung ueber den Node.js-Adapter auf einem VPS, ueber den Vercel-Adapter auf der Vercel-Plattform oder als pre-gerenderte statische Dateien auf Netlify deployed ist — Delta-QA greift auf die URLs Ihrer Anwendung zu und erfasst, was der Browser anzeigt. Der Adapter ist transparent fuer visuelles Testen.
Wie verwaltet man Svelte-Transitionen in visuellen Tests?
Svelte-Transitionen (transition:fade, in:fly usw.) muessen stabilisiert werden, um deterministische Erfassungen zu erhalten. Delta-QA deaktiviert CSS-Animationen bei der Erfassung, indem ein Stylesheet injiziert wird, das alle Transitions- und Animationsdauern auf null setzt. Fuer JavaScript-Transitionen koennen Sie eine Umgebungsvariable verwenden, die Ihre Anwendung erkennt, um Animationen im visuellen Testkontext zu umgehen.
Aendert Svelte 5 mit den Runes etwas am visuellen Testen?
Nein, und genau das ist der Vorteil eines framework-agnostischen visuellen Testens. Svelte 5 ersetzt reaktive Deklarationen ($:) durch Runes ($state, $derived, $effect), was das interne Reaktivitaetsmodell grundlegend aendert. Aber das Ergebnis im Browser bleibt HTML, CSS und JavaScript — und dieses Ergebnis erfasst visuelles Testen. Ob Sie von Svelte 4 zu Svelte 5 migrieren oder bei Svelte 4 bleiben, Ihre Strategie fuer visuelles Testen mit Delta-QA aendert sich nicht.
Was ist der Unterschied zwischen dem Testen meiner Svelte-Komponenten in Storybook und dem Testen meiner Seiten mit Delta-QA?
Der Unterschied ist fundamental. Storybook testet Ihre Komponenten isoliert, in einer kuenstlichen Umgebung, mit Daten, die Sie ihm manuell ueber Stories liefern. Delta-QA testet Ihre zusammengesetzten Seiten, in einem echten Browser, mit dem realen Rendering Ihrer SvelteKit-Anwendung (SSR, Hydratation, reale Daten). Die gefaehrlichsten visuellen Regressionen entstehen durch die Interaktion zwischen Komponenten im Kontext einer vollstaendigen Seite — genau das, was Storybook nicht testen kann und was Delta-QA natuerlich erfasst.
Wie lange dauert die Einrichtung von visuellem Testen in einem bestehenden SvelteKit-Projekt?
Mit Delta-QA rechnen Sie mit weniger als dreissig Minuten fuer eine einsatzbereite Einrichtung. Sie konfigurieren die URLs Ihrer Anwendung, definieren die zu erfassenden Viewports und starten eine erste Referenzerfassung. Es gibt keine Skripte zu schreiben, keine Abhaengigkeiten in Ihrem Projekt zu installieren, keine Storybook-Stories zu erstellen. Wenn Ihre SvelteKit-Anwendung bereits in einer Preview-Umgebung deployed ist, ist die Konfiguration noch schneller.
Fazit: Svelte verdient visuelles Testen auf der Hoehe seiner Ambitionen
Svelte ist ein ambitioniertes Framework, das die Grundlagen der Frontend-Entwicklung neu denkt. Seine Kompilierung, seine native Reaktivitaet, seine integrierten Transitionen und die Leistungsfaehigkeit von SvelteKit machen es zu einer immer populaereren Wahl fuer Teams, die performante und elegante Oberflaechen bauen wollen.
Aber diese visuelle Eleganz muss geschuetzt werden. Die anspruchsvollen Oberflaechen, die Svelte zu erstellen ermoeglicht, sind genau diejenigen, die am anfaelligsten fuer subtile visuelle Regressionen sind. Und das Svelte-spezifische Tool-Oekosystem ist noch nicht reif genug, um diesen Bedarf zu decken.
Ein framework-agnostisches Tool fuer visuelles Testen wie Delta-QA fuellt diese Luecke. Es ueberprueft, was wirklich zaehlt — das Endergebnis im Browser — ohne vom Zustand des Svelte-Tool-Oekosystems abzuhaengen. Es funktioniert heute, mit Svelte 4 oder 5, SvelteKit, jedem Adapter und jedem Hosting-Anbieter.
Wenn Sie Svelte gewaehlt haben, um Oberflaechen von Qualitaet zu bauen, waere es paradox, diese Qualitaet nicht visuell zu ueberpruefen. Visuelles Testen ist nicht optional — es ist die Garantie, dass die Qualitaet, die Sie in Ihren Code gesteckt haben, sich in dem widerspiegelt, was Ihre Nutzer sehen.