Detalles técnicos

Esta página está dirigida a quienes quieren conocer los detalles. Todo lo que aparece aquí se ha medido o leído en el código fuente; nada se ha estimado.

Cómo se carga el widget

En dos etapas. Primero, un pequeño cargador que dibuja el botón y no hace nada más. El chat solo se obtiene cuando se activa uno de cinco disparadores: el navegador está inactivo (como muy tarde después de tres segundos), un ratón o dedo sobre el botón, un comando de la página, una señal de frustración de MousePlayer o un aviso push, por ejemplo de su service worker.

Hay un motivo: la mayoría de los visitantes nunca abre el chat. Para ellos no debería retrasar la carga de la página; los disparadores aplicables se establecen en la etiqueta de script.

• Cargador: 3,48 kB, tal como lo transfiere nuestra CDN con gzip
• Widget completo: 85,5 kB, transferido del mismo modo y solo cuando se activa uno de los disparadores
• Hasta que aparece el botón: 11–21 ms
• Desplazamiento del diseño: 0,0000; el espacio se reserva antes de que aparezca nada

Como comparación, también medida y con los tres comprimidos con brotli: el cargador de Crisp pesa 2876 B y el de Intercom, 3161 B. Con 3069 B estamos entre ambos, no varios órdenes de magnitud por debajo. Quien afirme lo contrario no lo ha medido.

No interfiere con su sitio

El widget se aloja en un shadow DOM cerrado. Sus estilos no pueden alcanzarlo y los del widget no pueden alcanzar su página, ni siquiera si establece * { box-sizing: border-box } o utiliza un framework CSS que redefine todo.

Funciona con una política de seguridad de contenido estricta sin un solo mensaje en la consola: sin eval, sin fuente web y sin píxel de seguimiento. Establece sus estilos mediante hojas de estilo construibles, que no están cubiertas por style-src. Por tanto, el botón, la ventana del chat, los recorridos del producto y la consola de agentes en su sitio no necesitan unsafe-inline: medido con style-src 'self' e incluso con style-src 'none', cero infracciones y estilos completos. Medido en Chromium actual; los navegadores antiguos sin hojas de estilo construibles (como Safari anterior a 16.4) recurren a un elemento <style>, que una política estricta bloquea.

Cero solicitudes a otros servidores. Todo procede de reactive.chat o, con un dominio propio, de su propia dirección; las imágenes, como el logotipo y los avatares, proceden de las direcciones que usted indique.

El protocolo

La conexión utiliza WebSocket; cuando una red no deja pasar WebSocket, utiliza solicitudes HTTPS normales (Server-Sent Events o sondeo largo). El protocolo tiene versiones y define 31 códigos de error, 26 para el widget y el resto para el panel de agentes y la búsqueda del sitio web, cada uno con una respuesta prescrita del cliente (reintentar de inmediato, tras una espera, tras reconectar o no reintentar), algunos también con un código de cierre. Un error que no esté en la lista se trata como un error temporal del servidor: reintento tras una espera y, después de cinco intentos, el mensaje se considera no entregado y se puede reenviar, sin bucle infinito.

Reconexión con espera creciente. Si se interrumpe la conexión, los mensajes pasan a un búfer y se envían en cuanto se restablece. Cada mensaje lleva un ID; el servidor reconoce las repeticiones y no las almacena dos veces.

Accesibilidad

Desarrollado conforme a WCAG 2.2 AA:

• Foco retenido en la ventana abierta, ESC cierra y el foco vuelve a su ubicación anterior
• Los mensajes nuevos se anuncian mediante aria-live
• El contraste entre texto y superficie se calcula, no se presupone; véase más abajo
• Manejo completo con teclado e indicador de foco visible

El contraste se calcula

Usted indica un color. La superficie toma exactamente ese color. El texto sobre ella se ajusta hasta alcanzar una relación de 4,5:1, el requisito de WCAG para texto normal.

Medido con 178 colores, dos temas y tres combinaciones, es decir, 1068 puntos de datos: ninguno por debajo de 4,5:1, con un peor valor de 4,50:1.

Esa es la diferencia respecto a otros proveedores: en ellos se puede configurar un widget hasta que nadie pueda leerlo.

Datos personales

La ocultación se realiza en dos lugares: en el navegador del visitante antes de que salga nada del dispositivo y, de nuevo, en el servidor antes de almacenar nada. Se reconocen números de tarjeta (con comprobación de Luhn), IBAN, direcciones de correo, números de teléfono, números fiscales y de documentos de identidad. Los números de pedido y de cliente se mantienen.

En dos lugares porque uno solo no basta: la del navegador se puede desactivar y la del servidor solo ve lo que llega.

Reglas

Cuándo interviene el widget se define en una lista declarativa de reglas, no en una condición del código. Se incluyen seis reglas predeterminadas (permanencia en una página, clics de rabia, error de JavaScript, formulario atascado, intención de compra y abandono del proceso de pago); los clics de rabia, los formularios atascados y la intención de compra solo se detectan junto con MousePlayer. Puede añadir las suyas en su cuenta. En el plan Free se aplica un aviso activo por proyecto.

La diferencia es práctica: cambiar una regla significa cambiar un ajuste en su cuenta, no realizar un despliegue.

Integraciones

Los webhooks y Slack están terminados. Hay conexiones preparadas para más de 30 servicios adicionales; la mayoría se ha probado con servicios simulados, pero nunca ha funcionado con el servicio real, y la página de integraciones de su cuenta lo indica.

La API de servidor (REST y MCP) lee conversaciones, mensajes, proyectos, visitantes, eventos y reglas, escribe mensajes y eventos y registra webhooks. La lista de visitantes y MCP pueden desactivarse por proyecto.

Cada integración pasa por una cola con mecanismo de corte: si un tercero se bloquea, se omite durante un tiempo tras fallos repetidos. Nunca se retrasa un mensaje de chat por ello: es la regla más importante de esta capa.

Qué no está terminado

Para que nadie lo descubra durante la integración:

• El puente de MousePlayer realiza consultas periódicas porque MousePlayer todavía no emite por sí mismo los eventos acordados.
• Los archivos adjuntos, las pruebas A/B y el dominio propio funcionan como beta: funcionan y se han medido, pero todavía pueden cambiar.
• Los canales de correo, Telegram, SMS, WhatsApp, Messenger e Instagram se han probado con servicios simulados, todavía no con cuentas reales. Si una respuesta a través de un canal falla definitivamente, la conversación todavía no lo muestra.

Más información en la documentación

Cómo se coordinan el widget, el servidor y la conexión: Arquitectura y funcionamiento. Conexión, alternativa HTTP y reconexión: Transporte. Todos los capítulos: documentación.