Chat-Widget und Ladezeit: was es die Seite kostet

Ein Chat-Assistent ist Code, der im Browser Ihrer Besucher läuft, und jede Zeile davon teilt sich die Ladezeit mit dem Inhalt. Die Frage, was das Widget kostet, ist deshalb berechtigt. Die ehrliche Antwort besteht aus zwei Zahlen und einer Reihenfolge. Die erste Zahl ist die Größe der Datei, die beim Seitenaufbau wirklich übertragen wird, nicht die Größe im Quelltext. Die zweite ist die Zahl der Anfragen, die das Widget der Seite hinzufügt. Die Reihenfolge entscheidet über vieles: Was erst nach dem sichtbaren Inhalt lädt, kann ihn nicht verzögern, wird aber trotzdem übertragen. Dieser Beitrag beschreibt, wie ein Widget gebaut ist, das sich an diese Reihenfolge hält: ein Ladeskript, das den Aufbau der Seite nicht anhält, ein Chatfenster in einem eigenen Rahmen, der erst nach dem Laden der Seite entsteht, der Stil gekapselt über das Shadow DOM. Und er beschreibt, wie Sie den Unterschied selbst nachmessen, mit und ohne Widget. Die Zahlen stammen aus unserer eigenen Messung der ausgelieferten Dateien, nachzulesen unter Messreihen.

Grafik vergrößern

Beschriftungen der Abbildung

• Reihenfolge des Seitenaufbaus
• LCP steht
• Seite fertig geladen
• HTML und CSS
• Bilder und sichtbarer Text
• Rest der Seite
• Ladeskript
• Chatfenster im eigenen Rahmen
• Beim Seitenaufbau
• 1 Datei auf der Wirtsseite: das Ladeskript
• 24,1 KB komprimiert übertragen (Brotli)
• 76 439 Byte roh, ohne Brotli ungepackt
• Gezählt wird, was ankommt, nicht was im Quelltext steht.
• Nach dem Laden der Seite
• Chatfenster lädt in einem eigenen Rahmen
• Stil gekapselt, kein Zugriff auf das Seiten-CSS
• Außerhalb des kritischen Pfads, ohne Klick
• Mit Einwilligungstor erst nach der Zustimmung.
• Eigene Messung: 1 Datei, 24,1 KB komprimiert auf der Wirtsseite
• Gemessen an der ausgelieferten Datei, nicht am Quelltext

Was ein Chat-Widget die Ladezeit kostet

Was beim Seitenaufbau wirklich geladen wird

Wer von einem Chat-Widget spricht, meint meistens zwei verschiedene Dinge in einem Wort. Das erste ist das Ladeskript: die Datei, die Ihre Seite einbindet, die den Auslöser zeichnet und danach den Rahmen für das Chatfenster einhängt. Das zweite ist das Chatfenster mit Gesprächsverlauf, Eingabefeld, Formatierung und Anbindung an den Assistenten, in einem eigenen Rahmen mit eigenen Dateien. Entscheidend ist deshalb nicht nur, wie viel ein Chat-Assistent insgesamt an Code mitbringt, sondern wann welcher Teil geladen wird: während Ihre Seite aufgebaut wird, nach dem Laden der Seite oder erst, wenn ein Besucher den Chat öffnet. Jede dieser drei Stufen kostet etwas anderes.

Damit lässt sich die Frage beziffern. In unserer eigenen Messung lag das Ladeskript auf Ihrer Seite, komprimiert, bei 24,1 KB. Die Abdeckung dieser Zahl gehört dazu: gemessen wurde nur die Datei, die auf der fremden Seite läuft, mit der Kompression, die der Webserver tatsächlich schickt; das Chatfenster liegt im eigenen Rahmen und lädt, wenn Ihre Seite fertig geladen ist. Der Wert beschreibt unseren eigenen Stand der ausgelieferten Dateien und ist keine Zusage für ein anderes Vorhaben. Wie die Reihe entsteht und was sie nicht abdeckt, steht unter Messreihen.

Komprimiert statt roh: welche Zahl zählt

