Jedes Widget von Drittanbietern bringt dasselbe Risiko mit: Sein CSS sickert in deine Seite, oder dein CSS sickert ins Widget, und jemand verbringt einen Nachmittag mit den Devtools. Provedly rendert in einem Shadow DOM. Das heißt, der Browser selbst zieht eine Grenze, die normale CSS-Selektoren in keiner Richtung überschreiten können. Dieser Beitrag erklärt, was diese Grenze leistet, wovor sie dich schützt und welche wenigen Dinge sie bewusst nicht isoliert.
Was Shadow DOM ist
Shadow DOM ist ein Browser-Standard, mit dem ein Script einen separaten, gekapselten DOM-Baum an ein Element hängen kann. Styles, die im Shadow-Baum definiert sind, gelten nur dort; Styles der Seite reichen nicht hinein. Auf diesem Mechanismus beruhen native Elemente wie die Steuerelemente von <video>, und er ist in jedem aktuellen Browser verfügbar.
Wenn der Provedly-Loader läuft, erzeugt er ein Host-Element, hängt einen Shadow Root an und rendert den Toast, Zähler oder die Leiste in diesem Root mit einem eigenen Stylesheet. Aus Sicht deiner Seite gibt es am Ende von <body> ein scheinbar leeres Element.
<!-- what your page sees -->
<provedly-widget></provedly-widget>
#shadow-root
<style>
…widget styles…
</style>
<div class="toast">…</div>
Wovor es dich schützt
Deine Resets machen das Widget nicht platt. Ein globales * { box-sizing: border-box; margin: 0 } oder ein Tailwind-Preflight greift im Shadow Root nicht. Der Toast sieht auf einer Website mit aggressiven Resets genauso aus wie auf einer ohne.
Die Klassen des Widgets kollidieren nicht mit deinen. Das Widget kann eine Klasse namens .toast oder .badge verwenden, und sie trifft nie ein Element deiner Seite, genauso wie deine .badge-Regel nie das Widget trifft.
Deine !important-Regeln bleiben deine. Ein Theme, das p { font-size: 18px !important } deklariert, würde normalerweise jeden Absatz im Widget überschreiben. Innerhalb eines Shadow Root ist die Regel schlicht nicht gültig.
Framework-CSS bleibt, wo es ist. CSS Modules, styled-components, Scoped Styles in Vue oder Svelte: Keines davon wirkt sich auf das Widget aus, und das Widget nicht auf sie. Deshalb ist die Installation auf Next.js, Webflow, WordPress und Shopify dasselbe eine Script-Tag; es gibt keine Stylesheet-Arbeit pro Plattform. Siehe Social Proof in einer Next.js-App einbauen.
Schriften bleiben berechenbar. Das eigene Stylesheet des Widgets steuert die Typografie, sodass eine Display-Schrift auf deinem body aus einer Benachrichtigung keine Überschrift macht.
Was bewusst nicht isoliert wird
Shadow DOM kapselt Styles. Es kapselt nicht den Viewport, den Stacking-Kontext oder die Interaktion, und an ein paar Stellen teilen sich deine Seite und das Widget weiterhin den Raum.
| Gemeinsam genutzt | Warum es wichtig ist | Was du tun kannst |
|---|---|---|
| Position im Viewport | Der Toast ist position: fixed und konkurriert mit deinen anderen fixierten Elementen |
Eine freie Ecke wählen; Geräte-Targeting nutzen, wenn es auf Mobilgeräten eng wird |
| Stapelreihenfolge | Das Host-Element hat einen z-index; ein Seitenelement mit höherem Wert kann es verdecken | Selten; meist ein Vollbild-Overlay, das es ohnehin verdecken sollte |
body { overflow: hidden } |
Betrifft das Widget nicht, aber deine eigenen Modals erwarten vielleicht eine leere Ecke | Nichts, außer du willst den Toast bei Modals ausblenden; URL-Targeting für eigene Routen nutzen |
| Vererbte CSS Custom Properties | Custom Properties überschreiten die Shadow-Grenze absichtlich | Das Widget verlässt sich nicht auf Seitenvariablen, daher hat das keinen sichtbaren Effekt |
| Pointer-Events | Ein Klick auf das Badge öffnet die Verifizierungsseite, wie jeder Link | Nichts |
Die einzige praktische Kollision sind andere fixierte Elemente: Chat-Launcher, Cookie-Banner, sticky In-den-Warenkorb-Buttons. Shadow DOM kann nicht zwei Dinge in dieselbe Ecke setzen. Wähle die Positionen so, dass das nicht passiert.
Das Widget gestalten
Weil du von deinem Stylesheet aus nicht in den Shadow Root greifen kannst, liegen die Design-Einstellungen im Dashboard: fünf Themes (Clean white, Deep ocean, Midnight, Electric violet, Sunset blaze), Position, Avatar-Stil, Formate für Name und Ort und bei Leisten Layout, Ziffernstil, Schriftgröße, maximale Breite und Button-Farben. Das ist Einschränkung und Feature zugleich. Es garantiert, dass die Vorschau im Dashboard genau das ist, was Besucher sehen, auf jeder Website und unabhängig von deren CSS. Siehe Ein Toast-Theme wählen, das zu deiner Marke passt.
Wenn du etwas brauchst, das die Einstellungen nicht bieten, ist die Lösung nicht, den Shadow Root mit ::part oder per JavaScript über shadowRoot aufzubrechen. Solche Ansätze gehen mit dem nächsten Widget-Release kaputt.
Auswirkungen auf die Performance
Der Shadow Root wird einmal pro Seitenaufruf erzeugt. Die Styles darin werden einmal geparst und lösen keine Neuberechnung der Styles deiner Seite aus, weil der Browser beide Bäume für die Kaskade getrennt behandelt. Das Bundle des Widgets ist etwa 6 KB gzipped groß, lädt async defer und rendert fixierte Elemente, die nicht an deinem Layout teilnehmen, also gibt es keinen Layout-Shift zu messen. Mehr dazu in Ladezeit und Social-Proof-Scripts.
Debugging
In den Devtools erscheint das Widget als Host-Element mit einem Kind #shadow-root (open). Klapp es auf, um den Toast wie jedes andere Element zu inspizieren. Aktuelle Versionen von Chrome und Firefox zeigen Shadow-Bäume standardmäßig an; wenn dein Browser sie ausblendet, such in den Devtools-Einstellungen nach einer Option wie „show user agent shadow DOM“. Wenn der Toast gar nicht sichtbar ist, liegen die üblichen Ursachen außerhalb des Shadow Root: Die Domain steht nicht auf der Liste erlaubter Domains der Website, das Widget hat keine Datensätze, oder die Seite ist per URL-Targeting ausgeschlossen.
Häufige Fragen
Funktioniert Shadow DOM in jedem Browser, den meine Besucher nutzen?
Shadow DOM wird seit Jahren von allen Evergreen-Browsern unterstützt. Provedly unterstützt keine Browser ohne Shadow DOM.
Kann meine Content Security Policy die Inline-Styles im Shadow Root blockieren?
Ein striktes style-src ohne 'unsafe-inline' kann je nach Browser beeinflussen, wie Styles im Shadow Root angewendet werden. Wenn du eine solche Policy nutzt, teste das Widget auf Staging und schau in den Docs nach den empfohlenen CSP-Einträgen für provedly.app.
Nutzt der Live-Besucherzähler denselben Shadow Root?
Toast und Zähler desselben Widget-Tokens rendern im selben Host. Eine CTA-Leiste, die über cta.js geladen wird, hat ihren eigenen Host und ihren eigenen Shadow Root.
Sieh dir die Isolierung mit einem Script-Tag auf deiner eigenen Website an: kostenlos installieren.