Carica JavaScript di terze parti

Addy Osmani

Arthur Evans

Se hai ottimizzato il codice, ma il tuo sito continua a caricarsi troppo lentamente, è probabile che questo sia dovuto agli 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 anche essere fondamentali per la funzione del sito web o il flusso di entrate. Il loro utilizzo è rischioso:

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

È consigliabile assicurarsi che gli script di terze parti non influiscano sul percorso di rendering critico del sito. In questa guida, illustreremo come individuare 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 termine JavaScript di terze parti si riferisce spesso 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)

• Incorporamenti nel video player (YouTube, Vimeo)

• Iframe pubblicitari

• Script di analisi e metriche

• Script per il test A/B per gli esperimenti

• Librerie di supporto, ad esempio formattazione di date, animazioni o librerie funzionali

Esempio di incorporamento di un video di YouTube 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>

Sfortunatamente, l'incorporamento di script di terze parti ci consente spesso di farvi affidamento per un'esecuzione rapida senza che le nostre pagine vengano rallentate. Gli script di terze parti sono una causa comune di rallentamenti del rendimento causati da risorse che non sono controllabili dal proprietario del sito, tra cui i seguenti problemi:

• Sono state attivate troppe richieste di rete su più server. Maggiore è il numero di richieste da parte di un sito, maggiore sarà il tempo di caricamento.

• Invio di troppo codice JavaScript che mantiene occupato il thread principale. Troppo JavaScript può bloccare la creazione del DOM, ritardando il rendering delle pagine. L'analisi e l'esecuzione degli script che consumano molta CPU possono ritardare l'interazione dell'utente e causare il consumo della batteria.

• L'invio di file immagine o video di grandi dimensioni non ottimizzati può comportare un consumo di dati e costi aggiuntivi.

• Problemi di sicurezza che possono fungere da SPOF (Single Point of failure) se la pagina carica uno script senza cautela.

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

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

• Blocco della visualizzazione dei contenuti fino al completamento dell'elaborazione. Questo vale anche 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ò portare al pull di più framework e librerie, sprecando risorse e peggiorando i problemi di rendimento esistenti.

• Gli script di terze parti spesso utilizzano tecniche di incorporamento che possono bloccare window.onload se i server rispondono lentamente, anche se l'incorporamento utilizza un modalità asincrono o differito.

La 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 individuare e risolvere i problemi relativi alle risorse di terze parti.

Come identifichi lo script di terze parti su una pagina?

Identificare gli script di terze parti sul tuo sito e determinarne l'impatto sul rendimento è il primo passo per ottimizzarli. Ti consigliamo di utilizzare strumenti senza costi di test della velocità web, tra cui Chrome DevTools, PageSpeed Insights e WebPageTest per identificare gli script costosi. Questi strumenti mostrano informazioni diagnostiche dettagliate indicanti quanti script di terze parti vengono utilizzati dal tuo sito e quali richiedono più tempo per essere eseguiti.

La visualizzazione con struttura a cascata di WebPageTest può evidenziare l'impatto dell'utilizzo intensivo degli script di terze parti. La seguente immagine di Tag Gone Wild mostra un diagramma di esempio delle richieste di rete necessarie per caricare i contenuti principali di un sito, anziché gli script di monitoraggio e marketing.

Il caricamento degli script in questa pagina richiede più tempo rispetto alla pagina stessa.

La suddivisione dei domini di WebPageTest può essere utile anche per visualizzare la quantità di contenuti provenienti da origini di terze parti. L'analisi viene suddivisa per byte totali e numero di richieste:

I grafici di analisi dei domini mostrano in che misura i contenuti di una pagina provengono da terze parti.

Come posso misurare l'impatto di uno script di terze parti sulla mia pagina?

Quando vedi uno script che causa problemi, scopri cosa fa e stabilisci se il tuo sito deve funzionare. Se necessario, esegui un test A/B per bilanciare il valore percepito rispetto al suo impatto sulle metriche chiave sul coinvolgimento o sul rendimento degli utenti.

Controllo del tempo di avvio di Lighthouse

Il controllo del tempo di avvio di JavaScript di Lighthouse mette in evidenza gli script che richiedono costosi tempi di analisi, compilazione o valutazione degli script. Ciò può aiutarti a identificare gli script di terze parti che consumano molta CPU.

Il controllo del tempo di avvio mostra quali script impiegano più tempo a caricarsi.

Audit dei payload di rete Lighthouse

L'audit dei payload di rete di Lighthouse identifica le richieste di rete, incluse le richieste di rete di terze parti che rallentano il caricamento delle pagine e fanno spendere agli utenti più di quanto previsto sui dati mobili.

