Addy Osmani

Le risorse di terze parti (come gli elementi incorporati e gli script) sono molto utilizzate oggi sul web. Forniscono soluzioni pronte all'uso per l'inserimento di social media, video, analisi, chat live, pubblicità, test A/B, personalizzazione e altro ancora. Gli elementi incorporati di terze parti sono una parte necessaria dei siti web moderni che consentono ai proprietari di siti di concentrarsi sulle loro competenze di base, sgravando al contempo le funzioni standard, ma fondamentali, a fornitori esterni.

Quando gli elementi proprietari e di terze parti di una pagina web funzionano in armonia, è possibile offrire un'esperienza utente ottimale. Tuttavia, questo richiede uno sforzo significativo da parte dei team di ingegneria e aziendali ed è spesso trascurato, con un conseguente calo del rendimento delle pagine web e un impatto negativo sulle metriche incentrate sugli utenti come i Core Web Vitals. Questo è dannoso per entrambe le parti e crea opportunità perse nelle aziende. Possiamo fare di meglio?

Abbiamo una visione futura del web in cui gli script e le risorse di terze parti forniscono il valore commerciale previsto con una regressione minima al rendimento o all'esperienza utente dei siti web che li utilizzano nel browser. In questo modo, gli utenti potrebbero usufruire di caricamenti di pagine più rapidi.

Nell'ultimo anno abbiamo preso in considerazione, discusso e sperimentato molte possibilità che possono potenzialmente proteggere l'esperienza utente dall'impatto dannoso degli script di terze parti senza ridurre il loro valore commerciale per i proprietari di siti.

Con questo post vogliamo condividere informazioni su alcuni dei nostri esperimenti. Ci auguriamo che questo sia l'inizio di un processo che incoraggi la trasparenza e la visibilità tra user agent, attività commerciali e fornitori di terze parti e apra la strada a un web più veloce.

Un approfondimento sulle terze parti

Una terza parte è una risorsa pubblicata da un fornitore esterno al sito. Non sono direttamente sotto il controllo dei proprietari del sito, ma sono presenti con la loro approvazione. Le risorse di terze parti sono:

• Ospitato su un'origine pubblica e condivisa diversa dall'origine del sito principale.
• Non sono stati creati o influenzati da un singolo proprietario del sito.
• Ampiamente utilizzato da una serie di siti.

Dall'aiuto per generare entrate (tramite gli annunci) alla fornitura di migliori opportunità di marketing (embed dei social media), le terze parti hanno una vasta gamma di obiettivi commerciali. Le categorie più comuni di terze parti includono:

Fonte: Terze parti per categoria.

Questi script e librerie di terze parti consentono agli sviluppatori web di sfruttare soluzioni collaudate per implementare funzionalità standard anziché reinventare la ruota. In questo modo, le terze parti riducono i tempi di sviluppo e aiutano le aziende a lanciare o aggiornare i propri prodotti più velocemente. Non sorprende quindi che oltre il 94% di tutti i siti web su computer e dispositivi mobili utilizzi terze parti.

In che modo le terze parti influiscono sul rendimento?

Idealmente, gli sviluppatori di terze parti sono esperti in materia per le funzionalità specifiche che forniscono. Le terze parti più utilizzate hanno subito diverse iterazioni e ci si può aspettare che il loro codice sia ottimizzato per i propri obiettivi commerciali, che possono o meno includere il rendimento delle pagine che li utilizzano. Tuttavia, sappiamo che anche le terze parti più ottimizzate influiscono sul rendimento. Ecco i motivi principali di questo impatto:

1. Dimensioni e costi di esecuzione dello script: spesso le terze parti mirano a fornire funzionalità significative "solo" inserendo un elemento <script> o <iframe> nella pagina. Questi elementi importano script e risorse di grandi dimensioni che richiedono più tempo per il download e l'esecuzione. Troppe istruzioni JavaScript mantengono occupato il thread principale più a lungo, bloccano il rendering e ritardano le interazioni degli utenti. È noto che alcune delle principali terze parti bloccano il thread principale da 42 ms a 1,6 s per oltre il 50% dei siti analizzati. Un thread principale bloccato comporta un tempo di blocco totale (TBT) elevato, che è una delle metriche che influiscono sul punteggio del rendimento del sito. Inoltre, ritarda la risposta alle interazioni degli utenti e peggiora la metrica Interaction to Next Paint (INP) utilizzata per misurare l'adattabilità dei siti web. Pertanto, i costi di esecuzione dello script hanno un impatto significativo sul rendimento.

2. Numero: in media, i siti web utilizzano circa 21 terze parti diverse su mobile e web. Spesso i tag di terze parti vengono aggiunti da strumenti di gestione dei tag che non sono controllati direttamente dai team tecnici/di sviluppo. I tag non obbligatori possono essere aggiunti da altri team senza una procedura di revisione e non vengono mai rimossi. Questi possono influire notevolmente sull'esperienza utente, sul peso della pagina o sull'utilizzo della CPU. L'implementazione di una procedura di governance può risolvere queste situazioni e consentire agli sviluppatori di verificare l'impatto di ciascun fornitore. Sarebbe utile se gli sviluppatori avessero a disposizione dati pronti per tutte le terze parti che forniscono una funzione specifica con il relativo impatto sul rendimento, i vantaggi e i compromessi per il confronto. Un'altra sfida che i team devono affrontare è che, per molti siti, i tag di terze parti vengono eseguiti solo in produzione, ma non negli ambienti di sviluppo, il che rende più difficile per gli sviluppatori testarli.

3. Rete: poiché le terze parti sono ospitate su origini diverse, i browser devono effettuare un numero maggiore di connessioni per scaricare i contenuti. Le diverse connessioni non possono coordinare il download in base alla priorità, causando contese sulla rete. Ciò può ritardare ulteriormente il caricamento della pagina se non vengono prese in considerazione le ottimizzazioni appropriate.

4. Sequenzialità: le terze parti possono bloccare il thread principale e competere per la larghezza di banda con risorse più critiche. Detto questo, in alcuni casi le terze parti sono le risorse fondamentali necessarie per il rendering della pagina. La sequenziazione ottimale delle risorse proprietarie e di terze parti diventa necessaria quando i siti web utilizzano più terze parti. Gli sviluppatori web devono essere a conoscenza delle diverse opzioni disponibili per ottimizzare la sequenziazione.

Di conseguenza, le terze parti possono influire su uno o tutti i componenti di Core Web Vitals. La maggior parte delle terze parti influisce negativamente su Largest Contentful Paint (LCP) e First Input Delay (FID). Gli elementi incorporati di YouTube bloccano il thread principale per 4,5 secondi nel 10% dei siti web su dispositivi mobili e per almeno 1,6 secondi nel 50% dei siti web esaminati. Immagina la frustrazione di un utente che trova una pagina con 20 di questi script su una connessione lenta. La seguente visualizzazione di thirdpartyweb.today mostra le terze parti con l'impatto maggiore sul rendimento al momento.

"Tra i circa 4 milioni di siti principali, circa 2700 origini rappresentano circa il 57% di tutto il tempo di esecuzione dello script, mentre le prime 50 entità rappresentano già circa il 47%". - third-party-web

Le pagine che vengono visualizzate rapidamente e diventano interattive in un lasso di tempo ragionevole sono essenziali per un'esperienza utente ottimale, misurata dai Core Web Vitals. Una buona UX si traduce spesso in un buon business per i siti web, il che può significare un buon business per le terze parti utilizzate. Collaborare per ridurre l'impatto delle terze parti può essere una vittoria per tutti gli attori della catena.

