MAISON CODE .
/ Performance · Webpack · Javascript · React · Core Web Vitals

Dimensione del pacchetto: la dieta per il tuo JavaScript

JavaScript è la risorsa più costosa sul web. Una guida tecnica su Tree Shaking, Code Splitting e utilizzo di Partytown per sopravvivere all'apocalisse degli script di terze parti.

AB
Alex B.
Dimensione del pacchetto: la dieta per il tuo JavaScript

“Il sito è veloce sul mio MacBook Pro.” Questa è la frase più pericolosa nell’ingegneria del frontend. Il tuo MacBook Pro ha un chip M3 Max. Analizza 1 MB di JavaScript in 50 ms. Il tuo utente ha un Samsung Galaxy A15 da € 200. Analizza lo stesso 1 MB in 2,5 secondi. Durante questi 2,5 secondi, il thread principale viene congelato. L’utente fa clic su “Aggiungi al carrello”. Non succede nulla. Se ne vanno.

Nel 2025, la velocità della rete (4G/5G) rappresenta raramente il collo di bottiglia per l’e-commerce. La CPU è il collo di bottiglia. E la metrica che tiene traccia di questo è Interazione con Next Paint (INP). Per correggere INP, è necessario ridurre il payload JavaScript.

Noi di Maison Code Paris applichiamo budget rigorosi: <100KB di caricamento iniziale.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

1. Il costo delle importazioni: lo scuotimento degli alberi

Tree Shaking (Dead Code Elimination) è il processo di rimozione delle esportazioni inutilizzate dal pacchetto. Ma non funziona per magia. È necessario scrivere un codice che sia “Shakeable”.

La trappola del file barile