L'audit dei payload di rete mostra quali richieste di rete richiedono più tempo e recuperano la maggior parte dei dati.

Blocco delle richieste di rete Chrome DevTools

Chrome DevTools ti consente di vedere il comportamento della pagina quando uno script, un foglio di stile o un'altra risorsa specificati non sono disponibili. A questo scopo, utilizza il blocco delle richieste di rete, una funzionalità che consente di 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 qualsiasi nel riquadro Rete e seleziona Blocca URL richiesta. Nel riquadro a scomparsa di DevTools viene visualizzata una scheda di blocco delle richieste che ti consente di gestire le richieste bloccate.

Blocca le singole richieste di rete per vedere come si comporta la pagina senza queste ultime.

Riquadro delle prestazioni di Chrome DevTools

Il riquadro Prestazioni in Chrome DevTools consente di identificare i problemi relativi alle prestazioni web della tua pagina.

1. Fai clic su Registra.
2. Carica la pagina. DevTools mostra un diagramma a cascata che rappresenta il tempo di caricamento del sito.
3. Vai a Dal basso verso l'alto nella parte inferiore del riquadro Rendimento.
4. Fai clic su Raggruppa per prodotto e ordina gli script di terze parti della tua pagina in base al tempo di caricamento.

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

Per saperne di più sull'utilizzo di Chrome DevTools per analizzare le prestazioni di caricamento delle pagine, consulta Iniziare ad analizzare le prestazioni di runtime.

