El banner de consentimiento carga antes de que muchas personas vean el producto, por eso forma parte del rendimiento percibido. Benchmarks citados por el ecosistema de c15t informaron 30 ms de LCP para c15t y 491 ms para OneTrust, con bundles de 0,6 KB y 1,1 KB. Hay que reproducirlos en el sitio objetivo, pero exponen una categoría que suele quedar fuera de la optimización.
c15t es open source y headless. La aplicación controla la interfaz y tiene integraciones para React, Next.js, Vue, Svelte, Astro, GTM, PostHog y píxeles publicitarios. Soporta SSR, opt-in estricto, geolocalización, logs e internacionalización, con licencia GPL-3.0 y ejecución en el dominio propio.
La comparación tiene un límite duro. OneTrust es una suite de gobierno de privacidad con revisión legal, scanning de cookies, informes y soporte. Una capa ligera no sustituye esos servicios de forma automática. Compite cuando el requisito real es orquestar consentimiento con control y sin un runtime externo pesado.
Medir el banner en la misma prueba que el resto del LCP
Los 30 ms de c15t y los 491 ms de OneTrust vienen de CookieBench. Sirven para mostrar que el script de consentimiento entra en el LCP. No cierran la decisión solos. El número que importa es el de tu sitio, en la primera visita, con caché fría, en la geografía donde llega el tráfico.
En ese recorte el banner compite con el hero, las fuentes y cualquier tag que marketing ya puso en el <head>. Si el equipo ya trabaja con un techo de LCP en móvil, el CMP tiene que caber ahí. Medir solo la home autenticada, o solo la visita que ya aceptó cookies, esconde el pico: ocurre en el visitante nuevo.
Además del LCP, mira origen de las peticiones, el handshake TLS extra, bytes de JavaScript en el hilo principal y el INP del propio diálogo. c15t entra como paquete en el bundle de la aplicación. OneTrust, en el benchmark citado, llega como runtime de terceros. La diferencia práctica está ahí: uno pasa por tu build, el otro abre una conexión nueva antes del contenido.
Repite la prueba después de cada cambio en GTM. Equipos que recortan KB en la app y dejan el contenedor de tags suelto pierden la ganancia a la semana siguiente. Datos de campo (CrUX o RUM) confirman el laboratorio; el laboratorio solo arma una diapositiva.
Quién guarda el registro cuando el script deja el CDN
Sacar el CMP de un dominio de terceros cambia el lugar de la prueba. c15t puede correr en tu dominio, con audit logging y geo-detection. Eso ayuda. También trae la pregunta a casa: dónde vive el registro, durante cuánto tiempo, quién lo consulta después de un incidente, qué versión de la política estaba vigente en ese clic.
Guardar la elección solo en el navegador cubre preview y sitio estático. No responde, solo, a un pedido de evidencia de opt-in de un usuario concreto meses después. Si el equipo necesita ese rastro, necesita backend propio, el hosted de c15t u otro sistema de registro. Esa elección es de datos, no de CSS del banner.
La UI headless ayuda al design system. No escribe la política. Alguien todavía redacta las categorías (necesario, analytics, marketing), el texto, el comportamiento para menores y qué ocurre cuando la persona rechaza. Sin eso el componente queda alineado al layout y el sitio sigue disparando el pixel.
Nombra un responsable de política, uno de implementación y uno de auditoría. Si los tres son "el frontend", el registro se pudre en localStorage hasta el primer cuestionario de un cliente enterprise.
Pixels y GTM cargan solo después de la elección
El repositorio lista integración con GTM, PostHog, Meta Pixel, TikTok y LinkedIn. El valor aparece solo si la carga está condicionada. Un contenedor GTM con tags en All Pages ignora el banner, sea cual sea la biblioteca.
La regla es tediosa de auditar: ningún script de medición o anuncio sube antes del opt-in explícito, en el recorte GDPR que el producto adoptó. Eso incluye la tag "solo de prueba", el chat de terceros y el heatmap. La revisión tiene que mirar el HTML inicial, el GTM y los imports que suben SDK en el cliente.
Si marketing depende de Consent Mode v2, el cambio de CMP tiene que preservar las señales denied por defecto y la actualización después de la elección. Si no, el rendimiento mejora y la atribución se rompe. O la atribución sigue y el opt-in se vuelve teatro.
Tree-shaking y TypeScript reducen superficie en el bundle. El inventario de tags sigue cabiendo en una tabla con origen, categoría de consentimiento y dueño. Sin dueño, la tag vuelve. El SSR de c15t evita un flash de banner sin estado; no impide que un useEffect huérfano importe el pixel.
La suite de privacidad cubre un trabajo que el banner no hace
OneTrust, en la práctica de mercado, es una plataforma de gobierno: revisión jurídica, scanning de cookies, informes, soporte. c15t no promete ese paquete. Si legal ya opera sobre esos informes, quitar la suite porque el LCP está alto abre un hueco al día siguiente.
Se pueden separar las piezas. Banner y orquestación en el frontend; scanning y lista de vendors en otra herramienta; DSR y contratos donde ya están. Rendimiento, prueba de consentimiento y dictamen jurídico son tres costos. c15t compite en el primero y, con backend, en el segundo. En el tercero, solo si el equipo interno absorbe el trabajo.
Antes del npm install, legal lee la licencia del repositorio y el DPO describe qué considera prueba suficiente. Sin esa conversación, ingeniería optimiza milisegundos y compliance descubre el cambio el trimestre siguiente, encima de un cuestionario de cliente.
Criterio para salir del script de terceros este trimestre
El cambio entra en el sprint cuando coinciden cuatro cosas: RUM o CrUX muestra LCP malo en la primera visita; el frontend ya es dueño del <head>; legal acepta el registro en el stack de la aplicación; existe dueño para el inventario de tags. Si falta la tercera, el equipo gana milisegundos y pierde la narrativa de compliance.
Empieza por un sitio, no por todos. Compara una semana de campo antes y después, en el mismo canal de tráfico. Si el LCP de primera visita no se mueve, quizá el CMP no era el villano. Si se mueve y los pixels siguen disparando sin opt-in, el cambio fue cosmético.
Las estrellas en GitHub y un release de marzo de 2026 dicen que el proyecto está activo. No dicen que el soporte va a atender a tu DPO en el plazo de un incidente. El presupuesto de rendimiento y el de riesgo jurídico tienen que estar en la misma reunión. Sin eso cada área optimiza su métrica y el banner sigue siendo el script que nadie cuestiona.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
