Come far caricare Axeptio più velocemente (senza rompere il consenso)

Su una connessione veloce d'ufficio, il banner Axeptio compare quasi subito. Su un telefono per strada, i visitatori leggono, scorrono e toccano lo schermo prima che appaia, a volte molto dopo la pagina stessa. Nel frattempo i suoi tag aspettano un consenso che non è ancora stato chiesto, e il banner piomba sopra una pagina che il visitatore sta già usando.

Axeptio raramente è colpevole da solo. Ciò che lo rallenta è il suo posto nella coda. Questa guida mostra di cosa ha bisogno il banner prima di poter comparire, cosa fa una pagina reale a questa catena e le leve che lo anticipano senza toccare ciò che il consenso richiede.

Cosa carica Axeptio prima che compaia il banner

Il banner è l'ultimo passo di una breve catena, e ogni passo aspetta il precedente:

1. Le impostazioni: un piccolo script inline che dichiara window.axeptioSettings (l'id del suo progetto e la versione dei cookie) e inietta l'SDK.
2. L'SDK, uno script servito da static.axept.io.
3. La configurazione del progetto: testi, fornitori e design, recuperati dall'SDK una volta avviato.
4. Gli stili e il font del widget, tra cui un foglio di stile per un web font servito da fonts.axept.io.
5. Il banner, mostrato quando tutto quanto sopra è arrivato.

Nessuno di questi file è pesante. Il problema è che su una pagina carica vengono richiesti mentre decine di altri file sono già in download, e su una connessione mobile lenta ogni richiesta in coda costa un viaggio di andata e ritorno.

Un caso reale: 16 secondi in Slow 4G

Abbiamo misurato una vera landing page WordPress costruita con un page builder, circa 150 richieste, con Axeptio installato. Protocollo: emulazione di un telefono a 390 × 844 pixel, cache del browser disattivata, nessun cookie di consenso, nessuna interazione, cinque esecuzioni per rete, mediane conservate.

• Senza limitazione: primo rendering a 0,57 s, banner in posizione a 1,42 s.
• Fast 4G: primo rendering a 1,32 s, banner in posizione a 3,12 s.
• Slow 4G: primo rendering a 5,72 s, banner in posizione a 15,98 s.

Sul profilo lento, il visitatore ha avuto dieci secondi di pagina prima che gli venisse chiesto qualcosa. Ogni tag in attesa del consenso ha aspettato con lui.

Una versione alleggerita della stessa pagina, con circa 80 richieste invece di 150, aveva il banner in posizione a 5,8 s in Slow 4G. Quella versione cambiava anche la presentazione del banner, quindi il confronto dà un ordine di grandezza più che un guadagno esatto. Il punto è proprio l'ordine di grandezza: dimezzare la concorrenza ha ridotto l'attesa di circa due terzi.

Leva 1: alleggerire ciò che fa concorrenza al banner

È la leva più grande, e non ha nulla a che vedere con le impostazioni di Axeptio. Guardi il pannello Network su un profilo mobile con rete limitata ed elenchi ciò che si carica prima del banner: fogli di stile del page builder usati su altri template, uno script di slider per uno slider sotto la piega, un widget di chat, diversi pixel di marketing, immagini a grandezza piena in fondo alla pagina.

• Ritardi gli script che non servono al caricamento (chat, pop-up, slider sotto la piega), lasciando lo strumento di consenso fuori dal ritardo (leva 2).
• Smetta di caricare risorse sui template che non le usano.
• Carichi in lazy load le immagini sotto la piega, mai l'immagine principale in alto.
• Riduca il CSS a ciò che la pagina usa, così in coda ci sono fogli di stile meno numerosi e più leggeri.

Ogni richiesta tolta dall'inizio del caricamento è un posto che la catena di Axeptio ottiene prima.

Leva 2: non ritardare mai lo strumento di consenso

Gli strumenti di performance che rimandano JavaScript fino alla prima interazione sono una causa frequente di un banner che compare solo dopo uno scroll o un tocco. Se le impostazioni inline o l'SDK sono ritardati, il banner aspetta che il visitatore si muova, e il consenso viene chiesto a cose fatte.

Aggiunga entrambi alle eccezioni del suo strumento di ritardo: lo script inline, che può individuare con axeptioSettings, e l'SDK, che può individuare con axept.io. Poi verifichi il risultato: ricarichi in una finestra privata, non tocchi nulla, e il banner deve comparire da solo. Il metodo generale per trovare cosa ha rotto un ritardo è nella nostra guida sul ritardo di JavaScript.

Leva 3: avviare presto la catena

Inserisca lo snippet di Axeptio in alto nell'<head>, non nel footer e non dietro un altro script che a sua volta aspetta. Poi prepari in anticipo la connessione verso l'host dell'SDK, così la prima richiesta non paga DNS e TLS oltre al suo posto in coda:

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

Limiti questi suggerimenti agli host di Axeptio che vede davvero nel pannello Network, e a uno o due in totale: ogni preconnect apre una connessione che a sua volta fa concorrenza.

Leva 4: il font che nessuno vede

Il widget inietta un foglio di stile per il proprio web font. Se il banner usa il font del suo sito, quella richiesta è puro spreco: un file in più in coda, e qualsiasi script che aspetta document.fonts.ready aspetta anche quel file. Sulla pagina misurata, una comparsa del banner che aspettava i font perdeva 600 ms in Slow 4G per un font mai visualizzato.

Se, e solo se, il banner non usa quel font, può rimuovere il foglio di stile appena viene inserito:

// Rimuove il foglio del font del widget appena viene aggiunto.
// Solo se il banner usa il suo font.
(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 });
})();