Di seguito è riportato il 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 condizioni reali, ti consigliamo di attivare la limitazione della rete e la limitazione della CPU. È improbabile che gli utenti dispongano delle connessioni di rete veloci e dell'hardware per desktop che riducono l'impatto di script costosi nelle condizioni di laboratorio.
2. Blocca gli URL o i domini responsabili degli script di terze parti che ritieni rappresentino un problema (consulta il riquadro Prestazioni di Chrome DevTools per le indicazioni sull'identificazione degli script costosi).
3. Ricarica la pagina e misura di nuovo il tempo di caricamento.
   • Per dati più precisi, ti conviene misurare il tempo di caricamento almeno tre volte. Questo spiega alcuni script di terze parti che recuperano risorse diverse a ogni caricamento pagina. Per aiutarti, il riquadro delle 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.

Elenca i domini da bloccare in questo riquadro.

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

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

Seleziona i risultati del test di carico da confrontare.

L'immagine seguente mostra la funzionalità pellicola di WebPageTest che confronta le sequenze di caricamento per le pagine con e senza risorse di terze parti attive. Ti consigliamo di verificare questo comportamento per i test su 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, dall' utilizzo di WebPageTest per misurare l'impatto dei tag di terze parti di Andy Davies.

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

• blockDomains richiede un elenco di domini da bloccare.
• blockDomainsExcept richiede un elenco di domini e blocca tutti gli elementi non presenti nell'elenco.

WebPageTest dispone anche di una scheda SPOF (Single Point of failure) che consente di simulare un timeout o di completare un errore durante il caricamento di una risorsa. A differenza del blocco dei domini, il timeout di SPOF è lento, il che può essere utile per testare il comportamento delle pagine quando i servizi di terze parti sono troppo carichi o temporaneamente non disponibili.

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

Rileva iframe costosi utilizzando Attività lunghe

Quando l'esecuzione degli script in iframe di terze parti richiede molto tempo, possono bloccare il thread principale e ritardare altre attività. Queste attività possono rallentare il funzionamento dei gestori di eventi o il calo dei frame, peggiorando l'esperienza utente.

Per rilevare attività lunghe per 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 il contesto del frame che 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 saperne di più sul monitoraggio delle attività lunghe, consulta Metriche sul rendimento incentrate sull'utente.

Come carichi lo 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 dei documenti.
• 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 suggerimenti di risorse come <link rel=preconnect> o <link rel=dns-prefetch> per eseguire una ricerca DNS dei domini che ospitano script di terze parti.

Usa async o defer

L'esecuzione di JavaScript sta bloccando il parser. Quando il browser rileva uno script, deve mettere in pausa la creazione del DOM, passarlo 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 nel seguente modo:

• 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 l'esecuzione dello 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. Usa defer per le risorse meno critiche, ad esempio video che vengono visualizzati in una posizione più bassa nella pagina rispetto a quella che l'utente vedrà inizialmente.

Se le prestazioni sono la tua principale preoccupazione, ti consigliamo di attendere di aggiungere script asincroni fino a quando non vengono caricati i contenuti critici della pagina. Non è consigliabile utilizzare async per 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, in modo che il caricamento della richiesta di rete sia molto più tardi del previsto come script di blocco. È utile sapere in particolare per gli script di analisi.

Alcuni script devono essere caricati senza async o defer, soprattutto quelli che sono parti fondamentali del tuo sito. Includono librerie UI o framework CDN (Content Delivery Network) della rete CDN (Content Delivery Network) senza i quali il tuo sito non può funzionare.

Gli altri script non funzionano se vengono caricati in modo asincrono. Consulta la documentazione relativa agli script in uso e sostituisci quelli che non possono essere caricati in modo asincrono con alternative che possono farlo. Ricorda che alcune terze parti consigliano di eseguire i propri script in modo sincrono, anche se funzionano in modo altrettanto efficace in modo asincrono.

Ricorda che async non risolve tutto. Se la pagina include un numero elevato di script, ad esempio di monitoraggio per scopi pubblicitari, il caricamento asincrono non impedirà loro di rallentare il caricamento della pagina.

Utilizzare i suggerimenti sulle risorse per ridurre i tempi di configurazione della connessione

Stabilire connessioni con origini di terze parti può richiedere molto tempo, in particolare sulle reti lente, perché le richieste di rete hanno più componenti complessi, tra cui le ricerche DNS e i reindirizzamenti. Puoi utilizzare suggerimenti di 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 seguito:

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

Se il dominio di terze parti a cui ti stai connettendo 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é prevedono 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, questo non blocca l'esecuzione della pagina principale. AMP utilizza questo approccio per escludere JavaScript dal percorso critico. Tieni presente che questo approccio blocca ancora l'evento onload, quindi cerca di non collegare le funzionalità critiche a onload.

Chrome supporta anche i criteri di autorizzazione (in precedenza Criteri relativi alle funzionalità), un insieme di criteri che consentono a uno sviluppatore di disattivare selettivamente l'accesso a determinate funzionalità del browser. Puoi utilizzarla per impedire a contenuti di terze parti di introdurre comportamenti indesiderati in un sito.

Script di terze parti con hosting autonomo

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 essere in grado di ospitarlo autonomamente.

Tuttavia, il self-hosting presenta alcuni problemi, soprattutto nell'ambito dell'aggiornamento degli script. Gli script self-hosted non ricevono aggiornamenti automatici per modifiche all'API o correzioni di sicurezza, il che può portare a perdite di entrate o problemi di sicurezza finché non potrai aggiornare manualmente lo script.

In alternativa, puoi memorizzare nella cache gli script di terze parti utilizzando i service worker, per avere un maggiore controllo sulla frequenza di recupero degli script dalla rete. Puoi utilizzare i service worker anche per creare strategie di caricamento che limitano le richieste non essenziali di terze parti fino a quando la tua pagina raggiunge un momento utente chiave.

Test A/B per campioni più piccoli di utenti

Il test A/B (o test diviso) è una tecnica per sperimentare con due versioni di una pagina al fine di analizzare l'esperienza utente e il comportamento. Rende disponibili le versioni della pagina a diversi campioni di traffico del tuo sito web e, da dati e analisi, determina quale versione offre il tasso di conversione migliore.

Tuttavia, in base alla sua progettazione, i test A/B ritardano il rendering per decidere quale esperimento deve essere attivo. JavaScript viene spesso utilizzato per verificare se alcuni dei tuoi utenti appartengono a un esperimento di test A/B e poi attivare la variante corretta. Questo processo può peggiorare l'esperienza anche per gli utenti che non fanno parte dell'esperimento.

Per velocizzare il rendering delle pagine, ti consigliamo di inviare gli script per i test A/B a un campione più ridotto della tua base utenti e di eseguire il codice che determina la versione della pagina da visualizzare sul lato server.

Caricamento lento delle risorse di terze parti

Le risorse di terze parti incorporate, come annunci e video, possono contribuire in modo significativo a rallentare la velocità delle pagine se create in modo errato. Il caricamento lento può essere utilizzato per caricare le risorse incorporate solo quando necessario, ad esempio per attendere la pubblicazione degli annunci nel piè di pagina fino a quando l'utente scorre il dito a sufficienza per vederli. Puoi anche eseguire il caricamento lento di contenuti di terze parti dopo il caricamento dei contenuti della pagina principale, ma prima che un utente possa interagire con la pagina.

Puoi utilizzare il caricamento lento per asset che l'utente non vedrà immediatamente al caricamento della pagina.

Fai attenzione quando le risorse vengono caricate lentamente, poiché spesso comporta codice JavaScript che può essere influenzato da connessioni di rete instabili.

Nota: LazySizes è una popolare libreria JavaScript per immagini e iframe con caricamento lento. Supporta gli incorporamenti e i widget di YouTube.

Le indicazioni su come eseguire il caricamento lento degli annunci di DoubleClick sono disponibili nella documentazione ufficiale di DoubleClick.

Caricamento lento efficiente con Intersection Observationr

In passato, i metodi per rilevare se un elemento è visibile nell'area visibile ai fini del caricamento lento sono soggetti a errori e spesso rallentano il browser. Questi metodi inefficienti spesso restano in ascolto di eventi scroll o resize e utilizzano le API DOM come getBoundingClientRect() per calcolare dove gli elementi sono rispetto all'area visibile.

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

Analisi del carico lento

Se rimandi troppo a lungo il caricamento dei tuoi script di analisi, potresti perderti preziosi dati di analisi. Fortunatamente, sono disponibili strategie per inizializzare l'analisi in modo lento, mantenendo al contempo i dati relativi al caricamento delle pagine in anticipo.

Il post del blog di Phil Walton La configurazione di Google Analytics che utilizzo su ogni sito che creo riguarda una di queste strategie per Google Analytics.

Carica script di terze parti in sicurezza

Questa sezione fornisce indicazioni per caricare 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 ed è difficile eseguire il debug dei suoi errori.

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

Chrome DevTools segnala l'utilizzo di document.write().

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

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

Utilizza Tag Manager con cautela

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 di social media in un sito. Questi tag aggiungono richieste di rete, dipendenze JavaScript e altre risorse alla pagina in grado di influire sulle sue prestazioni, inoltre la riduzione al minimo dell'impatto per gli utenti diventa più difficile man mano che vengono aggiunti altri tag.

Per un caricamento rapido delle pagine, ti consigliamo di utilizzare uno strumento di gestione dei tag come Google Tag Manager (GTM). GTM consente di implementare i tag in modo asincrono in modo che non si blocchino a vicenda, ridurre il numero di chiamate di rete necessarie a un browser per eseguire i tag e raccogliere i dati dei tag nell'UI del livello dati.

Rischi dell'utilizzo di tag manager

Anche se i tag manager sono progettati per semplificare il caricamento delle pagine, un loro utilizzo non attento può rallentarlo nei seguenti modi:

• Un numero eccessivo di tag e Listener di eventi automatici nel gestore di tag fa sì che il browser effettui un numero di richieste di rete superiore a quello necessario e riduce la capacità del codice di rispondere rapidamente agli eventi.
• Chiunque disponga di credenziali e accesso può aggiungere JavaScript a Tag Manager. Ciò non solo può aumentare il numero di costose richieste di rete necessarie per caricare la pagina, ma può anche comportare rischi per la sicurezza e altri problemi di prestazioni dovuti a script non necessari. Per ridurre questi rischi, ti consigliamo di limitare l'accesso a Tag Manager.

Evita script che contaminano l'ambito globale

Gli script di terze parti possono comportarsi in tutti i modi in cui la pagina viene interrotta inaspettatamente:

• Gli script che caricano le dipendenze JavaScript possono inquinare l'ambito globale con codice che interagisce in modo errato con il codice.
• Aggiornamenti imprevisti possono causare modifiche che provocano errori.
• Il codice di terze parti può essere modificato in transito in modo da comportarsi in modo diverso tra il test e il deployment della pagina.

Consigliamo di eseguire controlli regolari degli script di terze parti caricati per verificare la presenza di utenti malintenzionati. Per proteggere la pagina, puoi anche implementare i test automatici, l'integrità delle sottorisorse e la trasmissione sicura di codice di terze parti.

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 ulteriori informazioni, consulta la sezione Contenuti misti.

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

• Criterio di sicurezza del contenuto (CSP): puoi utilizzare le intestazioni HTTP nella risposta del server per definire comportamenti di script attendibili per il tuo sito, nonché rilevare e mitigare gli effetti di alcuni attacchi, ad esempio Cross Site Scripting (XSS).

Di seguito è riportato un esempio di come utilizzare l'istruzione script-src di 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 saperne di più sull'ottimizzazione di JavaScript di terze parti, ti consigliamo di leggere quanto segue:

• Prestazioni e resilienza: test di stress di terze parti
• Aggiunta interattività con JavaScript
• Potenziali pericoli legati agli script di terze parti
• In che modo gli script di terze parti possono essere cittadini efficaci sul web
• Perché la velocità è importante - La magia di CSS
• Il paradox della catena di fornitura JavaScript: SRI, CSP e fiducia nelle librerie di terze parti
• Il CSS di terze parti non è sicuro

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