Widget de chat con Core Web Vitals perfectos

Cómo cargar un widget de chat de la forma correcta

Lo he dicho una y otra vez. Algunos scripts son más importantes que otros. Nadie en la historia de internet se ha molestado nunca porque un widget de chat no se haya cargado en los primeros 500ms de carga de la página. Ese momento en el que la página todavía está en blanco.

No tendría ningún sentido, ¿verdad?, cargar un widget de chat antes de que el contenido principal de la página haya siquiera comenzado a cargarse. No, tendría mucho más sentido cargar primero las partes más importantes (tu logotipo, tu imagen principal, tus hojas de estilo, tus fuentes, tal vez algunos scripts súper importantes que manejan la navegación y la conversión).

Los estudios muestran que solo entre el 3 y el 10 por ciento de los visitantes usan realmente un widget de chat durante su sesión. Diferir el script de chat no te cuesta nada en términos de user experience, pero te hace ganar todo en términos de velocidad de página.

Desafortunadamente, esta no es la forma en que la mayoría de los sitios web hacen las cosas. A diario veo scripts sin importancia (como scripts de chat) cargarse con la máxima prioridad inmediatamente al inicio de la carga de la página.

En este artículo explicaré cómo cargar correctamente un script de chat y cómo esto afecta a métricas importantes como el Largest Contentful Paint y el Interaction to Next Paint.

Última revisión por Arjen Karel en febrero de 2026

Contexto: cómo funcionan los widgets de chat

Un widget de chat generalmente funciona cargando un pequeño script en tu página. Ese script cargará algunos estilos e inyectará un iframe en tu página. Un iframe es una pequeña página web aislada dentro de una página web. Y ese iframe manejará todo lo que necesita para chatear con tus clientes.

¿Cómo afectan los widgets de chat a los Core Web Vitals?

Los widgets de chat afectan a los Core Web Vitals de varias maneras:

1. Afectan el First Contentful Paint y el Largest Contentful Paint al competir por recursos de red tempranos.

2. Afectan el Interaction to Next Paint bloqueando el hilo principal y, a veces, actualizándose lentamente después de la interacción.

3. Pueden causar layout shifts cuando no se renderizan correctamente en la página.

El impacto varía mucho entre proveedores. Los widgets de chat más pesados (Zendesk, Tawk.to) cargan de 500 a 750 KB de JavaScript. Alternativas más ligeras como Zoho Desk y Crisp se mantienen por debajo de los 155 KB. En promedio, un widget de chat agrega de 300 a 600 ms de tiempo de bloqueo del hilo principal. Eso es suficiente para empujar una puntuación de INP que de otro modo pasaría al rango de "necesita mejora".

Problemas de Largest Contentful Paint causados por widgets de chat

Un widget de chat puede afectar a los Core Web Vitals cuando compite por los recursos de la red. Los archivos JavaScript normalmente se ponen en cola para su descarga antes que las imágenes. Esto significa que, en el peor de los casos (cuando el script del chat bloquea el renderizado), el navegador tiene que esperar a que el script del chat se descargue y se ejecute antes de poder continuar con cualquier otra cosa. Un widget de chat que bloquea el renderizado puede duplicar el First Contentful Paint de 1.0 segundos a más de 2.3 segundos.

Incluso cuando el script de chat se difiere, aún puede impactar las métricas de renderizado de varias maneras. Primero déjame explicarte qué hacen los scripts diferidos. El navegador puede descargar scripts diferidos en paralelo y el navegador puede continuar renderizando hasta el evento DOMContentLoaded. Después de eso, ejecutará los scripts. El problema es que para los visitantes recurrentes, el elemento de LCP probablemente no se cargará en el evento DOMContentLoaded, sino que el script de chat (en caché) se ejecutará causando un retraso en las métricas de LCP.

Problemas de Interaction to Next Paint (INP) causados por widgets de chat

Un widget de chat puede impactar y de hecho impactará el Interaction to Next Paint de 2 maneras. La primera manera es bloqueando el hilo principal por un corto tiempo mientras el widget de chat ejecuta sus scripts o comprueba actualizaciones. Así es simplemente como funcionan las cosas. Todo lo que agregues a una página la ralentizará un poco.

