Le risorse di terze parti (come incorporamenti e script) sono attualmente molto utilizzate sul web. Forniscono soluzioni pronte all'uso per incorporare social media, video, analisi, chat live, pubblicità, test A/B, personalizzazione e altro ancora. Gli incorporamenti di terze parti sono una parte necessaria dei siti web moderni che consentono ai proprietari di siti di concentrarsi sulle proprie competenze fondamentali, riducendo al contempo funzioni standard ma fondamentali per i fornitori esterni.
Quando sia la prima parte che le terze parti su una pagina web operano in sinergia, è possibile che una pagina offra un'ottima esperienza utente. Tuttavia, ciò richiede un impegno significativo sia dai team di progettazione che da quelli aziendali e viene spesso trascurato, con conseguenti pagine web dalle prestazioni inferiori al previsto e un impatto negativo sulle metriche incentrate sugli utenti come i Segnali web essenziali. Ciò è dannoso per entrambe le parti e crea opportunità mancate per le aziende. Potremmo fare di meglio?
Abbiamo una visione futura del web in cui script e risorse di terze parti forniscono il valore aziendale previsto con una regressione minima delle prestazioni o dell'esperienza utente dei siti web che li utilizzano nel browser. In questo modo, gli utenti dovrebbero avere un'esperienza di caricamento delle pagine più rapida.
Nell'ultimo anno abbiamo considerato, discusso e sperimentato molte possibilità che possono potenzialmente proteggere l'esperienza utente dall'impatto dannoso degli script di terze parti senza ridurne il valore aziendale per i proprietari dei siti.
Tramite questo post, vogliamo condividere informazioni su alcuni dei nostri esperimenti. Ci auguriamo che questo sia l'inizio di un processo che incoraggerà trasparenza e visibilità tra user agent, aziende e fornitori di terze parti e aprirà la strada a un web più veloce.
Uno sguardo più approfondito alle terze parti
Per terze parti si intende una risorsa fornita da un provider esterno al sito. Non sono direttamente sotto il controllo dei proprietari dei siti, ma sono presenti con la loro approvazione. Le risorse di terze parti sono:
- Ospitato su un'origine condivisa e pubblica diversa dall'origine principale del sito.
- Non sono stati creati da un singolo proprietario del sito o non ne sono stati influenzati.
- Ampiamente utilizzato da una varietà di siti.
Dall'aiuto per generare entrate (tramite gli annunci) all'offerta di migliori opportunità di marketing (incorporamenti sui social media), le terze parti perseguono un'ampia varietà di scopi commerciali. Le categorie comuni di terze parti includono:
Fonte: Terze parti per categoria.
| Categoria | Definizione |
|---|---|
| Pubblicità | Script utilizzati per la pubblicazione di annunci o la misurazione del rendimento degli annunci. |
| Video | Script che attivano il video player e la funzionalità di streaming. |
| Librerie ospitate | Una combinazione di librerie open source ospitate pubblicamente. |
| Contenuti | Script di fornitori di contenuti o di un tracciamento affiliato specifico per la pubblicazione. |
| customer success | Script di fornitori di assistenza clienti/marketing che offrono soluzioni per chat e contatti. |
| Hosting | Script da piattaforme di hosting web. |
| Marketing | Script di strumenti di marketing che aggiungono popup, newsletter e altro ancora. |
| Social | Script che attivano le funzionalità social. |
| Tag Manager | Script che caricano molti altri script e avviano molte attività. |
| Analisi | Script che misurano o monitorano gli utenti e le loro azioni. |
| Piattaforma per il consenso all'uso dei cookie | Script che consentono ai siti di ottenere il consenso degli utenti (GDPR, ePR, CCPA) in modo informato e trasparente. |
| Utilità | Script che sono utilità per sviluppatori (client API, monitoraggio di siti, rilevamento di attività fraudolente e altri). |
| Altro | Script vari pubblicati tramite un'origine condivisa senza categoria o attribuzione precisa. |
Questi script e librerie di terze parti consentono agli sviluppatori web di sfruttare soluzioni comprovate per implementare funzionalità standard invece di reinventare tutto. 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 dunque che oltre il 94% di tutti i siti web su computer e dispositivi mobili utilizzi terze parti.
In che modo le terze parti influiscono sulle prestazioni?
Idealmente, gli sviluppatori di terze parti sono esperti in materia per le funzionalità specifiche che forniscono. Le terze parti più popolari hanno subito diverse iterazioni e ci si può aspettare che il loro codice sia ottimizzato per i propri obiettivi commerciali, il che potrebbe includere o meno il rendimento delle pagine che le utilizzano. Tuttavia, sappiamo che anche le terze parti più ottimizzate influiscono sul rendimento. Di seguito sono riportati i motivi principali dell'impatto:
Costi di dimensioni ed esecuzione di script: spesso le terze parti mirano a fornire funzionalità significative "solo" inserendo un elemento
<script>o<iframe>nella pagina. Questi elementi inseriscono script e risorse di dimensioni significative e che richiedono più tempo per il download e l'esecuzione. Troppo JavaScript mantiene occupati più a lungo il thread principale, blocca il rendering e ritarda le interazioni degli utenti. È noto che alcune delle terze parti principali bloccano il thread principale da 42 ms a 1,6 s per oltre il 50% dei siti analizzati. Un thread principale bloccato genera un tempo di blocco totale (TBT) elevato che è una delle metriche che influisce sul punteggio delle prestazioni del sito. Inoltre, ritarda la risposta alle interazioni degli utenti e riduce la metrica Interaction to Next Paint (INP) utilizzata per misurare la reattività dei siti web. Di conseguenza, i costi di esecuzione dello script hanno un impatto significativo sulle prestazioni.Numero: in media, i siti web utilizzano circa 21 terze parti diverse sui dispositivi mobili e sul web. Spesso, i tag di terze parti vengono aggiunti da strumenti di gestione tag che non sono controllati direttamente dai team tecnico/di sviluppo. I tag non obbligatori possono essere aggiunti da altri team senza una procedura di revisione e non vengono mai rimossi. Questi errori possono influire notevolmente sull'esperienza utente, sul peso della pagina o sull'utilizzo della CPU. La definizione di un processo di governance può far fronte a 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 loro impatto sulle prestazioni, 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.
Rete: poiché terze parti sono ospitate da origini diverse, i browser devono effettuare un maggior numero di connessioni per poter scaricare contenuti da queste terze parti. Le diverse connessioni non possono coordinare il download in base alla priorità, causando un conflitto di rete. Questo può ritardare ulteriormente il caricamento della pagina se non vengono prese in considerazione le ottimizzazioni corrette.
Sequenza: le terze parti possono bloccare il thread principale e fare i conti con la larghezza di banda per risorse più critiche. Detto questo, in alcuni casi, le risorse fondamentali necessarie per il rendering della pagina sono le terze parti. Quando i siti web utilizzano più terze parti, è necessaria una sequenza ottimale delle risorse proprietarie e di terze parti. Gli sviluppatori web devono essere a conoscenza delle diverse opzioni disponibili per ottimizzare la sequenza.
Come conseguenza di quanto illustrato in precedenza, le terze parti possono influire su uno o tutti i componenti di Segnali web essenziali. La maggior parte delle terze parti ha un impatto negativo su Largest Contentful Paint (LCP) e First Input Delay (FID). Gli incorporamenti di YouTube bloccano il thread principale per 4,5 secondi per il 10% dei siti web sui dispositivi mobili e almeno 1,6 secondi per il 50% dei siti web esaminati. Immagina la frustrazione di un utente che trova una pagina con 20 di questi script con una connessione lenta. La seguente visualizzazione di thirdpartyweb.today mostra le terze parti con l'impatto maggiore sulle prestazioni attualmente.
"Tra i principali 4 milioni di siti, circa 2700 origini rappresentano circa il 57% di tutti i tempi di esecuzione degli script e le prime 50 entità rappresentano già circa il 47%". - web-terze parti
Le pagine che vengono visualizzate rapidamente e diventano interattive entro un periodo di tempo ragionevole sono essenziali per una buona esperienza utente, in base alla misurazione dei Segnali web essenziali. Una buona esperienza utente spesso si traduce in un buon affare per i siti web, il che può significare un buon affare per terze parti. Lavorare insieme per ridurre l'impatto di terze parti può essere vantaggioso per tutti nella catena.
Siamo consapevoli che Google vende una serie di script di terze parti di uso comune, tra cui Google Tag Manager, gli incorporamenti di YouTube e il reCAPTCHA, per citarne alcuni. Siamo consapevoli che alcuni dei nostri script potrebbero avere un impatto minore sulle prestazioni di Segnali web essenziali e ci impegniamo a esplorare modi per migliorare questo impatto, ove possibile.
In che modo può essere utile Chrome?
Le risorse di terze parti che hanno un rendimento scarso sono regolarmente una sfida per gli sviluppatori, poiché richiedono una modifica delle dinamiche di base dell'ecosistema. Chrome vuole esplorare questo spazio per ottenere i seguenti risultati:
Trova modi migliori per caricare le risorse di terze parti sul web senza far regredire l'esperienza utente o i risultati aziendali.
Sappiamo che non possiamo andare avanti in questo impegno se non collaboriamo con partner, aziende, terze parti e sviluppatori. Vogliamo creare un campo aperto per discutere delle possibilità e scambiare idee tramite spiegazioni e specifiche pubbliche. Gli sviluppatori avranno il tempo di fornire feedback e verificare l'impatto di molte di queste proposte.
Consenti agli utenti di script di terze parti di avere un'attribuzione migliore dei costi negli strumenti e sul campo, percorsi chiari e ben pavimentati per il loro utilizzo e migliori incentivi durante i tempi di creazione per garantire che siano ottimali per impostazione predefinita.
Vogliamo migliorare tutti i livelli, ad esempio user agent, framework e script di terze parti, per ridurre l'impatto di terze parti sulle prestazioni. Intendiamo inoltre fornire informazioni sufficienti per aiutare i proprietari di siti ad adottare le best practice per ogni script incorporato, tra cui alternative più veloci, ove applicabili.
Approccio proposto
Proponiamo un approccio su tre fronti per raggiungere questi risultati...
**Fornisci agli sviluppatori un'attribuzione più approfondita per l'impatto di terze parti tramite RUM e negli strumenti per sviluppatori di Chrome.**
Per RUM si intendono dati di 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 Report sull'esperienza utente di Chrome. Proponiamo di migliorare le API e gli strumenti disponibili in modo che gli sviluppatori di siti comprendano l'impatto di ogni terza parte utilizzata su ogni pagina. Questi strumenti indicheranno inoltre le azioni che possono intraprendere per mitigare l'impatto (ad esempio, rinviarle o utilizzare facciate) ed esplorare altre potenziali soluzioni (altre terze parti o fai da te) con dei compromessi. Per quanto riguarda le API di monitoraggio delle prestazioni web, stiamo valutando nuovi modi per espandere la copertura delle risorse multiorigine senza compromettere la privacy e la sicurezza dei nostri utenti.
**Offri alle attività un percorso ben illuminato per caricare in modo efficiente le risorse di terze parti.**
Vorremmo proporre nuovi standard che incoraggiano i browser a scendere a compromessi in modo più intelligente tra il modo in cui le risorse proprietarie e di terze parti vengono caricate, nell'intento di migliorare l'esperienza di caricamento per gli utenti. Più avanti evidenzieremo alcune di queste proposte, come gli incorporamenti di terze parti con caricamento lento per impostazione predefinita o l'applicazione di priorità diverse alle risorse di terze parti che potrebbero non essere così fondamentali per i contenuti iniziali che potrebbero interessare di più agli utenti. Queste sono solo una piccola parte delle idee che stiamo valutando in questo ambito e ci piacerebbe collaborare sia con gli esperti di prestazioni web che con la community in generale per dare forma a questo lavoro.
Analogamente, vorremmo risolvere questi problemi nei framework JavaScript e nei sistemi di gestione dei contenuti (CMS), ove più opportuno. Progetti quali Aurora e il team di WordPress Performance ci hanno insegnato l'importanza di utilizzare valori predefiniti integrati che risolvono i problemi di caricamento noti. Le impostazioni predefinite integrate nei framework e nei CMS guidano le attività lungo un percorso ben illuminato. Possono essere utili anche per lo user agent (ad esempio Chrome) come suggerimenti che gli consentono di applicare euristiche per ottimizzare il caricamento delle pagine e il CWV. Questi suggerimenti possono aiutare lo user agent a decidere quando e come terze parti specifiche devono essere caricate nel ciclo di vita della pagina. Ad esempio, il componente script Next.js ha un'impostazione predefinita integrata per caricare script di terze parti quando la pagina diventa interattiva.
**Offrire incentivi a terze parti per ridurre il loro impatto sul rendimento migliorando la trasparenza.**
Al momento gli sviluppatori di terze parti non hanno la visibilità necessaria per comprendere l'impatto dei loro script sui siti in generale. Prevediamo di risolvere questo problema e di dotare questi fornitori di strumenti per analizzare il loro impatto e confrontarlo con altri prodotti sul mercato che forniscono lo stesso valore. Vogliamo anche aiutarli a utilizzare i dati per diagnosticare le cause dell'impatto, in modo che possano mitigare l'impatto a monte. Dovremo chiamare tutte le terze parti, incluse quelle create da Google, per avere successo.
Challenge
Uno sforzo di questa portata non è privo di sfide. Alcune delle sfide principali che dobbiamo considerare sono.
- Le terze parti rappresentano un problema trasversale che riguarda annunci, analisi, gestione dei tag, utilità e molti altri. 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. Troppo presto, vengono bloccati i contenuti di valore; troppo tardi, l'utente potrebbe non riuscire a vederli.
- Gli script di Analytics aumentano il peso della pagina, ma forniscono dati preziosi sulle azioni degli utenti per l'attività.
Speriamo di collaborare con varie categorie di terze parti, cogliere le sfumature del caso, risolvere compromessi e sviluppare incentivi che funzionino per tutti. Ci rendiamo conto di dover lavorare separatamente con le entità in ogni ambito affinché la nostra strategia sia efficace. Sono inclusi i nostri partner interni, come Google Tag Manager, Google Ads e YouTube.
Il nostro intento è fornire un'attribuzione più approfondita sia agli sviluppatori di siti sia a quelli di terze parti. Ciò richiede uno sforzo coscienzioso in cui identifichiamo i dati più rilevanti per la misurazione dell'impatto, li attribuiamo in modo preciso e dettagliato e forniamo la strada giusta da seguire. In definitiva, il calcolo del rendimento di una determinata terza parte rispetto alla concorrenza dovrebbe essere trasparente per tutti.
Proponiamo di migliorare Chrome in modo che possa applicare ottimizzazioni che aiutino a trovare il giusto equilibrio per dare priorità al caricamento delle risorse proprietarie e di terze parti. Una modifica importante diventa disponibile come standard in tutti i browser, ma richiede tempo. Ad esempio, l'attributo
loadingper gli elementi<img>e<iframe>è disponibile in Chrome/Edge dal 2019, ma è diventato disponibile solo in Safari nel 2022. Fino a quando una funzionalità non sarà standardizzata, gli utenti delle risorse di terze parti dovranno assicurarsi di aver ottimizzato anche per altri browser. Ti aiuteremo mettendo in evidenza questo aspetto nelle nostre indicazioni, se pertinente.Per realizzare questo progetto, dovremo collaborare con partner e sviluppatori non solo per aiutarci a comprendere i requisiti specifici, ma anche per testare soluzioni sperimentali su larga scala, fornire feedback, iterare e improvvisare come e quando necessario. Le modifiche dovranno essere pianificate, offrendo un periodo di tempo ragionevole per i test e la valutazione.
Proposte iniziali per gli standard
Abbiamo eseguito alcuni esperimenti iniziali per sviluppare delle funzionalità che possono essere attivate per ottimizzare il processo di caricamento di terze parti. Siamo soddisfatti dei risultati osservati e attualmente possiamo esaminare due di queste funzionalità.
LazyEmbeds
In precedenza, Chrome eseguiva il caricamento lento degli elementi <img> e <iframe> fuori schermo fuori schermo per i nostri utenti della modalità Lite. Questa funzionalità potrebbe essere estesa a tutti gli utenti per posticipare il caricamento degli elementi <iframe> considerati incorporamenti di terze parti finché l'utente non scorre vicino a questi elementi. Ciò potrebbe velocizzare il caricamento di altre parti della pagina, migliorare i Segnali web essenziali, ridurre l'utilizzo della memoria e risparmiare dati.
Ecco una demo che utilizza LazyEmbeds per eseguire il caricamento lento dei video di YouTube in una pagina. Generalmente, un singolo video di YouTube incorporato aggiunge 500-600 kB di JavaScript alla pagina. Abbiamo provato a ottimizzare un post del blog con 14 di questi incorporamenti video utilizzando la funzionalità LazyEmbed. I risultati sono stati promettenti in termini di tempo di caricamento delle pagine e risparmio di dati.
| Prima | Dopo | |
|---|---|---|
| Dati | 15,4 MB | 6,1 MB |
| Tempo di blocco totale | 3,2 secondi | 1,6 secondi |
Per saperne di più su questo lavoro, consulta il nostro thread esplicativo e di blink-dev (intent-to-experiment) e sull'estensione dell'esperimento.
Limitazione di terze parti scelta come target
Spesso gli script di terze parti vengono aggiunti da vari team senza processi di supervisione olistica. Il team di tecnici di The Telegraph ha affermato che "tutti vogliono ricevere quel tag su una pagina che farà guadagnare all'organizzazione". Ciò può aumentare continuamente l'onere della gestione dell'impatto sulle prestazioni.
La limitazione degli script di terze parti mirata si propone di limitare tipi molto specifici di terze parti per mitigare il loro impatto. Ciò consentirebbe ai browser di caricare tempestivamente i contenuti chiave e di terze parti critiche, mentre quelli che possono essere caricati in un secondo momento vengono limitati.
Miglioramento delle API RUM
Stiamo anche valutando di potenziare le API RUM per includere informazioni che sarebbero pertinenti per la valutazione delle prestazioni di terze parti. I miglioramenti includono:
Report di
<iframe>: stiamo lavorando a soluzioni che possano sfruttare l'API Performance Timeline per generare report cross-frame. In questo modo, gli autori della pagina di primo livello possono esaminare i dati sulle prestazioni di un iframe di terze parti che collabora e incorporato nella pagina.Attribuzione delle attività lunghe: l'API Long Tasks in RUM aiuterà i proprietari di siti a identificare le attività lunghe che legano per molto tempo il thread principale e ritardano l'interazione.
Ulteriori aggiornamenti
Stiamo ancora sperimentando molte idee di questo tipo e speriamo di pubblicare spiegazioni su GitHub e bozze di specifiche per le modifiche man mano che procediamo. Le terze parti e i proprietari di siti che desiderano collaborare con noi o lasciare un feedback possono contribuire alle discussioni tramite questi strumenti. Le terze parti possono anche iniziare a concentrarsi sull'ottimizzazione per le metriche INP e i Segnali web essenziali per garantire che non vengano attribuiti loro dati di scarso valore di Segnali web essenziali/INP. Per il momento, chi cerca attivamente gli aggiornamenti può fare riferimento ai post sul gruppo blink-dev.
Non vediamo l'ora di esplorare ulteriormente questo spazio problematico e di coinvolgere la community sulle nostre conoscenze.
Con 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.