Scopri in che modo PubConsent CMP ha ridotto l'INP per i propri clienti fino al 64% utilizzando una strategia di rendimento che utilizza le API Scheduler del browser per risolvere i problemi di reattività identificati con Chrome DevTools.
Le piattaforme di gestione del consenso (CMP) sono strumenti che aiutano i siti web a rispettare le normative sulla privacy ottenendo il consenso dell'utente per l'uso dei cookie e delle tecnologie di monitoraggio. Oltre all'obiettivo principale di garantire la conformità legale, le CMP, in quanto script di terze parti, devono anche garantire un impatto minimo sul rendimento e sull'esperienza utente.
La CMP di PubConsent è l'ultimo prodotto di PubTech. Progettata con un'attenzione particolare al rendimento, la CMP di PubConsent è progettata per essere leggera, garantire un'esperienza utente ottimale e un impatto minimo sul rendimento complessivo del sito web.
L'introduzione della metrica Interaction to Next Paint (INP) ha permesso a PubTech di scoprire problemi relativi alla reattività della nostra CMP. In questo case study, PubTech mostra come ha risolto i problemi di reattività nella piattaforma CMP di PubConsent e come ha migliorato l'INP prima che diventasse uno dei Segnali web essenziali a marzo 2024, dimostrando un impegno costante a fornire le migliori prestazioni possibili in un prodotto CMP.
Perché PubTech considera le prestazioni?
La CMP PubConsent, come la maggior parte delle CMP, offre la sua funzionalità di gestione del consenso implementata come script di terze parti nelle pagine del sito. Mitigare l'impatto sulle prestazioni della nostra offerta CMP, inclusa la reattività, è fondamentale per garantire il successo dell'integrazione della CMP.
Dando la priorità al rendimento e mantenendo leggero lo script CMP di PubConsent, i proprietari di siti web possono raggiungere un delicato equilibrio tra l'inclusione di preziose funzionalità di gestione del consenso e la salvaguardia della qualità dell'esperienza utente.
Data l'importanza della funzionalità fornita da una CMP e l'impatto che può avere sulle prestazioni, PubTech ha fissato i seguenti obiettivi:
- Riduci al minimo l'impatto del prodotto CMP di PubConsent sull'INP.
- Ridurre le attività lunghe attribuibili al prodotto CMP.
- Riduci il Tempo di blocco totale (TBT), che può avere un effetto negativo sull'INP di una pagina.
Come è stata misurata l'INP
PubTech ha utilizzato Chrome DevTools per eseguire un'analisi iniziale e diagnosi manualmente le interazioni lente. Questo flusso di lavoro ha permesso a PubTech di individuare problemi specifici che interessavano la reattività della pagina. Ad esempio, un'interazione tramite clic all'interno del prodotto CMP per accettare tutti i cookie e quindi ignorare la finestra di dialogo per il consenso all'uso dei cookie ha causato un'attività lunga che ha ritardato un aggiornamento del rendering dell'interfaccia utente. Come puoi vedere dall'immagine seguente, l'interfaccia utente non è stata aggiornata per indicare che la finestra di dialogo è stata chiusa fino al completamento della lunga attività.
Come il pulsante per accettare tutti i cookie, anche quello per rifiutare tutti i cookie o personalizzare le preferenze relative ai cookie segue lo stesso flusso di lavoro nell'architettura della CMP di PubConsent. Per questo motivo, i miglioramenti descritti in questo case study hanno influito su una serie di interazioni degli utenti nella CMP.
Questo ritardo ha portato alla percezione visiva del pannello che era in uno stato bloccato durante l'attività. Poiché ha bloccato l'aggiornamento del rendering per un periodo di tempo percepibile a lungo, l'INP della pagina ha subito un impatto negativo.
In che modo PubTech ha ottimizzato INP per pulsanti e link
Per migliorare l'INP, sono state adottate diverse strategie di rendimento nella CMP di PubConsent.
Rendi attività ad alta priorità
Il metodo yieldToMainUiBlocking mostrato nel seguente snippet di codice è progettato per ottimizzare le attività JavaScript ad alta priorità generando con scheduler.yield, se disponibile, per poi tornare a postTask con priorità user-blocking (alta) se postTask è disponibile, per poi tornare a niente.
setTimeout è stato evitato in questo caso perché il metodo yieldToMainUiBlocking è progettato per gestire le operazioni interne relative alle impostazioni della CMP e il lavoro ad alta priorità che deve mantenere questa priorità durante il rendimento. Questo significa che solo i browser che implementano queste API di pianificazione, che al momento sono disponibili solo nei browser basati su Chromium, traggono vantaggio dai miglioramenti descritti in questo case study. Anche così, questo approccio era considerato un miglioramento progressivo accettabile per queste attività ad alta priorità.
function yieldToMainUiBlocking () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
}
}
resolve(false);
});
};
Rendimento per attività di medie dimensioni e in background
Il metodo yieldToMainBackground mostrato nello snippet di codice riportato di seguito viene utilizzato per suddividere le attività lunghe con priorità user-visible (media) o background. La logica implementa scheduler.yield() se disponibile, ma si differenzia utilizzando postTask con priorità media per poi tornare a setTimeout sui browser non Chromium.
function yieldToMainBackground () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
}
}
setTimeout(() => { resolve(true) }, 0);
});
};
yieldToMainBackground consente al browser di eseguire il rendering del successivo Paint (chiudendo l'interfaccia utente della CMP in questo caso) più rapidamente.
In che modo PubTech ha ridotto ulteriormente TBT con l'ottimizzazione del layout del rendering
In seguito all'applicazione della strategia di rendimento, è emerso che il numero di INP era migliorato in modo significativo per la CMP. Infatti, dopo aver ridotto in modo significativo la durata di elaborazione del gestore di eventi, è stata scoperta l'opportunità di apportare ulteriori miglioramenti del rendering per la visualizzazione successiva dell'azione Close UI. Questa azione è stata originariamente progettata per rimuovere elementi dal DOM. Ciò ha causato problemi, in particolare sui siti web con un numero elevato di nodi DOM, con un conseguente aumento imprevisto del lavoro di rendering.
Per far fronte all'aumento del lavoro di rendering necessario per rimuovere gli elementi dal DOM, è stata introdotta una soluzione chiamata "derendering lento". Questo approccio applica inizialmente una regola CSS display: none alla finestra di dialogo per il consenso della CMP dopo che l'utente ha acconsentito a nasconderla. Successivamente, la rimozione dei nodi DOM associati alla finestra di dialogo CMP viene spostata in un momento successivo in cui il browser è inattivo utilizzando requestIdleCallback. Questo approccio si è rivelato molto più rapido rispetto alla rimozione dei nodi DOM nel momento in cui l'utente ha chiuso la finestra di dialogo per il consenso.
In che modo PubTech ha ridotto ulteriormente l'INP migliorando la libreria TCF di IAB
Dopo aver risolto con successo la maggior parte dei problemi di reattività della CMP, sono state individuate ulteriori opportunità di miglioramento in una delle sue principali dipendenze: la libreria TCF (Transparency and Consent Framework) di IAB.
I componenti più costosi dal punto di vista del calcolo di questa libreria erano le stringhe di build e l'invio del consenso. Questi componenti sono parte integrante della libreria TCF di IAB. Le seguenti ottimizzazioni a questi componenti sono state applicate in un fork separato appositamente per le esigenze di PubTech:
- Riutilizzo dei risultati calcolati per il processo di decodifica, che viene eseguito per ogni callback di terze parti che deve leggere il consenso dell'utente.
- Sono stati evitati e ridotti i loop non necessari nel processo di codifica delle limitazioni per i publisher, che viene eseguito quando l'utente dà il consenso.
La prima di queste ottimizzazioni ha ridotto il tempo impiegato dalla CMP su ogni callback di terze parti che si collega alla libreria TCF di IAB. La seconda ottimizzazione ha ridotto la durata dell'elaborazione sostenuta dal componente "Stringhe di build". In effetti, questa ottimizzazione ha consentito una riduzione fino al 60% dei loop eseguiti ogni volta che un utente esprimeva il consenso.
Risultati
Grazie alle strategie precedentemente efficaci e alle nuove ottimizzazioni del layout di rendering, l'INP della CMP è migliorato fino al 65%. Di conseguenza, la reattività dell'esperienza utente della CMP di PubConsent è stata notevolmente migliorata e, per alcuni annunci, la visibilità è persino migliorata dell'1,5% ottimizzando il momento in cui vengono richiesti gli annunci.
Oltre a questi miglioramenti, nella libreria TCF di IAB è stato osservato che l'INP è migliorato fino al 77% sui dispositivi mobili per i clienti interessati grazie alla riduzione delle attività lunghe indotte dal TCF fino all'85%. Ciò ha contribuito a ridurre significativamente il sovraccarico di ogni callback di terze parti eseguito durante l'intero ciclo di vita di una pagina.
Il numero di origini che trasmettono l'INP quando si utilizza la CMP di PubConsent è migliorato di oltre il 400%, passando dal 13% al 55% sui dispositivi mobili. Per alcuni clienti, l'INP della pagina è dimezzato (da 470 a 230 millisecondi) grazie alle ottimizzazioni dell'SDK PubTech apportate.
Conclusione
I clienti di PubTech sono stati in grado di riconoscere rapidamente i risultati positivi delle metriche INP e delle metriche aziendali derivanti dai nostri sforzi di ottimizzazione. Stiamo prendendo in considerazione ulteriori miglioramenti delle prestazioni per la CMP di PubConsent, sfruttando gli inestimabili dati di monitoraggio degli utenti reali (RUM) dei loro clienti. Questi dati monitorano da vicino sia le regressioni che i progressi, portando all'impegno continuo di PubTech per il miglioramento.
PubTech, in qualità di terza parte, si è anche resa conto di avere l'opportunità di migliorare le prestazioni web su larga scala e di fornire una migliore reattività, il tutto evitando impatti negativi sui KPI di business. Non è mai troppo tardi per iniziare a implementare questi tipi di miglioramenti.
Un ringraziamento speciale a Luca Coppola, CTO di PubTech per il supporto a questo lavoro di innovazione, e a Jeremy Wagner, Michal Mocny e Rick Viscomi di Google.