La segunda manera en que puede causar problemas de INP es por mala codificación (y créeme, hay algunos widgets de chat mal codificados por ahí). Cuando se trata de widgets de chat, "más popular" no significa "mejor codificado". Cuando un código deficiente tarda mucho en actualizar la presentación, automáticamente tendrás problemas de INP. Supongo que algunos proveedores de chat necesitan mejorar. Esta parte desafortunadamente está fuera de mi control. Si has elegido un widget de chat mal codificado, no hay manera de que yo pueda mejorar ese código.

Problemas de layout shift (CLS) causados por widgets de chat

A veces los widgets de chat causan un layout shift. Hay 3 sospechosos habituales que busco cuando compruebo layout shifts relacionados con widgets de chat.

• Layout shifts que ocurren cada vez que se carga el chat
• Layout shifts que ocurren en una "apertura de chat" retrasada
• Layout shifts que ocurren cuando se carga un historial de chat (visitante de chat recurrente)

Cómo solucionar problemas de Core Web Vitals causados por scripts de chat

Afortunadamente es bastante fácil minimizar el impacto que un widget de chat puede tener en las métricas de renderizado (LCP y FCP) y en algunas partes del Interaction to Next Paint (INP). En mi declaración inicial te dije que los scripts tienen un momento y un lugar. Y para los scripts de chat ese no es "de inmediato y a toda costa". Me gusta cargar los scripts de chat después del evento load, cuando la página no está respondiendo a la entrada del usuario y también me gusta omitir el escáner de precarga para evitar la competencia en la red.

Entonces, ¿cómo lo hacemos? Usamos el evento load porque cuando se ha disparado el evento load, el elemento de LCP se habrá pintado en la página (a menos que lo hayas cargado de forma diferida con JavaScript). Usamos requestIdleCallback para esperar un momento inactivo cuando el navegador no está respondiendo a la entrada del usuario. Y usamos JavaScript para inyectar el script del chat y asegurarnos de que el escáner de precarga no reconozca el src del script inmediatamente y active una descarga temprana (y eso es exactamente lo que queremos evitar). Este es el mismo patrón de aplazamiento de scripts utilizado para las incrustaciones de YouTube y Google Maps.

<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>

Ten en cuenta que requestIdleCallback no es compatible en Safari. Usa un fallback: const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1)); y reemplaza requestIdleCallback por idle en el ejemplo anterior.

Con este patrón de evento load más requestIdleCallback, el impacto de un widget de chat en la puntuación de Lighthouse se reduce de 9 a 16 puntos a 0 a 1 punto.

Alternativa: carga basada en interacción

En lugar de cargar el widget de chat automáticamente después del evento load, puedes esperar hasta que el visitante interactúe realmente con la página. Escucha mousemove, scroll o touchstart y carga el script del chat en el primer evento. Esto garantiza un impacto cero en todos los Core Web Vitals para los visitantes que nunca se desplazan o interactúan.

<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>

Solucionar problemas de Cumulative Layout Shift causados por widgets de chat

Los widgets de chat normalmente causarán un pequeño layout shift. Eso no tiene por qué ser un gran problema. Pero a veces los widgets de chat simplemente se renderizan mal. Afortunadamente, también podemos (más o menos) solucionar eso ocultando el mal renderizado hasta que el widget haya terminado de renderizarse.

Para hacer esto necesitamos leer la documentación del widget de chat (hay muchos proveedores de chat diferentes y todos funcionan un poco diferente). En la documentación, busca las funciones callback que se llaman en diferentes etapas del renderizado del chat. Como no sé qué widget de chat estás utilizando, para ilustrar el mecanismo utilizaremos la función chat.ready().

Ahora, con un poco de estilo inteligente, podemos ocultar y mostrar el chat con la propiedad opacity de CSS. Primero agregamos algunas clases para ocultar el widget de chat de forma predeterminada (cambia los selectores para que coincidan con tu widget de chat). Luego, en el callback chat.ready() agregamos "showchat" al classlist del body para activar la segunda línea CSS que muestra el chat nuevamente.

<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>

¡Eso es todo! Buena suerte acelerando tu widget de chat. Para verificar tus cambios con visitantes reales, configura el Real User Monitoring. Las puntuaciones de laboratorio son útiles para la depuración, pero los datos de campo de usuarios reales son lo que Google utiliza para el ranking.