5 Livelli di Priorità di JavaScript e Come Utilizzarli

Non tutti gli script sono creati uguali

Una cosa è sempre stata chiara: non tutto il JavaScript è creato uguale. Alcuni script gestiscono interazioni critiche come 'interazione con il menu' o 'aggiungi al carrello', mentre altri script sono molto meno importanti. Prendi ad esempio il tuo script di popup 'exit intent' che invita i visitatori che stanno per abbandonare il sito a compilare un questionario. Sono sicuro che potremmo tutti vivere senza questi ultimi, ma sarebbe davvero difficile navigare su un sito web senza i primi.

Eppure, sul 'sito web medio', a livello tecnico questa distinzione non viene quasi mai fatta. Tutti i JavaScript vengono 'semplicemente aggiunti' alla pagina e il browser viene lasciato a capire cosa fare. Questo è un problema perché il tuo browser non ha idea di cosa sia importante e cosa no. Noi sviluppatori sì. Quindi risolviamo il problema!

Ultima revisione a cura di Arjen Karel a Marzo 2026

La pagina mobile mediana carica 646 KB di JavaScript attraverso 22 richieste, secondo il Web Almanac 2025. Circa il 44% di quel JavaScript non viene nemmeno mai eseguito. Solo il 13% delle pagine supera l'audit delle risorse bloccanti per il rendering di Lighthouse. Il problema non è solo quanto JavaScript carichi. È quando e in che ordine.

Come la priorità di JavaScript può impattare i Core Web Vitals

Aggiungere semplicemente script alla pagina senza le giuste considerazioni può impattare tutti e 3 i Core Web Vitals. Il Largest Contentful Paint, l'Interaction to Next Paint e il Cumulative Layout Shift.

Esempio: la risorsa di rete del LCP è ritardata dai JavaScript che bloccano il rendering

Il Largest Contentful Paint è soggetto alla competizione per larghezza di banda e CPU. Quando troppi script competono per le risorse di rete iniziali, ciò ritarderà la risorsa di rete del Largest Contentful Paint, e il lavoro iniziale della CPU ritarderà l'LCP bloccando il main thread.

L'Interaction to Next Paint può essere influenzato dagli script che si eseguono subito prima di un'interazione. Quando gli script si eseguono, bloccano il main thread e ritarderanno qualsiasi interazione durante quel tempo di esecuzione.

Gli script possono anche causare un Cumulative Layout Shift se 'cambiano l'aspetto della pagina'. Gli script pubblicitari che iniettano banner nella pagina e gli slider sono noti per fare questo.

5 tipi di priorità di JavaScript

Mi piace distinguere tra 5 tipi di priorità di JavaScript.

• Render Critical: questi script sono tra i peggiori da avere. Cambiano il layout della pagina e senza caricare questi script il layout sarà completamente diverso. Esempio: alcuni script di slider o un test A/B.
• Script Critici: Questi script gestiscono funzionalità critiche della pagina e senza di essi operazioni critiche come aggiungere un prodotto al carrello, la ricerca nel sito o la navigazione non sono possibili.
• Script Importanti: Questi script gestiscono la logica di business importante e il tuo sito dipende da essi. Ad esempio: Analytics.
• Script Opzionali (Nice to Have): Questi script sono belli da avere ma, se si arriva al dunque, non ne abbiamo davvero bisogno per far funzionare la pagina. Ad esempio un widget di chat o un exit intent.
• Script Futuri: Questi script potrebbero essere critici o belli da avere ma non ne abbiamo bisogno in questo momento perché 'altri passaggi' devono essere intrapresi prima di poterli effettivamente usare. Ad esempio uno script di checkout in più fasi.

Prima di esaminare ogni livello di priorità, ecco come Chrome assegna la priorità di rete ai diversi tipi di script:

Comprendere questi valori predefiniti è la chiave per la prioritizzazione delle risorse.

1. Script Render-Critical