Verifichi nel pannello Network che non resti nessuna richiesta verso fonts.axept.io, e che il testo del banner venga reso nel suo font. Se il suo strumento di ritardo riscrive gli script inline, escluda anche questo.

Se personalizza il banner

Molti siti ridisegnano il banner per adattarlo al proprio brand. Tre regole evitano che questa personalizzazione le costi cara più avanti:

• Punti a riferimenti stabili. I nomi di classe del widget sono generati e cambiano da una versione all'altra. Punti a id come #axeptio_btn_acceptAll, o a un contenitore tramite il suo contenuto (per esempio div:has(> #axeptio_btn_acceptAll)), mai a una classe generata.
• Tenga i testi nel back office di Axeptio. Ciò che viene mostrato deve essere ciò che Axeptio registra come mostrato al visitatore. Riscrivere i testi in JavaScript fa divergere lo schermo e la prova del consenso.
• Reagisca alla scelta tramite l'SDK, non tramite il markup. Gli elementi del banner possono restare nella pagina dopo che il visitatore ha risposto, quindi aspettare che spariscano può voler dire aspettare per sempre. Ascolti invece l'SDK:

// Viene eseguito quando il visitatore ha scelto.
window._axcb = window._axcb || [];
window._axcb.push(function (sdk) {
  sdk.on('cookies:complete', function (choices) {
    // choices contiene i fornitori accettati dal visitatore.
  });
});

E se nasconde il pulsante flottante dei cookie, dia ai visitatori un altro modo per tornare alle proprie scelte, mostrato solo quando l'SDK lo espone:

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

Misurarlo come lo vive un nuovo visitatore

• Una finestra privata, così non viene impostato nessun cookie di consenso; con un cookie, il banner non compare mai e non si misura nulla.
• I DevTools con la cache disattivata e un profilo mobile con rete limitata, Slow 4G compreso.
• Non toccare nulla, e annotare quando il banner è sullo schermo, per esempio con gli screenshot del pannello Performance.
• Cinque esecuzioni per profilo e la mediana, come spiegato nella nostra guida sui dati di laboratorio e sul campo.
• Provi anche con un content blocker: se Axeptio è bloccato, la pagina deve restare utilizzabile e non aspettare mai un banner che non arriverà.

Con Mantys Core

In sintesi

• Il banner Axeptio è la fine di una catena di piccole richieste, e su una pagina carica quella catena aspetta il suo turno.
• Sulla pagina misurata, il banner impiegava 16 s in Slow 4G; con metà delle richieste, meno di 6 s.
• Alleggerire ciò che fa concorrenza, non ritardare mai lo strumento di consenso, caricarlo in alto nell'head ed eliminare il font che non si visualizza.
• Personalizzare tramite id stabili e il back office, e reagire alla scelta tramite l'SDK.
• Misurare come un nuovo visitatore: finestra privata, cache disattivata, mobile con rete limitata, nessuna interazione, più esecuzioni.