Größenangaben zu Widgets sind oft deshalb unbrauchbar, weil sie die falsche Datei beschreiben. Ein Webserver liefert Textdateien gepackt aus, üblicherweise mit gzip oder brotli, und der Browser entpackt sie beim Empfang. Übertragen wird also die gepackte Fassung, und nur die verbraucht Leitung und Zeit. Wer die Datei aus dem Bauverzeichnis wiegt, misst eine Größe, die nie über das Netz geht. In die andere Richtung fällt die Zahl noch weiter auseinander, wenn jemand die entpackte Größe im Arbeitsspeicher nennt oder gleich das gesamte Quellverzeichnis. Sinnvoll ist nur eine Angabe: was beim Browser ankommt, mit der Kompression, die der Webserver tatsächlich schickt.

Drei Angaben für eine Datei, und alle drei stimmen. Sie beantworten nur verschiedene Fragen. Der Rohwert sagt etwas über den Umfang des Codes, der gepackte Wert etwas über die Übertragung. Welche Fassung der Browser eines Besuchers tatsächlich zieht, entscheidet der Webserver anhand dessen, was der Browser an Kompression anbietet: Bei uns bekommt ein Browser mit Brotli die gepackte Fassung, einer, der nur gzip anbietet, derzeit die ungepackte. Deshalb gehört zu jeder Gewichtsangabe die Bemerkung, wie gemessen wurde. Ohne sie lässt sich dieselbe Datei je nach Interessenlage sehr unterschiedlich darstellen, ohne dass irgendwer lügen müsste.

Eine Anfrage auf der Wirtsseite

Byte sind nur die eine Hälfte der Rechnung. Die andere ist die Zahl der Anfragen, denn jede zusätzliche Anfrage kostet unabhängig von ihrer Größe Zeit: Namensauflösung, Verbindungsaufbau, bei einem fremden Ziel zusätzlich ein eigener Handschlag zur Verschlüsselung. Auf einem langsamen Mobilnetz wiegt dieser Vorlauf oft schwerer als die übertragenen Byte selbst. In unserer Messung steht auf der Wirtsseite genau eine Datei. Im Standard kommt sie von der Widgetdomain, und der Browser baut dafür eine eigene Verbindung auf. Läuft die Auslieferung über einen Pfad Ihrer eigenen Domain, nutzt er die Verbindung mit, die für das HTML der Seite ohnehin offen ist.

Verzögert nachladen: nach dem Laden der Seite

Der größte Hebel ist nicht die Kompression, sondern der Zeitpunkt. Ein Widget, das sich an den Aufbau der Seite anhängt, konkurriert mit dem Inhalt um dieselbe Leitung und denselben Hauptstrang im Browser. Ein Widget, das wartet, konkurriert mit dem Aufbau nicht. Deshalb ist die Ladekette gestaffelt: Das Skript wird verzögert eingebunden und läuft erst, wenn das Dokument steht. Es zeichnet den Auslöser und hängt den Rahmen mit dem Chatfenster erst ein, wenn die Seite fertig geladen ist. Das spart dem Besucher beim Öffnen die Wartezeit, kostet aber Übertragung auch bei Besuchern, die gar nicht chatten. Wer das anders gewichtet, nutzt die Einstellung für das Einwilligungstor; dann wartet der Rahmen auf die Zustimmung oder einen Klick auf den Auslöser. Wie der Auslöser dabei platziert wird und wann eine proaktive Ansprache sinnvoll ist, behandelt der Beitrag zum Platzieren des Chat-Widgets.

• Dokument zuerst: Das Skript wird verzögert eingebunden und hält den Aufbau der Seite nicht an.
• Auslöser zeichnen: Der Knopf bekommt seinen festen Platz, bevor irgendetwas nachlädt, damit nichts verspringt.
• Laden abwarten: Erst wenn die Seite fertig geladen ist, hängt das Skript den Rahmen für das Chatfenster ein.
• Einwilligung beachten: Ist das Einwilligungstor eingeschaltet, wartet der Rahmen auf die Zustimmung oder einen Klick auf den Auslöser.
• Gespräch aufbauen: Die Verbindung zum Assistenten entsteht im Fenster, nicht auf der Wirtsseite.
• Getrennt halten: Stil und Skripte des Fensters bleiben in seinem Rahmen und greifen nicht in das Dokument Ihrer Seite.

Warum das Widget den LCP nicht verschiebt

