Cómo hacer que Axeptio cargue más rápido (sin romper el consentimiento)

Con una conexión rápida de oficina, el banner de Axeptio aparece casi al instante. En un móvil en la calle, los visitantes leen, hacen scroll y tocan la pantalla antes de que aparezca, a veces mucho después que la propia página. Mientras tanto, sus etiquetas esperan un consentimiento que todavía no se ha pedido, y el banner aterriza encima de una página que el visitante ya está usando.

Axeptio rara vez es el culpable por sí solo. Lo que lo retrasa es su lugar en la cola. Esta guía muestra lo que necesita el banner antes de poder aparecer, lo que una página real le hace a esa cadena y las palancas que lo adelantan sin tocar lo que exige el consentimiento.

Lo que carga Axeptio antes de que aparezca el banner

El banner es el último paso de una cadena corta, y cada paso espera al anterior:

1. Los ajustes: un pequeño script inline que declara window.axeptioSettings (el id de su proyecto y la versión de cookies) e inyecta el SDK.
2. El SDK, un script servido desde static.axept.io.
3. La configuración del proyecto: textos, proveedores y diseño, que el SDK descarga en cuanto se ejecuta.
4. Los estilos y la fuente del widget, incluida una hoja de estilos de fuente web servida desde fonts.axept.io.
5. El banner, que se muestra cuando todo lo anterior está listo.

Ninguno de estos archivos pesa mucho. El problema es que, en una página cargada, se piden mientras decenas de otros archivos ya se están descargando, y con una conexión móvil lenta cada petición en la cola cuesta un viaje de ida y vuelta.

Un caso real: 16 segundos en Slow 4G

Medimos una landing page real de WordPress construida con un page builder, unas 150 peticiones, con Axeptio instalado. Protocolo: emulación de móvil a 390 × 844 píxeles, caché del navegador desactivada, sin cookie de consentimiento, sin interacción, cinco ejecuciones por red, conservando las medianas.

• Sin limitación: primer renderizado a los 0,57 s, banner en su sitio a los 1,42 s.
• Fast 4G: primer renderizado a los 1,32 s, banner en su sitio a los 3,12 s.
• Slow 4G: primer renderizado a los 5,72 s, banner en su sitio a los 15,98 s.

En el perfil lento, el visitante ha tenido diez segundos de página antes de que se le pregunte nada. Cada etiqueta que esperaba el consentimiento esperó con él.

Una versión simplificada de la misma página, con unas 80 peticiones en lugar de 150, tenía su banner en su sitio a los 5,8 s en Slow 4G. Esa versión también cambiaba la presentación del banner, así que la comparación da un orden de magnitud más que una ganancia exacta. Y el orden de magnitud es lo que cuenta: reducir la competencia a la mitad recortó la espera en unos dos tercios.

Palanca 1: aligerar lo que compite con el banner

Es la palanca más grande, y no tiene nada que ver con los ajustes de Axeptio. Mire el panel Network con un perfil móvil con red limitada y anote lo que carga antes del banner: hojas de estilos del page builder usadas en otras plantillas, un script de slider para un slider que está por debajo de la primera pantalla, un widget de chat, varios píxeles de marketing, imágenes a tamaño completo muy abajo en la página.

• Retrase los scripts que no hacen falta en la carga (chat, pop-ups, sliders por debajo de la primera pantalla), dejando la herramienta de consentimiento fuera del retraso (palanca 2).
• Deje de cargar recursos en las plantillas que no los usan.
• Aplique lazy loading a las imágenes por debajo de la primera pantalla, nunca a la imagen principal de arriba.
• Recorte el CSS a lo que usa la página, para que haya menos hojas de estilos, y más pequeñas, en la cola.

Cada petición que quita del inicio de la carga es un hueco que la cadena de Axeptio obtiene antes.

Palanca 2: no retrasar nunca la herramienta de consentimiento

Las herramientas de rendimiento que posponen JavaScript hasta la primera interacción son una causa frecuente de un banner que solo aparece tras un scroll o un toque. Si los ajustes inline o el SDK están retrasados, el banner espera a que el visitante se mueva, y el consentimiento se pide a posteriori.

Añada ambos a las excepciones de su herramienta de retraso: el script inline, que puede identificar por axeptioSettings, y el SDK, que puede identificar por axept.io. Después compruebe el resultado: recargue en una ventana privada, no toque nada, y el banner debe aparecer solo. El método general para encontrar lo que ha roto un retraso está en nuestra guía sobre el retraso de JavaScript.

Palanca 3: arrancar la cadena pronto

Coloque el snippet de Axeptio arriba en el <head>, no en el pie de página ni detrás de otro script que a su vez espera. Después precaliente la conexión con el host del SDK, para que la primera petición no pague DNS y TLS además de su lugar en la cola:

<link rel="preconnect" href="https://static.axept.io">

Limite las indicaciones a los hosts que realmente ve en el panel Network para Axeptio, y a uno o dos en total: cada preconnect abre una conexión que también compite.

Palanca 4: la fuente que nadie ve

El widget inyecta una hoja de estilos para su propia fuente web. Si su banner usa la fuente de su sitio, esa petición es puro desperdicio: un archivo más en la cola, y cualquier script que espere a document.fonts.ready también la espera. En la página que medimos, una aparición del banner que esperaba a las fuentes perdió 600 ms en Slow 4G por una fuente que nunca se mostró.

Si, y solo si, su banner no usa esa fuente, puede eliminar la hoja de estilos en cuanto se inserta:

// Elimina la hoja de la fuente del widget en cuanto se añade.
// Solo si el banner usa su propia fuente.
(function () {
  function drop(node) {
    if (node.nodeType !== 1) return;
    if (node.tagName === 'LINK' && /fonts\.axept\.io/.test(node.getAttribute('href') || '')) { node.remove(); return; }
    if (node.querySelectorAll) node.querySelectorAll('link[href*="fonts.axept.io"]').forEach(function (l) { l.remove(); });
  }
  new MutationObserver(function (mutations) {
    mutations.forEach(function (m) { m.addedNodes.forEach(drop); });
  }).observe(document.documentElement, { childList: true, subtree: true });
})();

Compruebe en el panel Network que no queda ninguna petición a fonts.axept.io y que el texto del banner se muestra con su fuente. Si su herramienta de retraso reescribe los scripts inline, excluya también este.

Si personaliza el banner

Muchos sitios cambian el estilo del banner para adaptarlo a su marca. Tres reglas evitan que esa personalización le salga cara más adelante:

• Apunte a anclajes estables. Los nombres de clase del widget se generan y cambian entre versiones. Apunte a ids como #axeptio_btn_acceptAll, o a un contenedor por su contenido (por ejemplo div:has(> #axeptio_btn_acceptAll)), nunca a una clase generada.
• Mantenga los textos en el back office de Axeptio. Lo que se muestra debe ser lo que Axeptio registra como mostrado al visitante. Reescribir los textos en JavaScript hace que la pantalla y la prueba de consentimiento diverjan.
• Reaccione a la elección a través del SDK, no del marcado. Los elementos del banner pueden quedarse en la página después de que el visitante haya respondido, así que esperar a que desaparezcan puede ser esperar para siempre. Escuche al SDK en su lugar:

// Se ejecuta cuando el visitante ha elegido.
window._axcb = window._axcb || [];
window._axcb.push(function (sdk) {
  sdk.on('cookies:complete', function (choices) {
    // choices contiene los proveedores que el visitante aceptó.
  });
});

Y si oculta el botón flotante de cookies, dé a los visitantes otra forma de volver a sus preferencias, que solo se muestre cuando el SDK la ofrezca:

<a href="#" id="manage-cookies" hidden>Manage cookies</a>
<script>
  window._axcb = window._axcb || [];
  window._axcb.push(function () {
    var link = document.getElementById('manage-cookies');
    if (typeof window.openAxeptioCookies !== 'function' || !link) return;
    link.hidden = false;
    link.addEventListener('click', function (e) { e.preventDefault(); window.openAxeptioCookies(); });
  });
</script>

Medirlo como lo vive un visitante nuevo

• Una ventana privada, para que no haya cookie de consentimiento; con una cookie, el banner no aparece nunca y no mide nada.
• DevTools con la caché desactivada y un perfil móvil con red limitada, Slow 4G incluido.
• No toque nada y anote cuándo está el banner en pantalla, por ejemplo con las capturas del panel Performance.
• Cinco ejecuciones por perfil y la mediana, como se explica en nuestra guía sobre datos de laboratorio y de campo.
• Pruebe también con un bloqueador de contenido: si Axeptio está bloqueado, la página debe seguir siendo usable y no esperar nunca un banner que no va a llegar.

Con Mantys Core

En resumen

• El banner de Axeptio es el final de una cadena de pequeñas peticiones, y en una página cargada esa cadena espera su turno.
• En la página que medimos, el banner tardó 16 s en Slow 4G; con la mitad de peticiones, menos de 6 s.
• Aligere lo que compite, no retrase nunca la herramienta de consentimiento, cárguela arriba en el head y prescinda de la fuente que no muestra.
• Personalice mediante ids estables y el back office, y reaccione a la elección a través del SDK.
• Mida como un visitante nuevo: ventana privada, caché desactivada, móvil con red limitada, sin interacción, varias ejecuciones.