Technische details
Protocol, foutcodes, toegankelijkheid en de stand van zaken achter elke belofte.
Deze pagina is voor wie de details wil weten. Alles hier is gemeten of uit de broncode afgelezen — niets is geschat.
Hoe de widget laadt
Twee fasen. Eerst een kleine loader die de knop tekent en verder niets doet. De chat zelf wordt pas opgehaald zodra een van vijf triggers optreedt: de browser heeft tijd (uiterlijk na drie seconden), een muis of vinger op de knop, een opdracht vanuit de pagina, een frustratiesignaal van MousePlayer of een pushsignaal, bijvoorbeeld vanuit uw service worker.
Daar is een reden voor: de meeste bezoekers openen de chat nooit. Voor hen mag die het laden van de pagina niet vertragen; welke triggers gelden, stelt u in op de scripttag.
- Loader: 3,48 kB, zoals ons CDN die met gzip verstuurt
- Hele widget: 85,5 kB, op dezelfde manier verstuurd en pas zodra een van de triggers optreedt
- Tot de knop verschijnt: 11–21 ms
- Layoutverschuiving: 0,0000 — de ruimte is gereserveerd voordat er iets verschijnt
Ter vergelijking, ook gemeten en alle drie met brotli gecomprimeerd: de loader van Crisp is 2.876 B, die van Intercom 3.161 B. Met 3.069 B zitten wij ertussen, geen ordes van grootte eronder. Wie iets anders beweert, heeft niet gemeten.
Uw website wordt niet verstoord
De widget bevindt zich in een gesloten shadow DOM. Uw stijlen bereiken de widget niet en de stijlen van de widget bereiken uw pagina niet — ook niet als u * { box-sizing: border-box } instelt of een CSS-framework gebruikt dat alles opnieuw definieert.
De widget werkt onder een strikte Content Security Policy zonder één melding in de console: geen eval, geen weblettertype, geen trackingpixel. De stijlen worden ingesteld via constructable stylesheets, waarop style-src niet van toepassing is. De knop, het chatvenster, producttours en de medewerkersconsole op uw website hebben daarom geen unsafe-inline nodig — gemeten onder style-src 'self' en zelfs onder style-src 'none': nul overtredingen, volledig opgemaakt. Gemeten in de huidige Chromium-versie; oudere browsers zonder constructable stylesheets (zoals Safari vóór 16.4) vallen terug op een <style>-element, dat een strikt beleid blokkeert.
Nul verzoeken aan andere servers. Alles komt van reactive.chat of, bij een eigen domein, van uw eigen adres; afbeeldingen zoals het logo en avatars komen van de adressen die u zelf opgeeft.
Het protocol
De verbinding gebruikt WebSocket; als een netwerk WebSocket blokkeert, worden gewone HTTPS-verzoeken gebruikt (server-sent events of long polling). Het protocol heeft versies en definieert 31 foutcodes, waarvan 26 voor de widget en de overige voor het agentenpaneel en zoeken op de website. Elke code schrijft een clientreactie voor (direct opnieuw proberen, na een wachttijd opnieuw proberen, na opnieuw verbinden opnieuw proberen, niet opnieuw proberen), sommige hebben ook een sluitcode. Een fout die niet op de lijst staat, wordt behandeld als een tijdelijke serverfout: na een wachttijd opnieuw proberen. Na vijf pogingen geldt het bericht als niet bezorgd en kan het opnieuw worden verzonden — geen eindeloze lus.
Opnieuw verbinden met steeds langere tussenpozen. Als de verbinding wegvalt, worden berichten in een buffer geplaatst en verzonden zodra de verbinding terug is. Elk bericht heeft een identificatiecode; de server herkent herhalingen en slaat ze niet tweemaal op.
Toegankelijkheid
Gebouwd volgens WCAG 2.2 AA:
- De focus blijft binnen het geopende venster, ESC sluit het en de focus keert terug naar de vorige plek
- Nieuwe berichten worden aangekondigd via
aria-live - Het contrast tussen tekst en achtergrond wordt berekend, niet aangenomen — zie hieronder
- Volledig met het toetsenbord te bedienen, met een zichtbare focusring
Contrast wordt berekend
U geeft een kleur op. Het oppervlak krijgt precies die kleur. De tekst erop wordt aangepast totdat de verhouding 4,5:1 wordt bereikt — de WCAG-eis voor gewone tekst.
Gemeten voor 178 kleuren in twee thema's en drie combinaties, dus 1.068 meetpunten: geen enkele onder 4,5:1, de laagste waarde was 4,50:1.
Dat is het verschil met andere aanbieders: daar kunt u een widget zo instellen dat niemand hem meer kan lezen.
Persoonsgegevens
Maskering vindt op twee plaatsen plaats: in de browser van de bezoeker voordat iets het apparaat verlaat, en opnieuw op de server voordat iets wordt opgeslagen. Herkend worden kaartnummers (met Luhn-controle), IBAN's, e-mailadressen, telefoon-, belasting- en identiteitskaartnummers. Bestel- en klantnummers blijven staan.
Op twee plaatsen, omdat één niet genoeg is: de maskering in de browser kan worden uitgeschakeld, die op de server ziet alleen wat aankomt.
Regels
Wanneer de widget zich meldt, staat in een declaratieve lijst met regels, niet in een voorwaarde in de code. Er zijn standaard zes regels (lang op een pagina blijven, woedeklikken, JavaScript-fout, vastgelopen formulier, koopintentie, verlaten van het afrekenproces); woedeklikken, vastgelopen formulieren en koopintentie worden alleen samen met MousePlayer herkend. U kunt eigen regels toevoegen in uw account. In het Free-abonnement werkt één actieve aanspreekregel per project.
Het verschil is praktisch: een regel wijzigen betekent een instelling in uw account wijzigen, geen nieuwe versie uitrollen.
Integraties
Webhooks en Slack zijn klaar. Voor ruim 30 andere diensten is een koppeling gereed; de meeste zijn getest met gesimuleerde tegenpartijen, maar hebben nog nooit met de echte dienst gewerkt. De integratiepagina in uw account vermeldt dit.
De server-API (REST en MCP) leest gesprekken, berichten, projecten, bezoekers, gebeurtenissen en regels, schrijft berichten en gebeurtenissen en registreert webhooks. De bezoekerslijst en MCP kunnen per project worden uitgeschakeld.
Elke integratie loopt via een wachtrij met een circuit breaker: als een externe dienst vastloopt, wordt die na herhaalde mislukkingen een tijdje overgeslagen. Een chatbericht wordt hierdoor nooit opgehouden — dat is de belangrijkste regel in deze laag.
Wat nog niet klaar is
Zodat niemand dit pas tijdens het integreren ontdekt:
- De MousePlayer-koppeling vraagt actief gegevens op, omdat MousePlayer de afgesproken gebeurtenissen nog niet zelf verstuurt.
- Bijlagen, A/B-tests en uw eigen domein zijn bètafuncties: ze werken en zijn gemeten, maar kunnen nog veranderen.
- De kanalen e-mail, Telegram, SMS, WhatsApp, Messenger en Instagram zijn getest met gesimuleerde tegenpartijen, nog niet met echte accounts. Als een antwoord via een kanaal definitief mislukt, is dat momenteel niet in het gesprek te zien.
Meer in de documentatie
Hoe widget, server en verbinding samenwerken: Architectuur en werking. Verbinding maken, HTTP-terugval en opnieuw verbinden: Transport. Alle hoofdstukken: documentatie.
آخری بار تازہ کاری: