Cómo un tracker de analytics de 2 KB mantiene tus Core Web Vitals en verde

Los Core Web Vitals son ahora una señal de posicionamiento. Un script de analytics lento ya no es solo un inconveniente — es un impacto directo en tu SEO y en la experiencia de cada visitante en una conexión lenta. La ironía de medir el tráfico de tu sitio con un script que lo degrada es real.

Lo que cuestan los scripts de analytics tradicionales

La etiqueta global de Google Analytics 4 tiene aproximadamente 45 KB transferidos. Hace varias solicitudes de red al cargar — a collect.js, al Measurement Protocol y a veces a scripts de funciones adicionales. En un dispositivo móvil con conexión 4G, eso es un retraso medible antes de que tu página sea interactiva.

El impacto aparece de tres maneras. Primero, la solicitud del script compite con tu contenido por el ancho de banda de la red. Segundo, cualquier ejecución síncrona bloquea el hilo principal. Tercero, cada evento de analytics posterior (inicio de sesión, page_view, engagement) dispara solicitudes salientes adicionales.

Cómo un tracker ligero cambia las matemáticas

El tracker de Monoid tiene menos de 2 KB minificado y comprimido. Se carga con un atributo async simple, lo que significa que el navegador lo descarga en segundo plano sin bloquear el análisis o renderizado del HTML. El Largest Contentful Paint no se ve afectado porque el script nunca está en la ruta crítica de renderizado.

Cuando se dispara un pageview, el tracker envía un único POST al endpoint de colección:

fetch('/collect', {
  method: 'POST',
  keepalive: true,
  body: JSON.stringify({ site_id, path, referrer, ... })
})

El flag keepalive: true es el detalle clave. Le indica al navegador que mantenga la solicitud activa incluso si el usuario navega antes de que se complete — el mismo mecanismo que usa la API navigator.sendBeacon, pero con soporte completo para JSON. Obtienes entrega confiable sin bloquear la navegación.

Los tres Core Web Vitals, uno a uno

Largest Contentful Paint (LCP) mide cuándo el contenido principal es visible. Un script async que no está en la ruta crítica no retrasa el LCP en absoluto. El tracker no manipula el DOM y no carga ninguna imagen.

Interaction to Next Paint (INP) mide la capacidad de respuesta a la interacción del usuario. Los event listeners del tracker son de solo lectura y ligeros — un único listener popstate para la navegación en SPAs. Sin tareas largas, sin layout thrashing.

Cumulative Layout Shift (CLS) mide el movimiento inesperado de diseño. El tracker no agrega ningún elemento al DOM, por lo que contribuye con cero layout shift.

Ejecutar una auditoría de Lighthouse

Si quieres cuantificar la diferencia, ejecuta una auditoría de Lighthouse en una página antes y después de agregar el tracker. No deberías ver ningún cambio en la puntuación de Rendimiento. El tracker aparecerá en el waterfall de red como un script async de carga tardía — pequeño, rápido y fuera de la ruta crítica.

Compara eso con una auditoría de GA4, donde Lighthouse a menudo marcará la etiqueta de analytics bajo "Reduce el impacto del código de terceros" y reportará un tiempo de bloqueo del hilo.

El rendimiento también es un argumento de privacidad

Hay una conexión entre el peso del script y la privacidad que vale la pena establecer claramente: los scripts de analytics pesados son pesados porque hacen más. Más seguimiento, más identificación de dispositivos, más perfilado de comportamiento. El tracker de 2 KB es pequeño porque solo recopila lo que necesita — un puñado de señales no personales por pageview.

Elegir analytics ligero no es un compromiso entre rendimiento e insight. Es reconocer que el peso extra en las herramientas tradicionales proviene de la recopilación de datos que probablemente no solicitaste. La familia amplia de navegador y el tipo de dispositivo se derivan en el servidor desde el User-Agent de la solicitud; User-Agent completos, versiones de navegador, cookies, identificadores persistentes y fingerprints de dispositivo nunca se almacenan.