Carica JavaScript di terze parti

Addy Osmani

Arthur Evans

Se hai ottimizzato il codice, ma il sito continua a caricarsi troppo lentamente, probabilmente la colpa è degli script di terze parti.

Gli script di terze parti offrono una serie di funzionalità utili che rendono il web più dinamico, interattivo e interconnesso. Alcuni di questi potrebbero persino essere fondamentali per il funzionamento del tuo sito web o per il flusso di entrate. Tuttavia, il loro utilizzo è rischioso:

• Possono rallentare le prestazioni del tuo sito.
• Possono causare problemi di privacy o sicurezza.
• Possono essere imprevedibili e il loro comportamento può avere conseguenze indesiderate.

Idealmente, devi assicurarti che gli script di terze parti non influiscano sul percorso di rendering critico del tuo sito. In questa guida, vedremo come trovare e risolvere i problemi relativi al caricamento di JavaScript di terze parti e ridurre al minimo i rischi per gli utenti.

Che cosa sono gli script di terze parti?

Il codice JavaScript di terze parti spesso si riferisce a script che possono essere incorporati in qualsiasi sito direttamente da un fornitore di terze parti. Ecco alcuni esempi:

• Pulsanti di condivisione sui social (Facebook, X, LinkedIn, Mastodon)

• Video player incorporati (YouTube, Vimeo)

• Iframe pubblicitari

• Script di analisi e metriche

• Script di test A/B per gli esperimenti

• Librerie helper, ad esempio librerie di formattazione delle date, di animazione o funzionali

Un esempio di video di YouTube incorporato che può essere aggiunto a una pagina utilizzando il seguente codice.

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

Purtroppo, l'incorporamento di script di terze parti significa che spesso ci affidiamo a loro per un'esecuzione rapida e per non rallentare le nostre pagine. Gli script di terze parti sono una causa comune di rallentamenti delle prestazioni causati da risorse al di fuori del controllo del proprietario del sito, tra cui i seguenti problemi:

• Invio di troppe richieste di rete a più server. Più richieste deve effettuare un sito, più tempo potrebbe impiegare per caricarsi.

• Invio di troppo codice JavaScript che tiene occupato il thread principale. Un eccesso di JavaScript può bloccare la costruzione del DOM, ritardando il rendering della pagina. L'analisi e l'esecuzione di script che richiedono un uso intensivo della CPU possono ritardare l'interazione dell'utente e causare il consumo della batteria.

• L'invio di file immagine o video di grandi dimensioni e non ottimizzati può consumare dati e costare denaro agli utenti.

• Problemi di sicurezza che possono fungere da single point of failure (SPOF) se la pagina carica uno script senza precauzioni.

• Memorizzazione nella cache HTTP insufficiente, che costringe il browser a inviare più richieste di rete per recuperare le risorse.

• La mancanza di una compressione del server sufficiente causa il caricamento lento delle risorse.

• Blocco della visualizzazione dei contenuti fino al completamento dell'elaborazione. Lo stesso può valere per gli script di test A/B asincroni.

• Utilizzo di API legacy note per danneggiare l'esperienza utente, ad esempio document.write().

• Elementi DOM eccessivi o selettori CSS costosi.

• L'inclusione di più incorporamenti di terze parti può comportare l'importazione di più framework e librerie più volte, con uno spreco di risorse e un peggioramento dei problemi di prestazioni esistenti.

• Gli script di terze parti spesso utilizzano tecniche di incorporamento che possono bloccare window.onload se i loro server rispondono lentamente, anche se l'incorporamento utilizza async o defer.

La tua capacità di risolvere i problemi relativi agli script di terze parti può dipendere dal tuo sito e dalla tua capacità di configurare il modo in cui carichi il codice di terze parti. Fortunatamente, esistono diverse soluzioni e strumenti per trovare e risolvere i problemi relativi alle risorse di terze parti.

Come si identifica uno script di terze parti in una pagina?

Identificare gli script di terze parti sul tuo sito e determinare il loro impatto sul rendimento è il primo passo per ottimizzarli. Per identificare gli script costosi, ti consigliamo di utilizzare strumenti senza costi per il test di velocità web, tra cui Chrome DevTools, PageSpeed Insights e WebPageTest. Questi strumenti mostrano informazioni diagnostiche dettagliate che possono indicarti quanti script di terze parti utilizza il tuo sito e quali richiedono più tempo per l'esecuzione.