Die Largest Contentful Paint, kurz LCP, ist der Zeitpunkt, zu dem das größte Bild oder der größte Textblock im Sichtfeld fertig gezeichnet ist. Zwei Dinge können diesen Zeitpunkt nach hinten schieben: eine Ressource, die dem größten Element die Leitung streitig macht, und Arbeit im Hauptstrang, die das Zeichnen aufhält. Ein verzögert eingebundenes Skript tut im Regelfall weder das eine noch das andere, weil es startet, nachdem das Dokument steht, und den Rahmen erst nach dem Laden der Seite nachzieht. Und der Auslöser selbst wird nicht zum gemessenen Element, solange er kleiner bleibt als das größte sichtbare Bild oder der größte Textblock, also im üblichen Fall eines Knopfes in einer Ecke. Er ist damit kein Kandidat für den LCP, sondern nur ein kleines Element daneben.

Für die beiden anderen Kennzahlen gilt dieselbe Logik. Ein Layoutsprung entsteht, wenn ein Element nachträglich Platz einnimmt, den vorher etwas anderes hatte. Der Auslöser bekommt seinen Platz deshalb vor dem Nachladen zugewiesen und liegt außerdem über dem Inhalt statt in ihm, sodass er nichts verschiebt. Die Reaktionszeit auf Eingaben leidet, wenn der Hauptstrang lange am Stück belegt ist. Ein Skript, das einen Knopf zeichnet und nach dem Laden einen Rahmen einhängt, belegt ihn kurz und gibt ihn wieder frei. Was danach im Chatfenster geschieht, läuft in einem eigenen Rahmen und nicht im Dokument Ihrer Seite. Wie lange der Assistent danach für eine Antwort braucht, ist eine ganz andere Messung, beschrieben im Beitrag zur Antwortzeit.

Eigener Ursprung statt fremder Server

Wo die Datei herkommt, entscheidet über Tempo und über Datenfluss zugleich. Kommt das Ladeskript von Ihrer eigenen Adresse, nutzt der Browser die Verbindung, die für die Seite ohnehin schon offen ist. Kommt es von einem fremden Server, beginnt die Kette von vorn: Namensauflösung, Verbindungsaufbau, Handschlag zur Verschlüsselung, und erst danach die eigentlichen Byte. Dazu kommt, dass eine Anfrage an einen fremden Server dessen Betreiber die Adresse des Besuchers zeigt, oft schon bevor irgendeine Einwilligung vorliegt. Bei XICBOT kommt das Ladeskript im Standard von der Widgetdomain; auf Wunsch läuft die Auslieferung vollständig über einen Pfad Ihrer eigenen Domain, dann ist für den Besucher nur Ihre Adresse im Spiel. Gehostet wird in Deutschland, und die Antworten erzeugt ein spezialisierter Modellanbieter, auch außerhalb der EU auf Grundlage von Standardvertragsklauseln; Einzelheiten dazu stehen auf der Seite zu Datenschutz und Hosting, der technische Weg der Einbindung auf der Seite zur Integration.

Der Unterschied fällt auf einem schnellen Anschluss kaum auf und auf einem schwachen Mobilnetz deutlich. Genau dort entscheidet sich aber, ob eine Seite als träge erlebt wird. Wenn Sie Ihre Werte prüfen, messen Sie deshalb nicht nur unter besten Bedingungen. Eine gedrosselte Messung auf einem mittleren Gerät zeigt den Vorlauf, den eine zusätzliche Verbindung kostet, während eine Messung auf einem schnellen Rechner ihn im Rauschen verschwinden lässt.

Shadow DOM gegen Stilkollisionen

Ein Widget, das seinen eigenen Stil in die Seite schüttet, ist kein Ladezeitproblem, sondern ein Pflegeproblem, und es fällt oft erst Wochen später auf. Klassisch geschieht das über allgemeine Regeln, die auf jedes Element einer Art wirken, oder über eine mitgebrachte Stildatei, die zufällig dieselben Namen verwendet wie Ihr Theme. Das Ergebnis sind verschobene Knöpfe an einer Stelle, an der niemand ein Widget vermutet. Das Shadow DOM löst das an der Wurzel: Der Auslöser hängt an einem eigenen Element, unter dem ein abgetrennter Baum liegt. Regeln von aussen greifen dort nicht hinein, Regeln von innen nicht hinaus.