Google vende una serie di script di terze parti di uso comune, tra cui Google Tag Manager, gli embed di YouTube e ReCaptcha, solo per citarne alcuni. Siamo consapevoli che alcuni dei nostri script potrebbero avere un impatto sulle prestazioni più ridotto sui Core Web Vitals e ci impegniamo a esplorare i modi per migliorare questo impatto, ove possibile.

In che modo Chrome può aiutarti?

Le risorse di terze parti con un rendimento scadente rappresentano spesso una sfida per gli sviluppatori, che richiedono un cambiamento radicale nelle dinamiche dell'ecosistema sottostante. Chrome vuole esplorare questo spazio per ottenere i seguenti risultati:

1. Trovare modi migliori per caricare risorse di terze parti sul web senza peggiorare l'esperienza utente o i risultati aziendali.

   Sappiamo che non possiamo fare molto in questo senso se non collaboriamo con partner, aziende, terze parti e sviluppatori. Vogliamo creare un campo aperto per discutere delle possibilità ed scambiare idee tramite spiegazioni e specifiche pubbliche. Gli sviluppatori avranno il tempo di fornire feedback e testare l'impatto di molte di queste proposte.

2. Consenti agli utenti degli script di terze parti di avere una migliore attribuzione dei costi per gli strumenti e sul campo, percorsi chiari e ben definiti per il loro utilizzo e incentivi migliori durante la creazione per garantire che siano ottimali per impostazione predefinita.

   Vogliamo migliorare tutti i livelli, come gli user agent, i framework e gli script di terze parti, per ridurre l'impatto sulle prestazioni delle terze parti. Inoltre, intendiamo fornire informazioni sufficienti per aiutare i proprietari di siti a utilizzare le best practice per ogni script incorporato, incluse alternative più veloci, ove applicabili.

Approccio proposto

Proponiamo un approccio a tre livelli per raggiungere questi risultati…

1. **Offri agli sviluppatori un'attribuzione più approfondita dell'impatto di terze parti tramite RUM e gli strumenti per sviluppatori di Chrome.**

   Per RUM si intendono i dati delle metriche utente reali (noti anche come dati sul campo) disponibili tramite le API di monitoraggio delle prestazioni web. Gli strumenti per sviluppatori di Chrome includono Lighthouse, Chrome DevTools e il Rapporto sull'esperienza utente di Chrome. Proponiamo di migliorare le API e gli strumenti disponibili in modo che gli sviluppatori dei siti comprendano l'impatto di ogni entità di terze parti che hanno utilizzato su ogni pagina. Gli strumenti forniranno inoltre informazioni sulle azioni che possono intraprendere per mitigare l'impatto (ad esempio, rimandandole o utilizzando facades) ed esplorare altre potenziali soluzioni (altre terze parti o fai-da-te) con compromessi. Per le API di monitoraggio delle prestazioni web, stiamo esplorando i modi in cui possiamo espandere la loro copertura delle risorse cross-origin senza compromettere la privacy e la sicurezza dei nostri utenti.

2. **Offri alle aziende un percorso ben illuminato per caricare in modo efficiente le risorse di terze parti.**

   Vorremmo proporre nuovi standard che incoraggino i browser a fare compromessi in modo più intelligente tra il modo in cui vengono caricate le risorse proprietarie e di terze parti in nome di un'esperienza di caricamento migliore per gli utenti. In seguito, metteremo in evidenza alcune di queste proposte, come il caricamento lento degli elementi incorporati di terze parti per impostazione predefinita o l'applicazione di una diversa priorità alle risorse di terze parti che potrebbero non essere così importanti per i contenuti iniziali che interessano di più agli utenti. Queste sono solo alcune delle idee che stiamo valutando in questo ambito e ci piacerebbe collaborare con gli esperti di prestazioni web e con la community più ampia per dare forma a questo progetto.

   Analogamente, vorremmo risolvere questi problemi nei framework JavaScript e nei sistemi di gestione dei contenuti (CMS), ove più opportuno. Progetti come Aurora e il team di prestazioni di WordPress ci hanno insegnato l'importanza dei valori predefiniti integrati che risolvono i problemi di caricamento noti. I valori predefiniti integrati nei framework e nei CMS guidano le attività lungo un percorso ben illuminato. Possono essere utili anche all'agente utente (ad esempio Chrome) come suggerimenti che consentono di applicare l'euristica per ottimizzare il caricamento della pagina e il CWV. Questi suggerimenti possono aiutare lo user-agent a decidere quando e come caricare parti terze specifiche nel ciclo di vita della pagina. Ad esempio, il componente script di Next.js ha un valore predefinito integrato per caricare gli script di terze parti dopo che la pagina diventa interattiva.

3. **Offri alle terze parti incentivi per ridurre l'impatto sul rendimento tramite un maggiore impegno in termini di trasparenza.**

   Attualmente gli sviluppatori di terze parti non dispongono della visibilità necessaria per comprendere l'impatto dei loro script sui siti in generale. Abbiamo intenzione di risolvere il problema e di fornire a questi fornitori gli strumenti per analizzare il loro impatto e confrontarlo con quello di altri prodotti sul mercato che offrono lo stesso valore. Vogliamo anche aiutarli a utilizzare i dati per diagnosticare le cause dell'impatto in modo da poterle mitigare a monte. Per riuscire, dovremo chiamare tutte le terze parti, incluse quelle create da Google.

Sfide

Un impegno di queste dimensioni non è privo di sfide. Ecco alcune delle principali sfide che dobbiamo considerare.

• Le terze parti rappresentano un problema trasversale che coinvolge annunci, analisi, gestione dei tag, utilità e molti altri aspetti. Ogni area richiede la considerazione di un insieme unico di requisiti e compromessi. Ad esempio:
  • La decisione di ottimizzare il caricamento degli annunci dipende da un compromesso tra entrate ed esperienza utente. Se vengono mostrati troppo presto, bloccano contenuti di valore; se vengono mostrati troppo tardi, l'utente non riesce a vederli.
  • Gli script di Analytics aumentano il peso della pagina, ma forniscono all'attività dati importanti sulle azioni degli utenti.

Ci auguriamo di collaborare con varie categorie di terze parti, comprendere le sfumature in gioco, risolvere i compromessi e sviluppare incentivi che funzionino per tutti. Ci rendiamo conto che dobbiamo lavorare separatamente con le persone in ogni area affinché la nostra strategia sia efficace. Sono inclusi i nostri partner interni, come Google Tag Manager, Google Ads e YouTube.

1. Vogliamo fornire un'attribuzione più approfondita sia agli sviluppatori del sito sia a quelli di terze parti. Questo richiede uno sforzo coscienzioso per identificare i dati più pertinenti per la misurazione dell'impatto, attribuirli in modo accurato e granulare e indicare la strada giusta da seguire. In definitiva, il calcolo del rendimento di una determinata terza parte rispetto alla concorrenza deve essere trasparente per tutti.

2. Proponiamo di migliorare Chrome in modo che possa applicare ottimizzazioni che aiutano a trovare il giusto equilibrio per dare la priorità al caricamento delle risorse proprietarie rispetto a quelle di terze parti. Una modifica importante diventa disponibile come standard in tutti i browser, ma ci vuole tempo. Ad esempio, l'attributo loading per gli elementi <img> e <iframe> è disponibile in Chrome/Edge dal 2019, ma è diventato disponibile in Safari solo nel 2022. Fino a quando una funzionalità non viene standardizzata, gli utenti delle risorse di terze parti dovranno assicurarsi di averla ottimizzata anche per altri browser. Lo evidenzieremo nelle nostre indicazioni, se pertinente.

3. Per realizzare questo progetto, dovremo collaborare con partner e sviluppatori non solo per aiutarci a comprendere requisiti specifici, ma anche per testare soluzioni sperimentali su larga scala, fornire feedback, eseguire l'iterazione e improvvisare in base alle esigenze. Le modifiche dovranno essere pianificate, prevedendo un periodo di tempo ragionevole per i test e la valutazione.

Proposte iniziali relative agli standard

Abbiamo eseguito alcuni esperimenti iniziali per sviluppare funzionalità che possono essere attivate per ottimizzare il processo di caricamento di terze parti. Siamo soddisfatti dei risultati osservati e al momento possiamo discutere di due di queste funzionalità.

LazyEmbeds

In precedenza, Chrome caricava in modo lazy gli elementi <img> e <iframe> offscreen per gli utenti della modalità Lite. Questa funzionalità potrebbe essere estesa a tutti gli utenti per posticipare il caricamento degli elementi di <iframe> determinati come incorporamenti di terze parti finché l'utente non li scorre. In questo modo, potresti velocizzare il caricamento di altre parti della pagina, migliorare Core Web Vitals, ridurre l'utilizzo della memoria e risparmiare dati.

Ecco una demo che utilizza LazyEmbeds per il caricamento differito dei video di YouTube in una pagina. Un singolo video incorporato di YouTube aggiunge in genere 500-600 KB di codice JavaScript alla pagina. Abbiamo provato a ottimizzare un post del blog con 14 di questi video incorporati utilizzando LazyEmbeds. I risultati sono stati promettenti in termini di tempo di caricamento della pagina e risparmio di dati.

Per scoprire di più su questo lavoro, consulta la nostra spiegazione e il thread relativo all'intenzione di eseguire esperimenti e l'estensione dell'esperimento di blink-dev.

Rallentamento mirato di terze parti

Gli script di terze parti vengono spesso aggiunti da vari team senza procedure di supervisione olistiche. Il team tecnico di The Telegraph ha dichiarato che "tutti vogliono quel tag su una pagina che generi entrate per l'organizzazione". Ciò può aumentare continuamente l'onere della gestione dell'impatto sulle prestazioni.

La limitazione degli script di terze parti mirati propone di limitare tipi molto specifici di terze parti per mitigarne l'impatto. In questo modo, i browser potrebbero caricare in anticipo i contenuti principali e i componenti di terze parti critici, mentre quelli che possono essere caricati in un secondo momento vengono limitati.

Miglioramento delle API RUM

Stiamo anche valutando la possibilità di migliorare le API RUM per includere informazioni pertinenti per la valutazione del rendimento di terze parti. I miglioramenti includono:

1. Report <iframe>: stiamo lavorando a soluzioni che possono sfruttare l'API Performance Timeline per i report cross-frame. In questo modo, gli autori della pagina di primo livello potrebbero esaminare i dati sul rendimento di un iframe di terze parti che collabora e che è incorporato nella pagina.

2. Attribuzione delle attività lunghe: l'API Long Tasks in RUM aiuterà i proprietari di siti a identificare le attività lunghe che occupano il thread principale per molto tempo e ritardano l'interazione.

Ulteriori aggiornamenti

Stiamo ancora sperimentando molte di queste idee e ci auguriamo di pubblicare spiegazioni e bozze delle specifiche su GitHub per le modifiche man mano che procediamo. Terze parti e proprietari di siti che vogliono collaborare con noi o lasciare un feedback possono contribuire alle discussioni tramite questi canali. Anche le terze parti possono iniziare a concentrarsi sull'ottimizzazione per le metriche Core Web Vitals e INP per assicurarsi che i dati scadenti di Core Web Vitals/INP non vengano attribuiti a loro. Per il momento, chi cerca attivamente aggiornamenti può fare riferimento ai post del gruppo blink-dev.

Non vediamo l'ora di esplorare ulteriormente questo spazio di problemi e di condividere con la community ciò che impariamo.

Un ringraziamento speciale a Leena Sohoni-Kasture, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara, Alex N. Jose, Melissa Mitchell, Yoav Weiss, Shunya Shishido e Minoru Chikamune per i loro feedback e contributi.