Gli sviluppatori adorano i “Barrel Files” (“index.ts` che esporta tutto). Distruggono Tree Shaking.

Modello errato: “dattiloscritto”. // componenti/index.ts esporta * da ’./Button’; esporta * da ’./Carousel’; // Componente gigante da 50kb esporta * da ’./Table’;

// App.tsx importa {Pulsante} da ’./components’;

In molte configurazioni di bundle (in particolare Webpack meno recenti), l'importazione di "Button" includerà anche "Carousel" nel bundle, a causa delle limitazioni nel rilevamento degli effetti collaterali.

**Correzione**: importazioni dirette o configurazione attenta di `sideEffects: false` in `package.json`.

### La trappola della biblioteca (Lodash)
`import { map } from 'lodash';` inserisce l'intera libreria da 70KB.
Utilizza `lodash-es` o importazioni specifiche: `import map from 'lodash/map';`.
Ancora meglio, usa metodi di array nativi. `[].map()` costa 0 byte.

## 2. Suddivisione del codice: percorsi di caricamento lento

Perché inviare il codice "Admin Dashboard" a un cliente che sta semplicemente acquistando una maglietta?
Utilizziamo la **suddivisione del codice basata sul percorso**.

In **Next.js (App Router)**, questo avviene automaticamente per i file `page.tsx`.
In **Vite/React Router**, devi utilizzare `lazy()`.

"tsx
import { pigro, Suspense } da 'react';

// Questa importazione dinamica crea un blocco separato (ad esempio, Settings.chunk.js)
const ImpostazioniPagina = lazy(() => import('./pages/Settings'));

funzione App() {
  ritorno (
    <Percorsi>
      <Percorso del percorso="/" elemento={<Home />} />
      <Percorso del percorso="/impostazioni" elemento={
        <Suspense fallback={<Spinner />}>
          <PaginaImpostazioni />
        </Suspense>
      } />
    </Rotte>
  );
}

Suddivisione a livello di componente

Il tuo “Visualizzatore di modelli 3D” è pesante? Non caricarlo al caricamento della pagina. Caricalo durante l’interazione.

“tsx const ModelViewer = Dynamic(() => import(’./ModelViewer’), { ssr: false });

funzione PaginaProdotto() { const [show3D, setShow3D] = useState(false);

ritorno ( <> <button onClick={() => setShow3D(true)}>Visualizza in 3D {mostra3D && } </> ); }

Il pesante JS viene scaricato solo quando l'utente lo richiede effettivamente.

## 3. Visualizzare il gonfiore

Non puoi aggiustare ciò che non puoi vedere.
Utilizziamo `@next/bundle-analyzer` (o `rollup-plugin-visualizer`).
Eseguilo prima di ogni distribuzione.

Troverai gli orrori:
* **Three.js** all'interno del bundle della home page?
* **Moment.js** versioni locali? (Utilizza l'API "date-fns" o "Intl").
* **Faker.js** in produzione? (Dovrebbe essere una devDependency).

In genere riduciamo le dimensioni del bundle del 30% semplicemente eliminando le dipendenze inutilizzate trovate nel visualizzatore.

## 4. Script di terze parti: la soluzione "Partytown".

Hai ottimizzato il codice dell'applicazione a 50 KB. Perfetto.
Quindi il team di marketing aggiunge GTM (Google Tag Manager).
GTM inietta:
*Pixel di Facebook (40KB)
*Pixel TikTok (50KB)
*Hotjar (70KB)
* Klaviyo (40KB)
* Gorgia (200KB)

All'improvviso, il tuo thread principale viene bloccato da 500 KB di script di marketing.
La soluzione è **Architettura off-main-thread**.

Usiamo **Partytown**.
Esegue script di terze parti in un **Web Worker**.
Procura l'accesso DOM (ad esempio, `document.cookie`) dal lavoratore al thread principale tramite XHR sincrono (Atomic Wait).

"tsx
// layout.tsx (Next.js)
import { Validazione } da './Partytown';

<Testa>
  <Partytown debug={true} forward={['dataLayer.push']} />
</Testa>
<Copione
  src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"
  type="text/partytown" // Attributo magico
/>

Risultato: il pixel di Facebook viene eseguito su un thread in background. Calcola i dati di tracciamento senza bloccare il pulsante “Aggiungi al carrello”. L’INP migliora notevolmente.

5. Formati moderni: spedizione con meno codice

I polyfill sono obsoleti

Supporti Internet Explorer 11? No. Interrompi la spedizione di polyfill per “Promise”, “Map”, “Set”, “fetch”. Imposta la destinazione browserlist su “default, non IE 11”. Ciò rimuove circa 30 KB di spazzatura legacy.

Compressione Brotli

Gzip è buono. Brotli è migliore. Brotli (br) comprime JavaScript circa il 20% meglio di Gzip. Assicurati che il tuo CDN (CloudFront/Vercel) abbia Brotli abilitato.

6. Ottimizzazione dell’immagine: il carico utile nascosto

JavaScript è il collo di bottiglia della CPU, ma le immagini sono il collo di bottiglia della larghezza di banda. Se carichi un PNG da 2 MB su una connessione 4G, il download di JS verrà ritardato. Strategia:

  1. Formato: utilizza AVIF. È più piccolo del 30% rispetto a WebP.
  2. Caricamento lento: <img caricamento="lazy"> per tutto quanto Below the Fold.
  3. Dimensioni: imposta sempre “larghezza” e “altezza” per evitare spostamenti di layout (CLS).
  4. CDN: utilizza Cloudinary o Imgix per ridimensionare al volo. immagine.jpg?w=400&q=auto

7. Strategia di caricamento dei caratteri

I caratteri bloccano il rendering. Se i tuoi file OTF sono 100KB, il testo è invisibile (FOIT) per 2 secondi. Correzione:

  1. Self-Host: non utilizzare Google Fonts. La ricerca DNS ti sorprende.
  2. Sottoinsieme: rimuovi i glifi che non usi (ad esempio, i caratteri cirillici).
  3. Scambio visualizzazione: font-display: swap;. Mostra immediatamente il carattere di riserva.
  4. Precarica: <link rel="preload" href="/font.woff2" as="font"> solo per il carattere dell’intestazione.

8. Il DX “Costo di importazione”.

Gli sviluppatori sono pigri. Se possono importare una libreria, lo faranno. Installa l’estensione Costo di importazione in VS Code. Visualizza la dimensione dell’importazione in linea durante la digitazione.

import {formato} da 'date-fns'; // 14KB (zippato) Questo ciclo di feedback istantaneo fa riflettere gli sviluppatori due volte prima di aggiungere una dipendenza.

8. Il futuro: ripristinabilità (Qwik)

Il difetto fondamentale di React è l’Idratazione. Idratazione significa: “Scarica l’HTML. Quindi scarica il JS. Quindi esegui il JS per collegare i listener di eventi.” È un lavoro duplicato. Framework come Qwik introducono la riprendibilità. Non c’è idratazione. Il listener di eventi viene serializzato nell’HTML: <button on:click="./chunk.js#handleClick">. Il JS per il gestore dei clic viene scaricato solo quando l’utente fa effettivamente clic. Se non fanno mai clic, scarichi 0 KB di JS. Questo è l’ideale “O(1) JavaScript”. Lo stiamo osservando da vicino per il 2026.

9. Componenti del server React (RSC)

Il router dell’app Next.js utilizza RSC. RSC consente di mantenere le dipendenze sul server. Prima dell’RSC: import { format } from 'date-fns' -> Il pacchetto client aumenta di 20 KB. Dopo RSC: import { format } from 'date-fns' -> Funziona sul server. Rende HTML. Il pacchetto client aumenta di 0 KB. Strategia: spostare tutta la formattazione complessa, il recupero dei dati e l’elaborazione del markdown nei Componenti server. Mantieni i componenti client solo per l’interattività (useState, useEffect). I “nodi foglia” dovrebbero essere componenti client. I “Nodi Contenitore” dovrebbero essere Componenti Server.

9. La regola del budget di 100kb

Abbiamo una regola rigida: Non puoi unire un PR che spinga il bundle iniziale oltre i 100kb. Lo applichiamo tramite CI. Il controllo “bundlesize” fallisce:

“Errore: il pacchetto principale è 105 kb. Il limite è 100 kb.” Ciò forza una conversazione. “Abbiamo davvero bisogno di questa libreria? Possiamo caricarla pigramente?” Se non lo applichi, il pacchetto crescerà all’infinito. Ogni KB deve lottare per la propria vita.

10. Conclusione

Le prestazioni non sono “bello da avere”. Sono entrate. Amazon ha scoperto che 100 ms di latenza costano l’1% delle vendite. Latenza IS JavaScript gonfiata. Tratta il budget delle dimensioni del pacchetto come un budget finanziario. Se lo superi, devi “ripagarlo” cancellando il codice.

Il tuo sito è pesante?

Il tuo punteggio Lighthouse Performance mostra “Riduci JavaScript non utilizzato”?

Controlla il mio pacchetto. Leggi informazioni su Core Web Vitals e Edge Computing.

Le prestazioni non sono “bello da avere”. Sono entrate. Amazon ha scoperto che 100 ms di latenza costano l’1% delle vendite. Latenza IS JavaScript gonfiata. Tratta il budget delle dimensioni del pacchetto come un budget finanziario. Se lo superi, devi “ripagarlo” cancellando il codice.

Il tuo sito è pesante?

Il tuo punteggio Lighthouse Performance mostra “Riduci JavaScript non utilizzato”?

Controlla il mio pacchetto. Assumi i nostri architetti.