La visualizzazione a cascata di WebPageTest può evidenziare l'impatto di un utilizzo intensivo di script di terze parti. L'immagine seguente di Tags Gone Wild mostra un diagramma di esempio delle richieste di rete necessarie per caricare i contenuti principali di un sito, rispetto agli script di monitoraggio e marketing.

Il caricamento degli script in questa pagina richiede più tempo rispetto a quello della pagina stessa.

Anche la suddivisione dei domini di WebPageTest può essere utile per visualizzare quanti contenuti provengono da origini di terze parti. La suddivisione viene effettuata in base ai byte totali e al numero di richieste:

I grafici di analisi dei domini mostrano la quantità di contenuti di una pagina provenienti da terze parti.

Come faccio a misurare l'impatto dello script di terze parti sulla mia pagina?

Quando vedi uno script che causa problemi, scopri cosa fa e determina se è necessario per il funzionamento del tuo sito. Se necessario, esegui un test A/B per bilanciare il valore percepito rispetto all'impatto sul coinvolgimento degli utenti o sulle metriche sul rendimento principali.

Controllo del tempo di avvio di Lighthouse

Il controllo del tempo di avvio di JavaScript di Lighthouse evidenzia gli script che hanno un tempo di analisi, compilazione o valutazione elevato. In questo modo puoi identificare gli script di terze parti che richiedono un utilizzo intensivo della CPU.

Il controllo del tempo di avvio mostra quali script richiedono più tempo per il caricamento.

Controllo dei payload di rete di Lighthouse

Il controllo dei payload di rete di Lighthouse identifica le richieste di rete, incluse quelle di terze parti, che rallentano il tempo di caricamento della pagina e fanno spendere agli utenti più del previsto per i dati mobili.

Il controllo dei payload di rete mostra quali richieste di rete richiedono più tempo e recuperano più dati.

Blocco delle richieste di rete di Chrome DevTools

Chrome DevTools ti consente di vedere come si comporta la tua pagina quando uno script, un foglio di stile o un'altra risorsa specificati non sono disponibili. Questo viene fatto con il blocco delle richieste di rete, una funzionalità che può aiutare a misurare l'impatto della rimozione di singole risorse di terze parti dalla pagina.

Per attivare il blocco delle richieste, fai clic con il tasto destro del mouse su una richiesta nel riquadro Rete e seleziona Blocca URL richiesta. Nella sezione DevTools viene visualizzata una scheda di blocco delle richieste, che ti consente di gestire le richieste bloccate.

Blocca singole richieste di rete per vedere come si comporta la pagina senza di esse.

Pannello Prestazioni di Chrome DevTools

Il riquadro Prestazioni di Chrome DevTools aiuta a identificare i problemi relativi alle prestazioni web della pagina.

1. Fai clic su Registra.
2. Carica la pagina. DevTools mostra un diagramma a cascata che rappresenta il modo in cui il tuo sito spende il tempo di caricamento.
3. Vai a Bottom-up nella parte inferiore del riquadro Prestazioni.
4. Fai clic su Raggruppa per prodotto e ordina gli script di terze parti della pagina in base al tempo di caricamento.

Script di terze parti ordinati per prodotto, a partire dal tempo di caricamento più lungo.

Per scoprire di più sull'utilizzo di Chrome DevTools per analizzare le prestazioni di caricamento pagina, consulta Inizia ad analizzare le prestazioni di runtime.

Di seguito è riportato il nostro flusso di lavoro consigliato per misurare l'impatto degli script di terze parti:

1. Utilizza il riquadro Rete per misurare il tempo necessario per caricare la pagina.
   • Per emulare le condizioni reali, ti consigliamo di attivare la limitazione della larghezza di banda della rete e la limitazione della CPU. È improbabile che i tuoi utenti dispongano di connessioni di rete veloci e di hardware desktop che riducono l'impatto di script costosi in condizioni di laboratorio.