Die Kapselung hat eine Grenze, die man kennen sollte: Sie trennt den Stil, nicht die Verantwortung. Der Auslöser ist Teil Ihrer Seite, er muss über die Tastatur erreichbar sein, eine sichtbare Fokusmarke tragen und einen sprechenden Namen haben. Auch die Kontraste im Fenster gehören geprüft, denn eine Vorlesehilfe liest den abgetrennten Baum wie jeden anderen Inhalt. Was dabei zu prüfen ist, steht auf der Seite zur Barrierefreiheit und im Beitrag zum barrierefreien KI-Assistenten.

Messen mit und ohne Widget

Alle Angaben in diesem Beitrag, auch unsere eigenen, sind für Ihre Seite nur ein Anhaltspunkt. Belastbar wird die Frage erst durch einen Vergleich an Ihrem eigenen Aufbau: dieselbe Adresse, einmal ohne und einmal mit eingebundenem Widget, unter gleichen Bedingungen. Was dabei zählt, ist nicht der Bestwert eines einzelnen Laufs, sondern die Mitte mehrerer Läufe. Eine einzelne Messung schwankt mit dem Netz, mit dem Zwischenspeicher und mit dem, was der Rechner sonst gerade tut; wer daraus eine Aussage ableitet, liest Rauschen.

• Zweimal dieselbe Seite: eine Fassung ohne Widget, eine mit; sonst ändert sich nichts, auch kein Text und kein Bild.
• Gleiche Bedingungen: gleiches Geräteprofil, gleiche Drosselung, leerer Zwischenspeicher, keine Erweiterungen im Browser.
• Mehrere Läufe: fünf oder mehr je Fassung, und verglichen wird der mittlere Lauf, nicht der schnellste.
• Vier Größen festhalten: übertragene Byte, Zahl der Anfragen, LCP und Layoutsprung, je Fassung.
• Getrennt vom Chatfenster: den Seitenaufbau bis zum Laden getrennt von dem ausweisen, was der Rahmen danach nachlädt, und in einem zweiten Durchgang mit geöffnetem Chat messen.
• Auch im Feld nachsehen: Laborwerte zeigen die Richtung, echte Aufrufe zeigen, was Ihre Besucher auf ihren Geräten erleben.

Was die eigene Zahl sagt und was nicht

Die 24,1 KB aus unserer Messung beschreiben eine Datei zu einem Stand, gemessen an der Auslieferung; den Rahmen mit dem Chatfenster, der nach dem Laden der Seite eigene Dateien holt, umfassen sie nicht. Sie sagen nichts darüber, wie schnell Ihre Seite insgesamt ist, denn dafür zählen Ihre Bilder, Ihre Schriften und Ihre übrigen Skripte weit mehr. Sie sagen auch nichts über morgen: Wächst der Funktionsumfang des Auslösers, wächst die Datei, und dann gilt die alte Zahl nicht mehr. Und sie sagen nichts über die Qualität der Antworten, die danach im Fenster erscheinen; die hängt an der Wissensbasis und nicht am Gewicht des Skripts. Nach Paragraf 5 Absatz 1 des Gesetzes gegen den unlauteren Wettbewerb handelt unlauter, wer eine irreführende geschäftliche Handlung vornimmt, die geeignet ist, einen Marktteilnehmer zu einer geschäftlichen Entscheidung zu veranlassen, die er andernfalls nicht getroffen hätte. Eine Gewichtsangabe ohne Angabe der Messart fällt genau in dieses Feld, und deshalb steht die Abdeckung bei uns neben jeder Zahl. Was das Widget nach dem Öffnen für Ihre Besucher leistet, zeigt die Seite zum Website-Assistenten.

• Übertragene, komprimierte Größe verlangen, nicht die Größe im Bauverzeichnis
• Nachfragen, wie viele Dateien und wie viele fremde Ursprünge auf der Wirtsseite entstehen
• Prüfen, wann das Chatfenster lädt: beim Seitenaufbau, nach dem Laden der Seite oder erst beim Öffnen
• Den Auslöser auf festen Platz, Tastaturbedienung und sichtbaren Fokus prüfen
• Dieselbe Seite ohne und mit Widget messen, gedrosselt und im Median mehrerer Läufe
• Zu jeder übernommenen Zahl die Abdeckung mitschreiben, sonst ist sie später nicht nachprüfbar

Häufige Fragen