In che modo la CMP PubConsent ha ridotto l'INP per i propri clienti fino al 64% utilizzando una strategia di rendimento che sfrutta le API Scheduler del browser per risolvere i problemi di reattività identificati utilizzando gli Strumenti per sviluppatori di Chrome.
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à alle normative, le CMP, in quanto script di terze parti, devono anche garantire un impatto minimo sul rendimento e sull'esperienza utente.
PubConsent CMP è l'ultimo prodotto 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 che diventasse uno dei Core Web Vitals a marzo 2024, dimostrando l'instancabile impegno a fornire le migliori prestazioni possibili in un prodotto CMP.
Perché PubTech si preoccupa del rendimento?
La CMP PubConsent, come la maggior parte delle CMP, offre la funzionalità di gestione del consenso implementata come script di terze parti nelle pagine del sito. Per garantire un'integrazione efficace della CMP, è fondamentale ridurre l'impatto sul rendimento della nostra offerta, inclusa la reattività.
Dando la priorità al rendimento e mantenendo leggero lo script della CMP PubConsent, i proprietari di siti web possono trovare un delicato equilibrio tra l'integrazione di funzionalità di gestione del consenso utili e il mantenimento della qualità dell'esperienza utente.
Data l'importanza della funzionalità fornita da una CMP e l'impatto che può avere sul rendimento, PubTech ha fissato i seguenti obiettivi:
- Riduci al minimo l'impatto del prodotto CMP PubConsent sull'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 eseguire 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.
Come il pulsante per accettare tutti i cookie, il pulsante per rifiutare tutti i cookie o personalizzare le preferenze relative ai cookie segue lo stesso flusso di lavoro nell'architettura della CMP 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 portato alla percezione visiva che il riquadro fosse in uno stato bloccato 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 l'INP per pulsanti e link
Per migliorare l'INP, nella CMP PubConsent sono state adottate diverse strategie di rendimento.
Genera attività ad alta priorità
Il metodo yieldToMainUiBlocking mostrato nel seguente snippet di codice è progettato per ottimizzare le attività JavaScript con priorità elevata restituendo scheduler.yield, se disponibile, ma tornando a postTask con priorità user-blocking (alta) se postTask è disponibile e infine tornando a nulla.
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. Ciò non significa che solo i browser che implementano queste API di pianificazione, che al momento sono disponibili solo nei browser basati su Chromium, beneficiano dei miglioramenti descritti in questo caso di studio. 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 nello snippet di codice seguente viene utilizzato per suddividere le attività lunghe con priorità user-visible (media) o background. La logica implementa scheduler.yield() se è disponibile, ma differisce per l'utilizzo di postTask con priorità media e infine per il passaggio 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 della release successiva (in questo caso chiudendo l'UI della CMP) prima.
In che modo PubTech ha ulteriormente ridotto il TBT con l'ottimizzazione del layout di rendering
Dopo aver applicato la strategia di rendimento, è emerso che l'INP è migliorato in modo significativo per la CMP. Infatti, dopo aver ridotto in modo significativo la durata dell'elaborazione del gestore eventi, è stata scoperta un'opportunità per apportare ulteriori miglioramenti al rendering per la successiva applicazione di pittura per l'azione Chiudi interfaccia utente. Questa azione è stata progettata originariamente per rimuovere elementi dal DOM. Ciò ha creato delle sfide, in particolare sui siti web con un numero elevato 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 prima una regola CSS display: none alla finestra di dialogo per il consenso della CMP dopo che l'utente ha dato il consenso per 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 è dimostrato molto più veloce della rimozione dei nodi DOM al momento in cui l'utente ha chiuso 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 la maggior parte dei problemi di reattività della CMP, sono state identificate ulteriori opportunità di miglioramento in una delle sue dipendenze principali: la libreria Transparency and Consent Framework (TCF) di IAB.
I componenti più dispendiosi in termini di risorse di calcolo di questa libreria erano "build strings" e "dispatch consent". Questi componenti sono parti integranti 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 la procedura di decodifica, che viene eseguita per ogni callback di terze parti che deve leggere il consenso dell'utente.
- Sono stati evitati e ridotti i cicli non necessari nella procedura di codifica delle limitazioni del publisher, che viene eseguita quando l'utente dà il consenso.
La prima di queste ottimizzazioni ha ridotto il tempo impiegato dalla CMP per ogni callback di terze parti collegato alla libreria TCF di IAB. La seconda ottimizzazione ha ridotto la durata di elaborazione richiesta dal componente "stringhe di creazione". Infatti, questa ottimizzazione ha consentito di ridurre fino al 60% dei loop eseguiti ogni volta che un utente esprimeva il consenso.
Risultati
Grazie alle strategie che hanno generato risultati in precedenza e alle 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 l'INP è migliorato fino al 77% sui dispositivi mobili per i clienti interessati a seguito della riduzione delle attività lunghe indotte dal TCF fino all'85%. In questo modo è stato possibile ridurre significativamente l'overhead 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 viene utilizzata la CMP PubConsent è migliorato di oltre il 400%, passando dal 13% al 55% sui dispositivi mobili. Per alcuni clienti, l'INP pagina è stato ridotto di oltre la metà, da 470 millisecondi a 230 millisecondi, grazie alle ottimizzazioni dell'SDK PubTech.
Conclusione
I clienti di PubTech hanno subito riconosciuto il rendimento positivo dell'INP e i risultati positivi delle metriche aziendali derivanti dai nostri sforzi di ottimizzazione. Sono in corso ulteriori miglioramenti del rendimento della CMP PubConsent, sfruttando i dati preziosi del monitoraggio dei real user (RUM) dei clienti. Questi dati monitorano attentamente sia le regressioni sia gli avanzamenti, contribuendo al miglioramento continuo di PubTech.
In qualità di terze parti, PubTech ha anche capito di avere l'opportunità di migliorare le prestazioni web su larga scala e offrire una maggiore reattività, il tutto evitando impatti negativi sui KPI aziendali. 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 progetto di innovazione e a Jeremy Wagner, Michal Mocny e Rick Viscomi di Google.