Questi script cambiano direttamente il layout della pagina. Senza di essi, la pagina appare completamente diversa dal suo design previsto. Gli esempi includono script per slider o framework di A/B testing che alterano il layout all'inizio del processo di caricamento.

Il problema con questi script è che non possono essere differiti (defer) o ritardati. Qualsiasi ritardo causerà uno spostamento del layout del sito web causando una scarsa UX e il fallimento dei Core Web Vitals.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Page Title</title>
    <link href="styles.css" rel="stylesheet" />
    <script src="render-critical.js"></script>
  </head>
  <body></body>
</html>

Best Practices:

• Evita gli script render-critical ogni volta che è possibile. Riscrivi il tuo codice per rimuovere la dipendenza da questi tipi di script.
• Se non è possibile evitarli, fai l'inline o carica solo le parti assolutamente necessarie di questi script.
• Non usare defer o async per questi script e posizionali in cima all'head per innescare un download 'il prima possibile'.

2. Script Critici

Questi script abilitano le interazioni fondamentali. Senza di essi, operazioni critiche come la navigazione del sito, l'aggiunta di articoli al carrello, l'avviso sui cookie o l'esecuzione di una ricerca diventano impossibili. Sono indispensabili per le funzionalità di base del sito.

Questi script dovrebbero essere posizionati nell'head della pagina con l'attributo async o defer. Per un confronto completo di questi due approcci, consulta async vs defer e come influenzano i Core Web Vitals.

<script defer src="critical.js"></script>
<script async src="critical.js"></script>

Best Practices:

• Mantieni script come questi al minimo e non combinare queste funzionalità con altre funzionalità meno critiche.
• Carica presto questi script usando async o defer, a seconda delle loro dipendenze.
• Usa il Real User Monitoring per identificare i colli di bottiglia nell'esecuzione e assicurarti che le loro performance siano in linea con le esigenze degli utenti.

3. Script Importanti

Questi script supportano il tuo business ma non sono necessari per far funzionare la pagina. Gli script di Analytics, ad esempio, forniscono dati essenziali ma non devono essere caricati prima di elementi visivi più importanti. La distinzione tra script critici e importanti può essere oggetto di dibattito, quindi assicurati di parlarne con tutti gli stakeholder prima di impostare questa priorità!

Ci sono 2 modi affidabili per abbassare la priorità degli script per questi tipi di script.

<html>
<head>
<!-- method 1: inject after DOMContentLoaded -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    var script = document.createElement('script');
    script.src = 'important.js';
    document.body.appendChild(script);
  });
</script>
</head>
<body>

<!-- method 2: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html>

1: Iniettare dopo il DOMContentLoaded

Iniettando lo script dopo l'evento DOMContentLoaded, ti assicuri che lo script inizi il download subito dopo che l'HTML è stato completamente analizzato. Questo permette alle risorse discoverable, come immagini e font, di avere la precedenza. Questo metodo offre un equilibrio: lo script inizia a caricarsi abbastanza presto da evitare ritardi nella funzionalità, ma non compete con le risorse iniziali che sono cruciali per il rendering iniziale della pagina.

2: Posizionare in fondo alla pagina

Questa tecnica classica differisce il caricamento dello script fino a quando il browser non ha elaborato l'intero documento e ottiene all'incirca lo stesso risultato della tecnica 1. L'unica differenza è che la tecnica 1 salta il preload scanner del tuo browser, mentre questa tecnica non lo fa. Il preload scanner è uno scanner rapido e leggero che il tuo browser utilizza per identificare e accodare rapidamente risorse critiche. Saltare il preload scanner potrebbe essere una buona idea se c'è la possibilità di avere immagini in lazy loading nel viewport, mentre utilizzare il preload scanner velocizzerà il caricamento per questo script.

