Perché è importante per il vostro negozio
60–80%
del tempo di esecuzione degli script proviene da app di terze parti
3+ sec
di ritardo dovuto agli script delle app su un negozio tipico
7%
di calo delle conversioni per ogni ritardo di 1 secondo
La soluzione semplice: ottimizzazione automatica degli script
Gli script di terze parti sono il problema di velocità più difficile da risolvere a mano: non potete modificare il codice delle app, e un rinvio ingenuo rompe le funzionalità. Thunder Page Speed Optimizer è stato costruito appositamente per risolvere questo problema.
Cosa fa Thunder con gli script delle vostre app:
Rinvio intelligente degli script
Rinvia gli script di terze parti preservando ordine di esecuzione e dipendenze
Mappatura delle dipendenze
Capisce quali script dipendono l'uno dall'altro — non romperà le vostre app
Report di impatto per singola app
Mostra esattamente quanti millisecondi ogni app aggiunge al caricamento della pagina
Si adatta automaticamente ai cambiamenti
Nuova app installata? Tema aggiornato? Thunder si adatta automaticamente
Miglioramento medio: +27 punti PageSpeed
I negozi con molte app registrano i guadagni maggiori: tempi di caricamento spesso più veloci del 20–60%. Valutazione 4.6★ · 20,000+ negozi.
Piano gratuito disponibile · Nessuna carta di credito richiesta · Configurazione in 30 secondi · Funziona con tutti i temi
1. Cosa sono gli script di terze parti (e perché dovrebbero interessarvi)?
Ogni volta che installate un'app dallo Shopify App Store, quell'app ha bisogno di un modo per mostrare le proprie funzionalità sul vostro storefront. Un widget di recensioni deve mostrare le stelle. Un'app di chat deve mostrare la bolla della chat. Un popup email deve... beh, comparire.
Per farlo, ogni app inietta file JavaScript (script) nell'HTML del vostro negozio. Si chiamano "script di terze parti" perché provengono da server esterni, non dall'infrastruttura di Shopify né dal codice del vostro tema.
Ecco il problema: il browser del visitatore deve scaricare, interpretare ed eseguire ognuno di questi script prima di poter completare il caricamento della pagina. E a differenza del codice del tema, che Shopify ha ottimizzato e serve dal suo CDN, gli script di terze parti arrivano da decine di server diversi con prestazioni variabili.
🔴 Il problema di fondo: il tema si carica una volta e pesa forse 200–400KB di JavaScript. Ma gli script delle app di terze parti possono aggiungere collettivamente 1–3MB di JavaScript in più — 3–10 volte più dell'intero tema. Ogni kilobyte deve essere scaricato sulla connessione del visitatore ed elaborato dalla CPU del suo dispositivo.
Non è una preoccupazione solo teorica. Le ricerche dell'HTTP Archive e di Google mostrano costantemente che il JavaScript di terze parti rappresenta il 60–80% del tempo totale di esecuzione degli script sul sito ecommerce medio. Sui negozi Shopify in particolare, abbiamo visto questo numero raggiungere l'85% nei negozi pieni di app.
L'ironia crudele? La maggior parte di questi script si carica su ogni pagina del negozio, anche quando le funzionalità dell'app non sono visibili. Il JavaScript del widget di recensioni si carica sulla homepage, sulla pagina Chi siamo, sulla pagina contatti — ovunque — anche se le recensioni compaiono solo sulle pagine prodotto.
2. Come si caricano gli script di terze parti nel browser
Per capire perché gli script di terze parti danneggiano così tanto le prestazioni, bisogna capire come i browser caricano una pagina. Ecco la versione semplificata:
L'HTML arriva
Il browser riceve l'HTML della pagina dai server di Shopify. Questo è veloce: l'infrastruttura di Shopify è solida.
Il browser inizia a interpretare l'HTML
Mentre legge l'HTML, scopre le risorse da caricare: file CSS, file JavaScript, immagini, font.
⚠️ I tag script bloccano il rendering
Quando il parser incontra un tag <script> senza async o defer, ferma tutto. Deve scaricare lo script, interpretarlo ed eseguirlo prima di continuare. Questo si chiama "render blocking".
⚠️ Ogni script effettua richieste di rete
Molti script delle app non sono autonomi. Caricano file aggiuntivi: dati di configurazione, template dei widget, librerie di analytics. Ognuno richiede il proprio lookup DNS, la propria connessione e il proprio download.
La pagina finalmente si renderizza
Solo dopo che tutti gli script bloccanti hanno finito di eseguirsi il browser mostra la pagina. Il vostro visitatore ha fissato per tutto questo tempo uno schermo vuoto o caricato a metà.
Molti sviluppatori di app non aggiungono gli attributi async o defer ai loro tag script — o perché non conoscono le best practice di performance, o perché i loro script dipendono dal DOM in uno stato specifico. Il risultato: i loro script bloccano il rendering della vostra pagina, danneggiando direttamente i vostri punteggi di Largest Contentful Paint (LCP) e Interaction to Next Paint (INP).
La timeline di caricamento
0ms — HTML ricevuto da Shopify
50ms — CSS interpretato, inizia il layout
100ms — ⏸ Script: review-widget.js (bloccante, 300ms)
400ms — ⏸ Script: chat-app.js (bloccante, 250ms)
650ms — ⏸ Script: analytics.js (bloccante, 200ms)
850ms — ⏸ Script: popup-builder.js (bloccante, 350ms)
1200ms — ⏸ Script: loyalty-program.js (bloccante, 200ms)
1400ms — ⏸ Ogni script carica ALTRI 2-3 script...
2800ms — Gli script finiscono finalmente l'esecuzione
3000ms — 🖼️ La pagina si renderizza (il visitatore vede il contenuto)
Timeline semplificata che mostra come il blocco degli script ritarda il rendering della pagina
In questo esempio, 2.8 secondi dei 3 secondi di caricamento sono spesi solo per gli script di terze parti. Il contenuto vero della pagina — i prodotti, le immagini, il brand — potrebbe caricarsi in meno di 500ms se gli script non fossero d'intralcio.
3. Esempi reali: quanto vi costa ogni tipo di app
Non tutte le app pesano allo stesso modo. Ecco cosa vediamo tipicamente sui negozi Shopify, sulla base di misurazioni reali:
💬 Widget di chat dal vivo
300–500msEsempi: Tidio, Gorgias, Zendesk Chat, LiveChat, Intercom
I widget di chat sono tra le app più pesanti. Caricano un intero framework UI, stabiliscono una connessione WebSocket, recuperano la cronologia delle conversazioni e renderizzano una bolla di chat con animazioni. Intercom da solo carica 300–500KB di JavaScript. La maggior parte di questo gira su ogni pagina, anche se la maggior parte dei visitatori non clicca mai sulla bolla della chat.
⭐ Widget di recensioni
200–400msEsempi: Judge.me, Loox, Yotpo, Stamped.io, Okendo
Le app di recensioni caricano il loro JavaScript principale, poi effettuano chiamate API per recuperare i dati delle recensioni, renderizzare le stelle e attivare le funzionalità interattive (caroselli fotografici, filtri, ordinamento). Anche sulle pagine senza recensioni visualizzate, lo script si carica e si inizializza comunque. Judge.me è tra le opzioni più leggere; Yotpo e Loox tendono a essere più pesanti.
📧 Email marketing e popup
200–350msEsempi: Klaviyo, Omnisend, Privy, Justuno, OptiMonk
Queste app caricano script per il rendering dei moduli, il tracciamento degli utenti, la logica dei popup (tempistiche, regole di targeting, test A/B) e spesso includono i propri framework CSS. Il JavaScript onsite di Klaviyo è particolarmente pesante perché traccia il comportamento degli utenti per la segmentazione, caricando codice di analytics, tracciamento di sessione e gestori dei moduli su ogni pagina.
📊 Analytics e tracciamento
100–300msEsempi: Google Analytics, Facebook Pixel, TikTok Pixel, Hotjar, Lucky Orange, Pinterest Tag
Gli script di analytics sono subdoli. Ognuno sembra piccolo — forse 50–100KB. Ma i negozi spesso eseguono 4–6 script di tracciamento contemporaneamente: GA4, Facebook Pixel, TikTok Pixel, Hotjar per le heatmap, più l'app di analytics del negozio stesso. Insieme arrivano a 300–600KB, e in più ognuno effettua richieste di rete per inviare i dati di tracciamento.
🏷️ Google Tag Manager (GTM)
300–800msIl contenitore di script di terze parti #1. GTM non è solo un altro script: è uno script che carica altri script.
Il container GTM da solo pesa 80–100KB+. Ma il costo vero viene da ciò che c'è dentro: Meta Pixel (80–150KB), TikTok Pixel (100–200KB), tracciamento conversioni Google Ads (50–100KB), tracciamento Klaviyo (100–200KB), Hotjar (150–300KB) e qualsiasi altra cosa aggiunta nel tempo. Un container GTM tipico attiva 5–15 script aggiuntivi, aggiungendo 300–800ms al tempo totale di caricamento.
Come fare un audit del vostro container GTM:
- Aprite Google Tag Manager e selezionate il vostro container.
- Andate su Tags e contate quanti sono attivi. La maggior parte dei negozi ne ha 10–30+.
- Controllate il Trigger di ogni tag: se dice "All Pages", chiedetevi: deve davvero attivarsi ovunque?
- Cercate i tag zombie di vecchie campagne (vecchi pubblici Facebook, strumenti dismessi).
- Usate la modalità Preview di GTM per vedere esattamente quali tag si attivano su ogni pagina e quanto tempo richiedono.
Tag pesanti comuni dentro GTM:
⚡ L'approccio di Thunder: invece di rinviare i singoli tag dentro GTM (cosa che richiede competenze GTM), Thunder rinvia l'intero container GTM. Quando GTM si carica più tardi, anche tutti i tag al suo interno si caricano più tardi — automaticamente. Questa singola ottimizzazione può far risparmiare 300–800ms senza toccare la configurazione GTM. Provatelo gratis →
GTM, Meta e TikTok: risolvi un calo da tracking senza rimuovere l’attribuzione alla cieca
Un forte calo dopo l’aggiunta di GTM e pixel è un segnale diagnostico, non un motivo per eliminare Google Tag Manager. Lo stesso fornitore viene spesso caricato più volte: tramite eventi cliente o pixel Shopify, app Google & YouTube, snippet del tema e GTM.
- Esegui il test gratuito di velocità Shopify su homepage e pagina prodotto.
- Controlla eventi cliente, incorporamenti app, app del canale di vendita, codice del tema e GTM Preview per ID e tag «All Pages» duplicati.
- Mantieni un solo percorso di installazione intenzionale per fornitore, poi verifica eventi di pageview, prodotto, aggiunta al carrello e acquisto.
I tag di consenso e attribuzione necessari non devono essere ritardati troppo. I tag marketing opzionali possono caricarsi dopo il contenuto visibile o solo sui template pertinenti. Identifica prima gli script Shopify o Google sconosciuti con l’analizzatore Shopify.
🎨 Page builder e app di upsell
200–500msEsempi: PageFly, Shogun, GemPages, ReConvert, Bold Upsell
I page builder come PageFly iniettano il proprio framework di rendering, che si carica su ogni pagina — anche su quelle che non avete costruito con l'app. Le app di upsell caricano su ogni pagina la logica di raccomandazione prodotti, gli script di modifica del carrello e le UI dei popup, per farsi trovare pronte quando un cliente aggiunge al carrello.
🔔 Social proof e urgenza
100–250msEsempi: Sales Pop, Fomo, badge di fiducia, timer per il conto alla rovescia, contatori di stock
Sembrano leggere, ma spesso causano spostamenti di layout (problemi di CLS). Iniettano elementi nella pagina dopo il caricamento — popup di notifica, barre con badge di fiducia, conti alla rovescia — spostando i contenuti e creando un'esperienza utente traballante. In più, ognuna è un altro script che il browser deve elaborare.
4. L'effetto cascata: morte per mille script
Nessuna singola app uccide la vostra velocità. È la combinazione a farlo. Ecco come si presenta un tipico negozio Shopify pieno di app:
Uno stack di app reale (15 app)
Tre secondi pieni di ritardo — solo dagli script delle app. Aggiungete il JavaScript del tema (~300ms), il CSS (~100ms), le immagini (~500ms) e i font (~200ms), e vi ritrovate con un caricamento pagina di 4+ secondi su una buona connessione. Su un dispositivo mobile con connessione 3G, raddoppiate. Se il vostro negozio somiglia a questo, la nostra guida passo passo vi accompagna nella correzione di ogni livello — non solo degli script.
15 app
numero medio di app su un negozio Shopify
~200ms
ritardo medio per ogni script di app
3+ sec
ritardo totale degli script di terze parti
Ma il conto è in realtà peggiore di una semplice somma. Gli script non aggiungono tempo in modo lineare: competono per le risorse:
- • Contesa di rete: i browser limitano le connessioni simultanee per dominio (in genere 6). Quando 15 app provano a caricarsi da 15 domini diversi contemporaneamente, si mettono in coda e si aspettano a vicenda.
- • Contesa di CPU: JavaScript è single-thread. Mentre uno script viene eseguito sul main thread, tutti gli altri devono aspettare. Ecco perché l'INP (Interaction to Next Paint) ne soffre: il browser non può rispondere ai clic dell'utente mentre è impegnato a eseguire il codice delle app.
- • Pressione sulla memoria: ogni script alloca memoria. Sugli smartphone economici (che rappresentano una grande fetta degli acquirenti mobile), un uso eccessivo di memoria rallenta il browser o addirittura lo fa crashare.
- • Richieste secondarie: la maggior parte degli script delle app carica risorse aggiuntive. Un widget di recensioni carica lo script principale, che poi carica CSS, icone dei font e dati API. Il "singolo script" di un'app può innescare 5–10 richieste di rete aggiuntive.
💡 La lezione: non si tratta di una singola app "troppo lenta". È il peso accumulato di tutte le app che si caricano insieme, in competizione per banda di rete, tempo di CPU e memoria. La soluzione non è necessariamente rimuovere le app: è controllare quando e come si caricano.
5. Come fare un audit degli script di terze parti sul vostro negozio
Prima di poter risolvere il problema, dovete identificare esattamente quali script lo causano. Iniziate con una base di partenza rapida: testate la velocità del vostro negozio per vedere dove vi trovate adesso. Poi usate questi metodi, dal più tecnico al più semplice:
Metodo 1: la scheda Network di Chrome DevTools
È la vista più dettagliata di ciò che si carica sulla vostra pagina.
- Aprite il negozio in Chrome. Premete F12 (o clic destro → Ispeziona) per aprire DevTools.
- Cliccate sulla scheda Network.
- Spuntate la casella "Disable cache" (simula un visitatore alla prima visita).
- Ricaricate la pagina (Ctrl+Shift+R per un ricaricamento forzato).
- Cliccate sul filtro "JS" per mostrare solo i file JavaScript.
- Ordinate per colonna "Size" o "Time" per trovare gli script più pesanti/lenti.
Cosa cercare: gli script da domini che non riconoscete sono di terze parti. I pattern comuni includono cdn.judge.me, static.klaviyo.com, widget.intercom.io, ecc. Annotate dominio, dimensione del file e tempo di caricamento per ciascuno.
Metodo 2: lo strumento Coverage di Chrome
Lo strumento Coverage mostra quanta parte di ogni file JavaScript viene effettivamente usata nella pagina corrente. Questo rivela lo spreco: script che caricano centinaia di KB ma usano solo il 10–20% del loro codice.
- Aprite DevTools (F12).
- Premete Ctrl+Shift+P (menu comandi) e digitate "Coverage".
- Cliccate su "Show Coverage".
- Cliccate sul pulsante di ricaricamento nel pannello Coverage.
- Dopo il caricamento della pagina, ordinate per "Unused Bytes".
Campanello d'allarme: se uno script ha l'80%+ di byte inutilizzati, sta caricando molto più codice del necessario per la pagina corrente. È comune con i grandi bundle delle app che includono funzionalità per ogni pagina ma ne usano solo una frazione su ciascuna.
Metodo 3: "Reduce JavaScript Execution Time" di PageSpeed Insights
L'approccio più semplice. Fate passare il vostro negozio da PageSpeed Insights e cercate queste diagnostiche specifiche:
- "Reduce JavaScript execution time" — elenca gli script più pesanti per tempo di esecuzione
- "Reduce the impact of third-party code" — mostra gli script di terze parti raggruppati per fornitore con il loro tempo di blocco
- "Minimize main-thread work" — mostra la ripartizione del tempo totale sul main thread per categoria
- "Avoid enormous network payloads" — segnala le risorse sovradimensionate
Metodo 4: usate lo scanner delle app di Thunder (il più facile)
Thunder scansiona automaticamente le app Shopify installate e genera un report di impatto sulla velocità per singola app, mostrando esattamente quanti millisecondi e kilobyte ogni app aggiunge al caricamento della pagina. Nessuna conoscenza di DevTools richiesta. Installate l'app e il report compare nella vostra dashboard Shopify.
6. Come risolvere gli script di terze parti lenti
⚠️ Difficoltà: da intermedia ad avanzata. L'ottimizzazione manuale degli script richiede la comprensione dell'ordine di esecuzione JavaScript, delle catene di dipendenze e del templating Liquid di Shopify. Un errore può rompere il checkout o le app. Thunder automatizza tutto questo con una configurazione di 30 secondi.
Una volta identificati i colpevoli, ecco cosa potete fare, in ordine di efficacia:
Soluzione 1: rimuovete ciò che non vi serve
Lo script più veloce è quello che non si carica mai. Passate in rassegna le app installate e valutate onestamente ciascuna:
- App provate una volta e dimenticate. Controllate il vostro admin Shopify → App. Vi sorprenderà quante app "di prova" sono ancora installate.
- Funzionalità duplicate. Usate sia Klaviyo che Omnisend? Sia Loox che Judge.me? Sceglietene una.
- App di scarso valore. Quella notifica "Sales Pop" che mostra "Qualcuno a Toronto ha appena comprato..."? Aggiunge 100–200ms di caricamento. Sta davvero generando conversioni o è solo rumore?
- Residui stagionali. Il conto alla rovescia delle feste ancora installato a febbraio? Rimuovetelo.
Passaggio critico: dopo la disinstallazione, controllate il codice del tema. Andate su Negozio online → Temi → Modifica codice e cercate il nome dell'app in theme.liquid e nei file di layout/. Molte app lasciano tag script che continuano a caricarsi anche dopo la disinstallazione.
Soluzione 2: trovate alternative più leggere
Non tutte le app della stessa categoria hanno lo stesso impatto sulle prestazioni. Per esempio:
- Recensioni: Judge.me è nettamente più leggera di Yotpo o Loox
- Email marketing: Shopify Email è più leggera di Klaviyo per esigenze di base
- Chat: Shopify Inbox è più leggera di Intercom o Gorgias
- Analytics: gli analytics integrati di Shopify + GA4 possono bastare senza Hotjar, Lucky Orange E Mixpanel insieme
Soluzione 3: rinviate gli script non critici
Per le app che volete tenere, la seconda opzione migliore è cambiare quando i loro script si caricano. Invece di bloccare il rendering della pagina, rinviateli fino a quando il contenuto principale è visibile:
- Approccio manuale: modificate
theme.liquiddel tema e aggiungetedeferai tag script delle app. Rischioso: può rompere le app se fatto male. - Ritardo fino all'interazione: alcuni sviluppatori usano una tecnica in cui gli script si caricano solo dopo la prima interazione dell'utente (scroll, clic, tocco). Migliora drasticamente il caricamento iniziale, ma le funzionalità non sono pronte immediatamente.
- Usate un ottimizzatore di script: strumenti come Thunder automatizzano questo processo, rinviando gli script in modo intelligente e mantenendo le funzionalità. Per maggiori dettagli, consultate la nostra guida completa all'ottimizzazione della velocità.
Soluzione 4: caricamento condizionale (script specifici per pagina)
Perché caricare lo script del widget di recensioni sulla homepage, quando le recensioni compaiono solo sulle pagine prodotto? Il caricamento condizionale garantisce che gli script si carichino solo dove servono.
In Liquid, potete racchiudere i tag script delle app in condizioni sul template:
{% if template contains 'product' %}
<script src="review-widget.js"></script>
{% endif %}
È una tecnica potente, ma richiede la modifica del codice del tema e la conoscenza di quali app servono su quali pagine. Alcune app iniettano i loro script in modi che rendono difficile farlo senza rompere le funzionalità.
7. L'approccio Thunder: ottimizzazione automatizzata degli script
Tutte le soluzioni sopra funzionano, ma condividono un problema: sono manuali, fragili e difficili da mantenere. Le app aggiornano i loro script. Nuove app vengono installate. Gli aggiornamenti del tema possono sovrascrivere le vostre modifiche. Vi servirebbe uno sviluppatore che monitori e aggiusti costantemente.
Per questo abbiamo costruito Thunder. Invece di modificare a mano i tag script sperando che non si rompa nulla, Thunder automaticamente:
- ✓ Scansiona tutte le app installate e genera un report di impatto sulla velocità per singola app
- ✓ Rinvia in modo intelligente gli script non critici, che si caricano dopo che il contenuto della pagina è visibile
- ✓ Preserva le dipendenze tra gli script — capisce quali script devono caricarsi prima di altri
- ✓ Monitora i Core Web Vitals, così potete vedere l'impatto reale nella vostra dashboard Shopify
- ✓ Si adatta automaticamente quando le app aggiornano i loro script o ne installate di nuove
Il risultato: i negozi registrano tipicamente un miglioramento del 20–60% nei tempi di caricamento, con i guadagni maggiori nei negozi con più app di terze parti. Se il vostro punteggio PageSpeed è attualmente 25–35, con la sola ottimizzazione degli script potete realisticamente raggiungere 50–70+. Volete vedere cosa è incluso? Guardate i piani di Thunder — c'è un livello gratuito per iniziare.
Non siete sicuri che Thunder sia la scelta giusta? Abbiamo scritto confronti onesti con ogni concorrente principale: Thunder vs Booster, Thunder vs Hyperspeed, Thunder vs Avada e Thunder vs Tapita. Oppure guardate la nostra panoramica completa delle migliori app di ottimizzazione della velocità Shopify per il 2026.
Domande frequenti
Cosa sono gli script di terze parti su Shopify?
Gli script di terze parti sono file JavaScript caricati dalle app installate sul vostro negozio Shopify. Quando installate un widget di recensioni, un'app di chat, un popup email o uno strumento di analytics, ognuno inietta il proprio JavaScript nel vostro storefront. Questi script vengono eseguiti nel browser dei visitatori insieme al codice del tema, in competizione per il tempo di elaborazione e la banda di rete.
Come trovo quali app stanno rallentando il mio negozio Shopify?
Aprite Chrome DevTools (F12), andate nella scheda Network, ricaricate la pagina e filtrate per 'JS'. Cercate gli script provenienti da domini esterni: sono gli script delle app di terze parti. Ordinate per dimensione o tempo per trovare i peggiori colpevoli. Per un approccio più semplice, usate lo strumento Coverage (Ctrl+Shift+P → 'Coverage') per vedere quanta parte di ogni script viene effettivamente usata. Lo scanner delle app di Thunder automatizza l'intero processo e vi fornisce un report di impatto per singola app.
Le app Shopify disinstallate rallentano ancora il negozio?
Sì, spesso è così. Molte app Shopify iniettano frammenti di codice nei file del tema (soprattutto theme.liquid) durante l'installazione. Quando disinstallate l'app, questi frammenti restano. Dovete controllare manualmente il codice del tema e rimuovere i tag script rimasti. Cercate nei file del tema il nome dell'app o il dominio del suo script per trovare il codice orfano.
Quante app Shopify sono troppe?
Non esiste un numero magico: dipende dal peso di ogni app. Un negozio con 30 app leggere può essere più veloce di uno con 5 app pesanti. Il negozio Shopify medio ha 15-25 app installate. Concentratevi sulla misurazione dell'impatto reale di ogni app sul tempo di caricamento anziché contare le app. Come regola generale, se il punteggio PageSpeed scende di oltre 5 punti dopo l'installazione di un'app, quell'app ha bisogno di ottimizzazione.
Posso rinviare gli script di terze parti senza rompere le mie app?
Sì, ma serve attenzione. Un rinvio ingenuo degli script può compromettere le funzionalità delle app: per esempio, rinviare lo script di un widget di recensioni può far comparire le recensioni all'improvviso dopo il caricamento della pagina, oppure rinviare uno script di analytics può far perdere il tracciamento delle pageview. Strumenti di rinvio intelligenti come Thunder comprendono le dipendenze tra gli script e li rinviano nell'ordine corretto, preservando le funzionalità e migliorando i tempi di caricamento.
Come riduco il tempo di esecuzione JavaScript su Shopify?
Per ridurre il tempo di esecuzione JavaScript, iniziate rimuovendo le app inutilizzate e il loro codice residuo da theme.liquid. Poi rinviate gli script di terze parti non critici in modo che si carichino dopo il contenuto principale. Usate il pannello Performance di Chrome DevTools per trovare gli script più pesanti: tutto ciò che supera i 100ms di lavoro sul main thread è un candidato al rinvio. I container di Google Tag Manager spesso valgono da soli 300-800ms perché caricano più script di tracciamento. Un ottimizzatore di velocità come Thunder automatizza il rinvio degli script preservando le funzionalità, con un risparmio tipico di 1-3 secondi di tempo di esecuzione.
Qual è la differenza tra async e defer per gli script?
Sia async che defer permettono al browser di continuare a interpretare l'HTML mentre scarica lo script. La differenza: gli script 'async' vengono eseguiti appena scaricati (potenzialmente fuori ordine), mentre gli script 'defer' vengono eseguiti dopo il parsing completo dell'HTML, nell'ordine in cui compaiono. Per gli script delle app di terze parti, 'defer' è di solito più sicuro perché preserva l'ordine di esecuzione. L'approccio migliore, però, è ritardare del tutto gli script fino a quando la pagina è interattiva: è ciò che fanno le app di ottimizzazione della velocità.