Scopri come la CMP di PubConsent 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 degli utenti 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 sulle prestazioni e sull'esperienza utente.
CMPConsent CMP è il prodotto più recente di PubTech. Progettata con un'attenzione particolare alle prestazioni, la CMP di PubConsent è progettata per essere leggera, garantire un'esperienza utente ottimale e un impatto minimo sulle prestazioni complessive del sito web.
L'introduzione della metrica Interazione con Next Paint (INP) ha consentito a PubTech di scoprire problemi di reattività della nostra CMP. In questo case study, PubTech mostra come ha risolto i problemi di reattività nella sua piattaforma CMP PubConsent e come ha migliorato INP prima di diventare uno dei Core Web Vitals a marzo 2024, dimostrando l'impegno incessante a fornire le migliori prestazioni possibili in un prodotto CMP.
Perché a PubTech interessa 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 sulle pagine del sito. Ridurre l'impatto delle prestazioni della nostra offerta di CMP, inclusa la reattività, è fondamentale per garantire una corretta integrazione della CMP.
Dando la priorità al rendimento e mantenendo leggero lo script CMP di PubConsent, i proprietari di siti web possono trovare un delicato equilibrio tra l'integrazione di preziose funzionalità di gestione del consenso e al contempo la 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 su INP.
- Riduci 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 è stato misurato l'INP
PubTech ha utilizzato Chrome DevTools per condurre un'analisi iniziale e diagnosticare manualmente le interazioni lente. Questo flusso di lavoro ha consentito a PubTech di individuare problemi specifici relativi alla reattività delle pagine. Ad esempio, un'interazione con un clic all'interno del prodotto CMP per accettare tutti i cookie e successivamente chiudere 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 era stata chiusa fino al completamento dell'attività lunga.
Analogamente al pulsante per accettare tutti i cookie e al pulsante per rifiutare tutti i cookie o personalizzare le preferenze relative ai cookie, tutti seguono lo stesso flusso di lavoro nell'architettura CMP di PubConsent. Per questo motivo, i miglioramenti descritti in questo case study hanno influito su una serie di interazioni degli utenti nel prodotto CMP.
Questo ritardo ha comportato la percezione visiva del blocco dello stato del pannello durante l'attività. Poiché ha bloccato l'aggiornamento del rendering per un periodo di tempo percepito come lungo, l'INP della pagina è stato influenzato negativamente.
In che modo PubTech ha ottimizzato INP per pulsanti e link
Per migliorare l'INP, nella CMP di PubConsent sono state adottate diverse strategie di rendimento.
Fornire attività ad alta priorità
Il metodo yieldToMainUiBlocking mostrato nel seguente snippet di codice è progettato per ottimizzare le attività JavaScript ad alta priorità cedendo con scheduler.yield se disponibile, ma tornando a postTask con priorità user-blocking (alta) se postTask è disponibile, per poi ripristinare il valore zero.
setTimeout è stato evitato qui perché il metodo yieldToMainUiBlocking è progettato per gestire le operazioni delle impostazioni CMP interne e il lavoro ad alta priorità che dovrebbe 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 al momento della scrittura, traggono vantaggio dai miglioramenti descritti in questo case study. Ciononostante, questo approccio è stato ritenuto 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à medie e in background
Il metodo yieldToMainBackground mostrato nel seguente snippet di codice viene utilizzato per suddividere le attività lunghe con priorità user-visible (media) o background. La logica implementa scheduler.yield() se è disponibile, ma differisce dall'utilizzo di postTask con priorità media e, infine, da 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 permette al browser di eseguire il rendering della release successiva (in questo caso chiudendo la UI della CMP) prima.
Come PubTech ha ulteriormente ridotto le TBT con l'ottimizzazione del layout del rendering
Dopo aver applicato la strategia di rendimento, è emerso che 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 individuata l'opportunità di apportare ulteriori miglioramenti al rendering per la visualizzazione successiva dell'azione Chiudi UI. Questa azione è stata originariamente progettata per rimuovere elementi dal DOM. Questo ha posto dei problemi, soprattutto sui siti web con un numero considerevole di nodi DOM, con un conseguente aumento imprevisto del lavoro di rendering.
Per affrontare la maggiore quantità di lavoro di rendering necessario per rimuovere gli elementi dal DOM, è stata introdotta una soluzione che il team ha chiamato "de-rendering lazy". Questo approccio applica innanzitutto una regola CSS display: none alla finestra di dialogo per il consenso della CMP dopo che l'utente ha dato il consenso a nasconderla. Quindi, la rimozione dei nodi DOM associati alla finestra di dialogo CMP viene spostata in un momento successivo, quando il browser è inattivo, utilizzando requestIdleCallback. Questo approccio si è rivelato molto più rapido rispetto alla rimozione dei nodi DOM nel momento in cui l'utente chiudeva la finestra di dialogo per il consenso.
Come PubTech ha ridotto ulteriormente l'INP mediante il miglioramento della libreria TCF di IAB
Dopo aver risolto con successo la maggior parte dei problemi di reattività della CMP, sono state identificate ulteriori opportunità di miglioramento in una delle sue dipendenze principali: la libreria TCF (Transparency and Consent Framework) di IAB.
I componenti di questa libreria più costosi dal punto di vista del calcolo erano le "stringhe di build" e "invia consenso". Questi componenti sono parte integrante della libreria TCF di IAB. Le seguenti ottimizzazioni di 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 cicli 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 per ogni callback di terze parti che si collega alla libreria TCF di IAB. La seconda ottimizzazione ha ridotto la durata di elaborazione delle "stringhe di build" di strumento di authoring. In effetti, questa ottimizzazione ha consentito una riduzione fino al 60% dei loop eseguiti ogni volta che un utente ha espresso il consenso.
Risultati
Con le strategie di rendimento precedenti e le nuove ottimizzazioni del layout di rendering, l'INP della CMP è migliorato fino al 65%. Di conseguenza, l'esperienza utente della CMP di PubConsent è stata notevolmente migliorata e, per alcuni annunci, la visibilità è stata addirittura migliorata dell'1,5% mediante l'ottimizzazione quando vengono richiesti gli annunci.
Oltre a questi miglioramenti, nella libreria TCF di IAB è stato osservato che INP è migliorato fino al 77% sui dispositivi mobili per i clienti interessati grazie alla riduzione fino all'85% delle attività lunghe indotte dal TCF. In questo modo è stato possibile ridurre notevolmente l'overhead di ogni callback di terze parti eseguito durante l'intero ciclo di vita di una pagina.
Il numero di origini che superano 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 è stato ridotto di oltre la metà, da 470 millisecondi a 230 millisecondi, a causa delle ottimizzazioni dell'SDK PubTech.
Conclusione
I clienti di PubTech hanno riconosciuto rapidamente i risultati positivi delle prestazioni INP e delle metriche aziendali derivanti dai nostri sforzi di ottimizzazione, stanno prendendo in considerazione ulteriori miglioramenti delle prestazioni per la CMP di PubConsent, sfruttando inestimabili dati di monitoraggio degli utenti reali (RUM) dai loro clienti. Questi dati monitorano attentamente sia le regressioni che i progressi, guidando i continui sforzi di miglioramento di PubTech.
In qualità di terza parte, PubTech 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 aziendali. Non è mai troppo tardi per iniziare a implementare questo tipo 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.