2. Blocca gli URL o i domini responsabili degli script di terze parti che ritieni siano un problema (consulta il pannello Prestazioni di Chrome DevTools per indicazioni su come identificare gli script costosi).
3. Ricarica la pagina e misura di nuovo il tempo di caricamento.
   • Per dati più accurati, ti consigliamo di misurare il tempo di caricamento almeno tre volte. Questo spiega perché alcuni script di terze parti recuperano risorse diverse a ogni caricamento pagina. Per aiutarti, il riquadro Prestazioni di DevTools supporta più registrazioni.

Misura l'impatto degli script di terze parti con WebPageTest

WebPageTest supporta il blocco del caricamento di singole richieste per misurarne l'impatto in Impostazioni avanzate > Blocca. Utilizza questa funzionalità per specificare un elenco di domini da bloccare, ad esempio i domini pubblicitari.

In questo riquadro, elenca i domini che vuoi bloccare.

Per utilizzare questa funzionalità, ti consigliamo il seguente flusso di lavoro:

1. Testa una pagina senza bloccare le terze parti.
2. Ripeti il test con alcune terze parti bloccate.
3. Seleziona i due risultati dalla Cronologia test.
4. Fai clic su Confronta.

Seleziona i risultati del test di carico da confrontare.

La seguente immagine mostra la funzionalità di sequenza di WebPageTest che confronta le sequenze di caricamento per le pagine con e senza risorse di terze parti attive. Ti consigliamo di controllare questo aspetto per i test di singole origini di terze parti, in modo da determinare quali domini influiscono maggiormente sul rendimento della tua pagina.

L'impatto del blocco delle risorse di terze parti, da Using WebPageTest To Measure The Impact Of Third-Party Tags di Andy Davies.

WebPageTest supporta anche due comandi che operano a livello di DNS per bloccare i domini:

• blockDomains accetta un elenco di domini da bloccare.
• blockDomainsExcept accetta un elenco di domini e blocca tutto ciò che non è presente nell'elenco.

WebPageTest ha anche una scheda Single Point of Failure (SPOF) che ti consente di simulare un timeout o un errore completo di caricamento di una risorsa. A differenza del blocco dei domini, lo SPOF si disconnette lentamente, il che può essere utile per testare il comportamento delle tue pagine quando i servizi di terze parti sono sottoposti a un carico elevato o non sono temporaneamente disponibili.

Utilizza la funzionalità di test SPOF per simulare l'errore di domini specificati.

Rileva iframe costosi utilizzando attività lunghe

Quando gli script negli iframe di terze parti richiedono molto tempo per l'esecuzione, possono bloccare il thread principale e ritardare altre attività. Queste attività lunghe possono rallentare i gestori di eventi o causare la perdita di frame, peggiorando l'esperienza utente.

Per rilevare le attività lunghe per il Real User Monitoring (RUM), utilizza l'API JavaScript PerformanceObserver per osservare le voci longtask. Queste voci contengono una proprietà di attribuzione che puoi utilizzare per determinare quale contesto del frame ha causato l'attività lunga.

Il seguente codice registra le voci longtask nella console, inclusa una per un iframe "costoso":

<script>
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Attribution entry including "containerSrc":"https://example.com"
      console.log(JSON.stringify(entry.attribution));
    }
  });

  observer.observe({entryTypes: ['longtask']});
</script>

<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>

Per scoprire di più sul monitoraggio delle attività lunghe, consulta Metriche sul rendimento incentrate sull'utente.

Come si caricano gli script di terze parti in modo efficiente?

Se uno script di terze parti rallenta il caricamento della pagina, hai diverse opzioni per migliorare le prestazioni:

• Carica lo script utilizzando l'attributo async o defer per evitare di bloccare l'analisi del documento.
• Se il server di terze parti è lento, valuta la possibilità di ospitare autonomamente lo script.
• Se lo script non aggiunge un valore chiaro al tuo sito, rimuovilo.
• Utilizza i suggerimenti per le risorse come <link rel=preconnect> o <link rel=dns-prefetch> per eseguire una ricerca DNS per i domini che ospitano script di terze parti.

Utilizza async o defer

L'esecuzione di JavaScript blocca l'analizzatore sintattico. Quando il browser rileva uno script, deve mettere in pausa la creazione del DOM, passare lo script al motore JavaScript e consentire l'esecuzione dello script prima di continuare con la creazione del DOM.

Gli attributi async e defer modificano questo comportamento come segue:

• async fa sì che il browser scarichi lo script in modo asincrono mentre continua ad analizzare il documento HTML. Al termine del download dello script, l'analisi viene bloccata durante l'esecuzione dello script.

• defer fa sì che il browser scarichi lo script in modo asincrono mentre continua ad analizzare il documento HTML, quindi attende di eseguire lo script fino al completamento dell'analisi del documento.

Utilizza sempre async o defer per gli script di terze parti, a meno che lo script non sia necessario per il percorso di rendering critico. Utilizza async se è importante che lo script venga eseguito prima nel processo di caricamento, ad esempio per alcuni script di analisi. Utilizza defer per le risorse meno critiche, ad esempio i video che vengono visualizzati più in basso nella pagina rispetto a ciò che l'utente vedrà inizialmente.

Se le prestazioni sono la tua principale preoccupazione, ti consigliamo di attendere l'aggiunta di script asincroni fino al caricamento dei contenuti critici della pagina. Sconsigliamo di utilizzare async per le librerie essenziali come jQuery.

Nota: in Chrome e in altri browser basati su Blink, async e defer riducono la priorità della richiesta di rete per le risorse, pertanto il caricamento potrebbe avvenire molto più tardi rispetto a uno script di blocco. Questo è utile da sapere, in particolare per gli script di analisi.

Alcuni script devono essere caricati senza async o defer, in particolare quelli che costituiscono parti cruciali del tuo sito. Sono incluse le librerie UI o i framework di rete CDN (Content Delivery Network) senza i quali il tuo sito non può funzionare.

Altri script non funzionano se vengono caricati in modo asincrono. Consulta la documentazione degli script che utilizzi e sostituisci quelli che non possono essere caricati in modo asincrono con alternative che possono esserlo. Tieni presente che alcune terze parti consigliano di eseguire i propri script in modo sincrono, anche se funzionerebbero altrettanto bene in modo asincrono.

Ricorda che async non risolve tutti i problemi. Se la pagina include un numero elevato di script, ad esempio script di monitoraggio per scopi pubblicitari, il caricamento asincrono non impedirà il rallentamento del caricamento della pagina.

Utilizza i suggerimenti per le risorse per ridurre il tempo di configurazione della connessione

La creazione di connessioni a origini di terze parti può richiedere molto tempo, soprattutto su reti lente, perché le richieste di rete hanno più componenti complessi, tra cui ricerche DNS e reindirizzamenti. Puoi utilizzare i suggerimenti per le risorse come per eseguire ricerche DNS per i domini che ospitano script di terze parti all'inizio del processo di caricamento della pagina, in modo che il resto della richiesta di rete possa procedere più rapidamente in un secondo momento:

<link rel="dns-prefetch" href="http://example.com" />

Se il dominio di terze parti a cui ti connetti utilizza HTTPS, puoi anche utilizzare , che esegue ricerche DNS e risolve i round trip TCP e gestisce le negoziazioni TLS. Questi altri passaggi possono essere molto lenti perché comportano la verifica dei certificati SSL, quindi la preconnessione può ridurre notevolmente il tempo di caricamento.

<link rel="preconnect" href="https://cdn.example.com" />

Script "sandbox" con un iframe

Se carichi uno script di terze parti direttamente in un iframe, l'esecuzione della pagina principale non viene bloccata. AMP utilizza questo approccio per tenere JavaScript fuori dal percorso critico. Tieni presente che questo approccio blocca comunque l'evento onload, quindi cerca di non collegare funzionalità critiche a onload.

Chrome supporta anche Permissions Policy (precedentemente Feature Policy), un insieme di policy che consentono a uno sviluppatore di disattivare selettivamente l'accesso a determinate funzionalità del browser. Puoi utilizzarla per impedire che i contenuti di terze parti introducano comportamenti indesiderati in un sito.

Ospita autonomamente gli script di terze parti

Se vuoi avere un maggiore controllo sul caricamento di uno script critico, ad esempio per ridurre il tempo DNS o migliorare le intestazioni di memorizzazione nella cache HTTP, potresti ospitarlo autonomamente.

Tuttavia, l'hosting autonomo presenta problemi, soprattutto quando si tratta di aggiornare gli script. Gli script in hosting autonomo non riceveranno aggiornamenti automatici per le modifiche alle API o le correzioni di sicurezza, il che può comportare perdite di entrate o problemi di sicurezza finché non potrai aggiornare lo script manualmente.

