Dettagli tecnici

Questa pagina è per chi vuole conoscere i dettagli. Tutto ciò che vi è riportato è misurato o ricavato dal codice sorgente: nulla è stimato.

Come si carica il widget

Due fasi. Prima un piccolo caricatore che disegna il pulsante e non fa altro. La chat vera e propria viene recuperata solo quando si verifica uno dei cinque eventi di attivazione: il browser è inattivo (al più tardi dopo tre secondi), un mouse o un dito sul pulsante, un comando dalla pagina, un segnale di frustrazione da MousePlayer oppure un avviso push, ad esempio dal Suo service worker.

C’è un motivo: la maggior parte dei visitatori non apre mai la chat. Per loro non deve rallentare il caricamento della pagina; gli eventi di attivazione applicabili si impostano sul tag script.

• Caricatore: 3,48 kB, come trasferiti dalla nostra CDN con gzip
• Widget completo: 85,5 kB, trasferiti allo stesso modo e solo quando si verifica uno degli eventi di attivazione
• Tempo prima che compaia il pulsante: 11–21 ms
• Spostamento del layout: 0,0000 – lo spazio viene riservato prima che compaia qualsiasi cosa

Per confronto, anch’essi misurati e tutti e tre compressi con brotli: il caricatore di Crisp pesa 2.876 B, quello di Intercom 3.161 B. Con 3.069 B ci collochiamo nel mezzo, non ordini di grandezza più in basso. Chi sostiene il contrario non ha misurato.

Non interferisce con il Suo sito

Il widget risiede in uno shadow DOM chiuso. I Suoi stili non possono raggiungerlo e i suoi stili non possono raggiungere la Sua pagina, nemmeno se imposta * { box-sizing: border-box } o usa un framework CSS che ridefinisce tutto.

Funziona con una Content Security Policy rigorosa senza un solo messaggio nella console: nessun eval, nessun font web, nessun pixel di tracciamento. Imposta gli stili tramite fogli di stile costruibili, che non rientrano in style-src. Il pulsante, la finestra della chat, i tour del prodotto e la console operatori sul Suo sito non richiedono quindi unsafe-inline: misurato con style-src 'self' e persino con style-src 'none', zero violazioni e stili completi. Misurato nella versione attuale di Chromium; i browser meno recenti senza fogli di stile costruibili (come Safari prima della 16.4) ripiegano su un elemento <style>, che una policy rigorosa blocca.

Zero richieste ad altri server. Tutto proviene da reactive.chat oppure, con un dominio personalizzato, dal Suo indirizzo; immagini come logo e avatar provengono dagli indirizzi che fornisce Lei stesso.

Il protocollo

La connessione usa WebSocket; dove una rete non lascia passare WebSocket, usa normali richieste HTTPS (server-sent events o long polling). Il protocollo è versionato e definisce 31 codici di errore, 26 per il widget e gli altri per il pannello operatori e la ricerca nel sito, ciascuno con una reazione prescritta del client (riprovare subito, riprovare dopo un’attesa, riprovare dopo la riconnessione, non riprovare), alcuni anche con un codice di chiusura. Un errore non presente nell’elenco viene trattato come un errore temporaneo del server: nuovo tentativo dopo un’attesa e, dopo cinque tentativi, il messaggio viene considerato non consegnato e può essere inviato nuovamente, senza cicli infiniti.

Riconnessione con attesa progressivamente crescente. Se la connessione cade, i messaggi finiscono in un buffer e vengono inviati non appena torna disponibile. Ogni messaggio ha un ID; il server riconosce le ripetizioni e non le memorizza due volte.

Accessibilità

Realizzato secondo WCAG 2.2 AA:

• Focus confinato nella finestra aperta, Esc la chiude e il focus torna alla posizione precedente
• I nuovi messaggi vengono annunciati tramite aria-live
• Il contrasto fra testo e superficie è calcolato, non presunto: veda sotto
• Interamente utilizzabile da tastiera, con indicatore del focus visibile

Il contrasto viene calcolato

Fornisce un colore. La superficie assume esattamente quel colore. Il testo su di essa viene modificato fino a raggiungere un rapporto di 4,5:1, il requisito WCAG per il testo normale.

Misurato su 178 colori in due temi e tre abbinamenti, quindi 1.068 punti dati: nessuno sotto 4,5:1, valore peggiore 4,50:1.

Questa è la differenza rispetto ad altri provider: lì si può configurare un widget fino a renderlo illeggibile.

Dati personali

Il mascheramento avviene in due punti: nel browser del visitatore prima che qualsiasi dato lasci il dispositivo, e di nuovo sul server prima che venga memorizzato. Vengono riconosciuti numeri di carta (con controllo di Luhn), IBAN, indirizzi e-mail, numeri di telefono, codici fiscali e numeri di documenti d’identità. I numeri d’ordine e cliente rimangono invariati.

Due punti, perché uno non basta: quello nel browser può essere disattivato, quello sul server vede solo ciò che arriva.

Regole

Il momento in cui il widget interviene è definito in un elenco dichiarativo di regole, non in una condizione nel codice. Sono incluse sei regole predefinite (permanenza su una pagina, clic di rabbia, errore JavaScript, modulo bloccato, intenzione d’acquisto, abbandono del checkout); clic di rabbia, modulo bloccato e intenzione d’acquisto vengono rilevati solo insieme a MousePlayer. Può aggiungere regole proprie nell’account. Nel piano Free ha effetto un solo invito attivo per progetto.

La differenza è pratica: modificare una regola significa cambiare un’impostazione nell’account, non eseguire una distribuzione.

Integrazioni

Webhook e Slack sono completi. Per oltre 30 ulteriori servizi è pronto un collegamento; la maggior parte è stata testata con controparti simulate ma non ha mai funzionato con il servizio reale, e la pagina delle integrazioni nell’account li contrassegna come tali.

L’API server (REST e MCP) legge conversazioni, messaggi, progetti, visitatori, eventi e regole, scrive messaggi ed eventi e registra webhook. L’elenco dei visitatori e MCP possono essere disattivati per ciascun progetto.

Ogni integrazione passa da una coda con un interruttore di protezione: se un servizio esterno si blocca, dopo errori ripetuti viene saltato per un certo periodo. Un messaggio di chat non viene mai rallentato da questo: è la regola più importante di questo livello.

Che cosa non è finito

Per evitare che lo si scopra durante l’integrazione:

• Il bridge MousePlayer esegue polling, perché MousePlayer non emette ancora autonomamente gli eventi concordati.
• Allegati, test A/B e dominio personalizzato funzionano in beta: funzionano e sono stati misurati, ma possono ancora cambiare.
• I canali e-mail, Telegram, SMS, WhatsApp, Messenger e Instagram sono testati con controparti simulate, non ancora con account reali. Se una risposta tramite un canale fallisce definitivamente, al momento la conversazione non lo mostra.

Approfondimenti nella documentazione

Come interagiscono widget, server e connessione: Architettura e flusso. Connessione, fallback HTTP e riconnessione: Trasporto. Tutti i capitoli: documentazione.