Una nota su fetchpriority: potresti aspettarti che fetchpriority="low" su uno script differito abbassi la sua priorità. Non è così. Gli script deferred e async vengono già caricati a priorità Bassa in Chrome. Aggiungere fetchpriority="low" a questi script non ha alcun effetto (no-op). L'attributo fetchpriority fa la differenza solo sugli script bloccanti, dove può abbassare la priorità da Massima ad Alta. Per ulteriori modi per differire JavaScript, consulta la nostra guida completa.

4. Script Opzionali (Nice-to-Have)

Questi script migliorano la UX ma non sono necessari per il funzionamento del sito. Gli esempi includono widget di chat, popup per il feedback dei clienti o animazioni opzionali.

Questi script sono i candidati ideali per un pattern chiamato 'lazy on load'. Questo significa: attendere l'evento load della pagina e poi, durante il tempo di inattività (idle time), iniettare lo script. Aspettare l'evento load assicura che lo script non competa per la larghezza di banda e la CPU con risorse iniziali più importanti. Aspettare un momento di inattività assicura che il browser non stia gestendo compiti più importanti come l'input dell'utente.

Ecco un esempio funzionante:

window.addEventListener("load", () => {
  const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1));
  idle(() => {
    const script = document.createElement("script");
    script.src = "/path/to/script.js";
    document.head.appendChild(script);
  });
});

Il fallback con setTimeout è necessario perché Safari non supporta requestIdleCallback. Per gli script che devono anche suddividere la loro esecuzione in frammenti più piccoli, considera l'utilizzo di scheduler.yield() per mantenere reattivo il main thread e proteggere il tuo punteggio INP.

Best Practices:

• Carica questi script in lazy-load dopo che la pagina si è caricata e attendi un momento di inattività (idle moment).
• Comprendi che gli script caricati con questo pattern non sono garantiti per caricarsi velocemente.

Sui siti monitorati da CoreDash, le pagine che differiscono gli script non critici a dopo l'evento load ottengono un punteggio dell'84% come 'buono' sull'INP, rispetto al 61% per le pagine che caricano tutti gli script in modo eagerly (anticipato).

5. Script Futuri

Gli script futuri sono quelli di cui non si avrà bisogno finché non vengono soddisfatte condizioni specifiche. Ad esempio, uno script per un checkout in più fasi diventa rilevante solo dopo che l'utente ha aggiunto articoli al carrello. Questi script possono aspettare fino a molto più tardi nel percorso dell'utente.

Dai un'occhiata a questo esempio. Usa l'IntersectionObserver per caricare la logica JS solo quando è necessaria: quando il form si trova nel viewport visibile.

<!DOCTYPE html>
<html>
  <head>
    <script>
      document.addEventListener("DOMContentLoaded", function () {
        const form = document.querySelector("form");
        const observer = new IntersectionObserver(function (entries) {
          entries.forEach((entry) => {
            if (entry.isIntersecting) {
              const script = document.createElement("script");
              script.src = "/sign-up.js";
              document.head.appendChild(script);
              observer.unobserve(form);
            }
          });
        });
        observer.observe(form);
      });
    </script>
  </head>
  <body>
    <form action="/sign-up" method="post">
      <label for="email">Email:</label>
      <input type="email" id="email" name="email" required />
      <button type="submit">Sign Up</button>
    </form>
  </body>
</html>

Best Practices:

• Carica questi script on demand, innescati dalle azioni dell'utente.
• Usa tecniche di code-splitting per consegnare solo le parti richieste in ogni passaggio.
• Iniettali dinamicamente solo quando servono, ad esempio quando un utente scrolla fino a una sezione specifica.

La maggior parte dei siti ha bisogno solo di due pattern: defer per tutto ciò che è funzionale e il pattern load+idle per tutto il resto. Se stai spendendo tempo a perfezionare la fetchpriority sugli script, probabilmente stai complicando troppo le cose. Ottieni prima i grandi risultati: usa defer per ciò che puoi, ritarda ciò che puoi e elimina ciò di cui non hai bisogno.