Chat-Widget mit perfekten Core Web Vitals

Wie man ein Chat-Widget richtig lädt

Ich habe es immer und immer wieder gesagt. Manche Skripte sind wichtiger als andere. Niemand in der Geschichte des Internets war jemals genervt, dass ein Chat-Widget nicht in den ersten 500ms des Seitenladens geladen wurde. In der Zeit, in der die Seite noch leer ist.

Es wäre doch unsinnig, ein Chat-Widget zu laden, bevor der Hauptinhalt der Seite überhaupt begonnen hat zu laden? Nein, es wäre viel sinnvoller, zuerst die wichtigsten Elemente zu laden (euer Logo, euer Hauptbild, eure Stylesheets, eure Schriften, vielleicht einige besonders wichtige Skripte, die Navigation und Conversion steuern).

Studien zeigen, dass nur 3 bis 10 Prozent der Besucher ein Chat-Widget während ihrer Sitzung tatsächlich nutzen. Das Verzögern des Chat-Skripts kostet euch nichts in Bezug auf die user experience, bringt euch aber alles in Bezug auf die Seitengeschwindigkeit.

Leider machen die meisten Websites es nicht so. Täglich sehe ich unwichtige Skripte (wie Chat-Skripte), die mit höchster Priorität sofort beim Seitenladen gestartet werden.

In diesem Artikel erkläre ich, wie man ein Chat-Skript korrekt lädt und wie sich das auf wichtige Metriken wie den Largest Contentful Paint und die Interaction to Next Paint auswirkt.

Zuletzt überprüft von Arjen Karel im Februar 2026

Hintergrund: Wie funktionieren Chat-Widgets?

Ein Chat-Widget funktioniert normalerweise, indem ein kleines Skript auf eurer Seite geladen wird. Dieses Skript lädt einige Styles und fügt einen iframe in eure Seite ein. Ein iframe ist eine kleine isolierte Webseite innerhalb einer Webseite. Und dieser iframe übernimmt alles, was nötig ist, um mit euren Kunden zu chatten.

Wie beeinflussen Chat-Widgets die Core Web Vitals?

Chat-Widgets beeinflussen die Core Web Vitals auf verschiedene Weisen:

1. Sie beeinflussen den First Contentful Paint und den Largest Contentful Paint, indem sie um frühe Netzwerkressourcen konkurrieren.

2. Sie beeinflussen die Interaction to Next Paint, indem sie den Main Thread blockieren und manchmal nach einer Interaktion langsam aktualisieren.

3. Sie können Layout Shifts verursachen, wenn sie nicht korrekt auf der Seite gerendert werden.

Die Auswirkungen variieren stark zwischen den Anbietern. Die schwersten Chat-Widgets (Zendesk, Tawk.to) laden 500 bis 750 KB JavaScript. Leichtere Alternativen wie Zoho Desk und Crisp bleiben unter 155 KB. Im Durchschnitt fügt ein Chat-Widget 300 bis 600 ms Main-Thread-Blockierzeit hinzu. Das reicht aus, um einen ansonsten bestandenen INP-Wert in den Bereich "Verbesserung nötig" zu verschieben.

Largest Contentful Paint Probleme durch Chat-Widgets

Ein Chat-Widget kann die Core Web Vitals beeinflussen, wenn es um Netzwerkressourcen konkurriert. JavaScript-Dateien werden normalerweise früher zum Download in die Warteschlange gestellt als Bilder. Das bedeutet, dass der Browser im schlimmsten Fall (wenn das Chat-Skript render-blockierend ist) warten muss, bis das Chat-Skript heruntergeladen und ausgeführt wurde, bevor er mit allem anderen fortfahren kann. Ein render-blockierendes Chat-Widget kann den First Contentful Paint von 1,0 Sekunden auf über 2,3 Sekunden verdoppeln.

Auch wenn das Chat-Skript deferred ist, kann es die Paint-Metriken dennoch auf verschiedene Weise beeinflussen. Zuerst erkläre ich, was deferred Skripte tun. Der Browser kann deferred Skripte parallel herunterladen und der Browser kann mit dem Rendering fortfahren bis zum DOMContentLoaded-Event. Danach wird er die Skripte ausführen. Das Problem ist, dass bei wiederkehrenden Besuchern das LCP-Element beim DOMContentLoaded-Event wahrscheinlich noch nicht geladen ist, aber das (gecachte) Chat-Skript ausgeführt wird und eine Verzögerung der LCP-Metriken verursacht.

Interaction to Next Paint (INP) Probleme durch Chat-Widgets

Ein Chat-Widget kann und wird die Interaction to Next Paint auf 2 Arten beeinflussen. Die erste Art ist die Blockierung des Main Threads für kurze Zeit, während das Chat-Widget seine Skripte ausführt oder nach Updates sucht. So funktioniert es einfach. Alles, was man einer Seite hinzufügt, verlangsamt die Seite ein wenig.

Die zweite Art, wie es INP-Probleme verursachen kann, ist durch schlechten Code (und glaubt mir, es gibt einige schlecht programmierte Chat-Widgets da draußen). Bei Chat-Widgets bedeutet "populärer" nicht "besser programmiert". Wenn schlechter Code lange braucht, um die Darstellung zu aktualisieren, bekommt ihr automatisch INP-Probleme. Ich denke, einige Chat-Anbieter müssen sich verbessern. Dieser Teil liegt leider außerhalb meiner Kontrolle. Wenn ihr ein schlecht programmiertes Chat-Widget gewählt habt, gibt es keine Möglichkeit für mich, diesen Code zu verbessern.