In alternativa, puoi memorizzare nella cache gli script di terze parti utilizzando i service worker per un maggiore controllo sulla frequenza con cui gli script vengono recuperati dalla rete. Puoi anche utilizzare i service worker per creare strategie di caricamento che limitano le richieste di terze parti non essenziali finché la pagina non raggiunge un momento chiave per l'utente.

Esegui test A/B su campioni di utenti più piccoli

I test A/B (o split test) sono una tecnica per sperimentare due versioni di una pagina per analizzare l'esperienza e il comportamento degli utenti. Rende disponibili le versioni della pagina a diversi campioni del traffico del tuo sito web e determina, in base ai dati di analisi, quale versione fornisce un tasso di conversione migliore.

Tuttavia, per progettazione, i test A/B ritardano il rendering per decidere quale esperimento deve essere attivo. JavaScript viene spesso utilizzato per verificare se uno dei tuoi utenti appartiene a un esperimento di test A/B e quindi attivare la variante corretta. Questo processo può peggiorare l'esperienza anche per gli utenti che non partecipano all'esperimento.

Per velocizzare il rendering della pagina, ti consigliamo di inviare gli script dei test A/B a un campione più piccolo della tua base utenti ed eseguire il codice che decide quale versione della pagina visualizzare lato server.

Carica risorse di terze parti tramite caricamento lento

Le risorse di terze parti incorporate, come annunci e video, possono contribuire in modo significativo a rallentare la velocità della pagina se non sono create correttamente. Il caricamento lento può essere utilizzato per caricare le risorse incorporate solo quando necessario, ad esempio aspettando di pubblicare gli annunci nel piè di pagina finché l'utente non scorre abbastanza da visualizzarli. Puoi anche eseguire il caricamento lento dei contenuti di terze parti dopo il caricamento dei contenuti della pagina principale, ma prima che un utente possa interagire con la pagina.

Puoi caricare lentamente gli asset che l'utente non vedrà immediatamente al caricamento della pagina.

Fai attenzione quando esegui il caricamento lento delle risorse, perché spesso comporta l'utilizzo di codice JavaScript che può essere influenzato da connessioni di rete instabili.

Nota: LazySizes è una libreria JavaScript molto utilizzata per il caricamento lento di immagini e iframe. Supporta i video di YouTube incorporati e i widget.

DoubleClick fornisce indicazioni su come implementare il caricamento lento degli annunci nella sua documentazione ufficiale.

Caricamento lento efficiente con Intersection Observer

In passato, i metodi per rilevare se un elemento è visibile nell'area visibile per il caricamento lento erano soggetti a errori e spesso rallentavano il browser. Questi metodi inefficienti spesso ascoltano gli eventi scroll o resize, quindi utilizzano API DOM come getBoundingClientRect() per calcolare la posizione degli elementi rispetto alla viewport.

IntersectionObserver è un'API del browser che consente ai proprietari delle pagine di rilevare in modo efficiente quando un elemento osservato entra o esce dall'area visibile del browser. LazySizes offre anche il supporto facoltativo per IntersectionObserver.

Analisi del caricamento lento

Se rinvii troppo a lungo il caricamento degli script di analisi, potresti perdere dati di analisi preziosi. Fortunatamente, esistono strategie per inizializzare l'analisi in modo lazy, conservando al contempo i dati di caricamento pagina iniziali.

Il blog post di Phil Walton The Google Analytics Setup I Use on Every Site I Build illustra una di queste strategie per Google Analytics.

Carica gli script di terze parti in modo sicuro

Questa sezione fornisce indicazioni per caricare gli script di terze parti nel modo più sicuro possibile.

Evita document.write()

Gli script di terze parti, in particolare per i servizi meno recenti, a volte utilizzano document.write() per inserire e caricare script. Questo è un problema perché document.write() si comporta in modo incoerente e i suoi errori sono difficili da sottoporre a debug.

La soluzione ai problemi di document.write() è non utilizzarlo. In Chrome 53 e versioni successive, Chrome DevTools registra gli avvisi nella console per l'utilizzo problematico di document.write():

Utilizzo dei flag di Chrome DevTools document.write().

