Ein Social-Proof-Widget verdient seinen Platz nur, wenn es die Seite, der es helfen soll, nicht ausbremst. Das Skript von Provedly ist gzip-komprimiert etwa 6 KB groß, lädt asynchron, rendert in einem Shadow DOM außerhalb deines Layouts und wartet, bevor es etwas zeichnet. Dieser Beitrag zeigt genau, was beim Laden passiert, was das für die Core Web Vitals bedeutet und welche wenigen Entscheidungen auf deiner Seite die Performance beeinflussen.
Was lädt und wann
<script
src="https://provedly.app/w/widget.js"
data-token="pp_…"
async
defer
></script>
- Der Browser holt
widget.js, ohne das Parsen des HTML zu blockieren, dankasyncunddefer. - Der Loader fragt
GET /api/w/{token}/configan, das in einer Antwort die Einstellungen und bis zu 30 aktuelle Einträge zurückgibt. - Nach deiner Startverzögerung (standardmäßig 3 Sekunden) rendert der erste Toast. Jedes Rendern sendet eine Impression an
/track. - Solange der Tab offen ist, ruft ein Heartbeat alle 30 Sekunden
/presencefür den Live-Zähler auf.
Das ist der komplette Netzwerk-Fußabdruck: ein Skript, eine Config-Anfrage, eine kleine Anfrage pro angezeigter Benachrichtigung und ein Heartbeat alle 30 Sekunden. Es werden keine Schriften geladen, keine Bilder, außer du nutzt Bild-Avatare, und aus dem Widget heraus gibt es keine Aufrufe an Dritte.
Core Web Vitals, eine nach der anderen
Largest Contentful Paint. Das Skript blockiert weder Parsen noch Rendern, und nichts, was es zeichnet, kommt als LCP in Frage; ein Toast erscheint nach deinem Hauptinhalt und ist klein. In der Praxis hat ein korrekt installiertes Widget keinen messbaren Effekt auf den LCP. Setzt du den Tag ohne async defer in den <head>, gilt das nicht mehr, also lass das.
Cumulative Layout Shift. Toast, Zähler und Leiste sind position: fixed innerhalb einer Shadow Root. Fixierte Elemente nehmen im Dokumentfluss keinen Platz ein, ihr Erscheinen verschiebt also nichts. Der Beitrag zum CLS ist konstruktionsbedingt null. Die Ausnahme ist eine Leiste in der Position „inline“, die du bewusst in den Fluss setzt; reserviere ihre Höhe, wenn du das nutzt.
Interaction to Next Paint. Die Arbeit des Widgets im Main Thread ist gering: ein 6-KB-Skript parsen, ein paar DOM-Knoten rendern und ein Timer. Es hängt keine Scroll- oder Pointer-Listener an dein Dokument. Der INP bleibt unberührt, es sei denn, deine Seite ist ohnehin schon am Limit.
| Metrik | Effekt eines korrekt installierten Widgets |
|---|---|
| LCP | Keiner; asynchron, nach dem Hauptinhalt |
| CLS | Keiner; fixierte Position, außerhalb des Flusses |
| INP | Vernachlässigbar; keine dokumentweiten Listener |
| Gesamte Übertragung | Etwa 6 KB gzip plus Config-JSON |
Wozu die Verzögerung von 3 Sekunden dient
Die Standard-Startverzögerung ist für den Besucher da, nicht für die Performance, aber sie hilft beidem. Bis der erste Toast erscheint, ist die Seite meist fertig geladen, Bilder sind da und der Besucher hat sich orientiert. Eine Benachrichtigung, die aufpoppt, bevor das Hero-Bild gezeichnet ist, nervt und konkurriert bei langsamen Verbindungen um Bandbreite. Lass die Verzögerung bei 3 Sekunden oder mehr; eine Verkürzung bringt nichts.
Entscheidungen auf deiner Seite, die zählen
Wo der Tag hinkommt. Ans Ende von <body> mit async defer oder next/script mit strategy="afterInteractive". Nicht synchron in den <head>.
Direkter Tag oder Tag Manager. GTM fügt das Laden des Containers und die Auswertung der Trigger hinzu, bevor das Widget-Skript überhaupt angefragt wird. Auf einer langsamen Seite verschiebt das den ersten Toast weiter nach hinten als gewollt. Siehe Installation über den Google Tag Manager, und wann nicht.
Bild-Avatare. Sendest du avatar_url bei Einträgen, lädt jeder Toast unter Umständen ein Bild. Halte sie klein oder nutze einen Avatar-Stil ohne Bild; Webhook-Einträge von Stripe und Shopify enthalten ohnehin keine Fotos.
Anzahl der Widgets. Ein Widget pro Seite deckt Toasts und den Live-Zähler ab. Eine Leiste ist ein zweiter Loader. Installiere denselben Token nicht zweimal; der Loader ist idempotent, aber doppelte Tags kosten trotzdem eine Anfrage.
Countdown-GIFs für E-Mails. Das ist ein anderes Produkt: ein serverseitig gerendertes animiertes GIF für E-Mails, bis zu 3 Minuten lang und unter 100 KB. Es beeinflusst die Performance deiner Website überhaupt nicht, aber denk daran, dass E-Mail-Clients es beim Öffnen laden.
Selbst messen
Lass Lighthouse oder WebPageTest zweimal über eine Seite laufen, mit und ohne Tag, und vergleiche. Rechne damit, dass der Unterschied im normalen Rauschen zwischen zwei Durchläufen liegt. Siehst du eine echte Verschlechterung, prüf auf eine synchrone Platzierung des Tags, einen doppelten Tag oder eine CSP, die Wiederholungen auslöst. Das Dashboard meldet keine Performance-Zahlen; dein eigenes Tooling ist hier die Wahrheit, und das Widget ist so gebaut, dass es darin nicht auffällt.
Warum Größe wichtiger ist, als es scheint
Mehrere Social-Proof-Tools bündeln, Stand Oktober 2026 und laut ihren Listings, A/B-Test-Engines, visuelle Editoren, Analytics-Schichten und mehrere Benachrichtigungstypen in einem Client-Skript. Jede Funktion ist ein Grund, warum das Bundle wächst. Das Widget von Provedly tut auf der Seite eine Sache: Config holen, echte Einträge mit ihren Labels zeigen, Anwesenheit ehrlich zählen. Alles andere, einschließlich der Verifizierungsseite und der Attributionszuordnung für durch Proof unterstützte Bestellungen, passiert auf dem Server. Den Client klein zu halten ist ebenso eine Produktentscheidung wie eine technische.
Häufige Fragen
Leert der Heartbeat alle 30 Sekunden den Akku oder das Datenvolumen?
Ein Heartbeat ist eine winzige Anfrage alle 30 Sekunden, solange der Tab offen ist. Das liegt weit unter dem, was jedes Analytics-Skript oder Chat-Widget tut, und er stoppt, wenn der Tab geschlossen wird.
Kann ich das Widget erst laden, wenn der Besucher scrollt?
Die Startverzögerung deckt den üblichen Fall bereits ab. Brauchst du scrollgesteuertes Laden, füge den Tag aus deinem eigenen Scroll-Handler mit demselben src und data-token ein; der Loader funktioniert genauso.
Ist das Shopify-App-Embed schwerer als der Script-Tag?
Nein. Das App-Embed lädt denselben Renderer mit derselben Isolation und hat den Vorteil, dass Bestellungen ohne zusätzlichen Client-Code verifiziert ankommen.
Installiere es, mach deinen Geschwindigkeitstest und behalte, was immer dabei herauskommt: kostenlos starten.