Layout Shift (CLS) Probleme durch Chat-Widgets

Manchmal verursachen Chat-Widgets einen Layout Shift. Es gibt 3 übliche Verdächtige, auf die ich achte, wenn ich nach Chat-Widget-bezogenen Layout Shifts suche.

• Layout Shifts, die jedes Mal beim Laden des Chats auftreten
• Layout Shifts, die bei einem verzögerten "Chat öffnen" passieren
• Layout Shifts, die auftreten, wenn ein Chat-Verlauf geladen wird (wiederkehrender Chat-Besucher)

Wie man Core Web Vitals Probleme durch Chat-Skripte behebt

Glücklicherweise ist es ziemlich einfach, die Auswirkungen eines Chat-Widgets auf Paint-Metriken (LCP und FCP) und auf einige Teile der Interaction to Next Paint (INP) zu minimieren. In meiner Einleitung habe ich euch gesagt, dass Skripte eine Zeit und einen Ort haben. Und für Chat-Skripte ist das nicht "sofort und um jeden Preis". Ich lade Chat-Skripte gerne nach dem Load-Event, wenn die Seite nicht auf Benutzereingaben reagiert, und ich umgehe gerne den Preload-Scanner, um Netzwerkkonkurrenz zu vermeiden.

Wie machen wir das? Wir verwenden das Load-Event, weil zum Zeitpunkt des Load-Events das LCP-Element bereits auf der Seite gezeichnet wurde (es sei denn, ihr habt es mit JavaScript lazy geladen). Wir verwenden requestIdleCallback, um auf einen untätigen Moment zu warten, in dem der Browser nicht auf Benutzereingaben reagiert. Und wir verwenden JavaScript, um das Chat-Skript einzufügen, damit der Preload-Scanner die Script-src nicht sofort erkennt und einen frühen Download auslöst (und genau das wollen wir vermeiden). Dies ist dasselbe Script-Deferral-Pattern, das für YouTube-Einbettungen und Google Maps verwendet wird.

<script>
window.addEventListener('load', function(){
  requestIdleCallback(function(){
    var s = document.createElement('script');
    s.src = 'https://your-chat-widget-url.com/chat.js';
    document.body.appendChild(s);
  })
})
</script>

Beachtet, dass requestIdleCallback in Safari nicht unterstützt wird. Verwendet einen fallback: const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1)); und ersetzt requestIdleCallback durch idle im obigen Beispiel.

Mit diesem Load-Event plus requestIdleCallback-Pattern sinkt die Lighthouse-Score-Auswirkung eines Chat-Widgets von 9 bis 16 Punkten auf 0 bis 1 Punkt.

Alternative: Interaktionsbasiertes Laden

Anstatt das Chat-Widget automatisch nach dem Load-Event zu laden, könnt ihr warten, bis der Besucher tatsächlich mit der Seite interagiert. Lauscht auf mousemove, scroll oder touchstart und ladet das Chat-Skript beim ersten Event. Das garantiert null Auswirkung auf alle Core Web Vitals für Besucher, die nie scrollen oder interagieren.

<script>
function loadChat() {
  var s = document.createElement('script');
  s.src = 'https://your-chat-widget-url.com/chat.js';
  document.body.appendChild(s);
  ['mousemove','scroll','touchstart'].forEach(function(e){
    document.removeEventListener(e, loadChat);
  });
}
['mousemove','scroll','touchstart'].forEach(function(e){
  document.addEventListener(e, loadChat, {once: true});
});
</script>

Cumulative Layout Shift Probleme durch Chat-Widgets beheben

Chat-Widgets verursachen normalerweise einen kleinen Layout Shift. Das muss kein großes Problem sein. Aber manchmal rendern Chat-Widgets einfach schlecht. Glücklicherweise können wir (gewissermaßen) auch das beheben, indem wir das schlechte Rendering verstecken, bis das Widget fertig gerendert hat.

Dazu müssen wir die Dokumentation des Chat-Widgets lesen (es gibt viele verschiedene Chat-Anbieter und sie funktionieren alle ein wenig anders). Sucht in der Dokumentation nach Callback-Funktionen, die in verschiedenen Phasen des Chat-Renderings aufgerufen werden. Da ich nicht weiß, welches Chat-Widget ihr verwendet, werden wir zur Veranschaulichung des Mechanismus die chat.ready()-Funktion verwenden.

Nun können wir mit etwas cleverem Styling den Chat mit der CSS-Eigenschaft opacity verstecken und wieder anzeigen. Zuerst fügen wir einige Klassen hinzu, um das Chat-Widget standardmäßig zu verstecken (ändert die Selektoren passend zu eurem Chat-Widget). Dann fügen wir im chat.ready()-Callback "showchat" zur body-Klassenliste hinzu, um die zweite CSS-Zeile zu aktivieren, die den Chat wieder anzeigt.

<style>
/*hide chat widget by default*/
.chatwidget{opacity:0}
/*show chat widget after .showchat body class*/
body.showchat .chatwidget {opacity:1}
</style>

<script>
chat.ready(function(){
  document.documentElement.classList.add('showchat');
})
</script>

Das war's! Viel Erfolg beim Beschleunigen eures Chat-Widgets. Um eure Änderungen mit echten Besuchern zu verifizieren, richtet Real User Monitoring ein. Lab-Scores sind nützlich zum Debuggen, aber die Felddaten von echten Nutzern sind das, was Google für das Ranking verwendet.