Se ricevi questo errore, puoi controllare l'utilizzo di document.write() sul tuo sito cercando le intestazioni HTTP inviate al tuo browser. Lighthouse può anche evidenziare eventuali script di terze parti che utilizzano ancora document.write().

Un report Lighthouse che mostra quali script utilizzano document.write().

Utilizza i Tag Manager con attenzione

Un tag è uno snippet di codice che consente ai team di marketing digitale di raccogliere dati, impostare cookie o integrare contenuti di terze parti, come i widget dei social media, in un sito. Questi tag aggiungono alla pagina richieste di rete, dipendenze JavaScript e altre risorse che possono influire sul suo rendimento. Ridurre al minimo questo impatto per gli utenti diventa più difficile man mano che vengono aggiunti altri tag.

Per mantenere un caricamento rapido della pagina, ti consigliamo di utilizzare un gestore tag come Google Tag Manager (GTM). GTM ti consente di implementare i tag in modo asincrono, in modo che non si blocchino a vicenda durante il caricamento, riduce il numero di chiamate di rete necessarie a un browser per eseguire i tag e raccoglie i dati dei tag nella UI del livello dati.

Rischi legati all'utilizzo di Tag Manager

Sebbene i gestori dei tag siano progettati per semplificare il caricamento delle pagine, un utilizzo incauto può rallentarlo nei seguenti modi:

• Un numero eccessivo di tag e listener di eventi automatici in Tag Manager fa sì che il browser effettui più richieste di rete di quelle necessarie e riduce la capacità del codice di rispondere rapidamente agli eventi.
• Chiunque disponga di credenziali e accesso può aggiungere JavaScript a Tag Manager. Questo non solo può aumentare il numero di richieste di rete costose necessarie per caricare la pagina, ma può anche presentare rischi per la sicurezza e altri problemi di prestazioni dovuti a script non necessari. Per ridurre questi rischi, ti consigliamo di limitare l'accesso al tuo Tag Manager.

Evita gli script che inquinano l'ambito globale

Gli script di terze parti possono comportarsi in modi diversi che interrompono la pagina in modo imprevisto:

• Gli script che caricano dipendenze JavaScript possono inquinare l'ambito globale con codice che interagisce male con il tuo codice.
• Gli aggiornamenti imprevisti possono causare modifiche che provocano un errore.
• Il codice di terze parti può essere modificato durante il transito per comportarsi in modo diverso tra il test e il deployment della pagina.

Ti consigliamo di eseguire controlli regolari degli script di terze parti che carichi per verificare la presenza di malintenzionati. Puoi anche implementare l'autodiagnostica, l'integrità delle risorse secondarie e la trasmissione sicura del codice di terze parti per proteggere la tua pagina.

Strategie di mitigazione

Ecco alcune strategie su larga scala per ridurre al minimo l'impatto degli script di terze parti sulle prestazioni e sulla sicurezza del tuo sito:

• HTTPS: i siti che utilizzano HTTPS non devono dipendere da terze parti che utilizzano HTTP. Per saperne di più, consulta Contenuti misti.

• Sandboxing: valuta la possibilità di eseguire script di terze parti in iframe con l'attributo sandbox per limitare le azioni disponibili per gli script.

• Content Security Policy (CSP): puoi utilizzare le intestazioni HTTP nella risposta del server per definire i comportamenti degli script attendibili per il tuo sito e rilevare e mitigare gli effetti di alcuni attacchi, come il cross-site scripting (XSS).

Di seguito è riportato un esempio di come utilizzare l'istruzione script-src della CSP per specificare le origini JavaScript consentite di una pagina:

// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed

<script src="https://not-example.com/js/library.js"></script>

Per approfondire

Per scoprire di più sull'ottimizzazione di JavaScript di terze parti, ti consigliamo di leggere quanto segue:

• Prestazioni e resilienza: stress test di terze parti
• Aggiunta di interattività con JavaScript
• Potenziali pericoli degli script di terze parti
• How 3rd Party Scripts can be performant citizens on the web
• Why Fast Matters - CSS Wizardry
• The JavaScript Supply Chain Paradox: SRI, CSP and Trust in Third Party Libraries
• Il CSS di terze parti non è sicuro

Ringraziamo Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick e Cheney Tsai per le loro recensioni.