Ottimizzazione delle performance Next.js: la guida completa

Q: Qual è un buon punteggio Lighthouse per un sito Next.js?

Tutto ciò che supera 90 è considerato buono, oltre 95 molto buono. I nostri progetti raggiungono regolarmente 95–100. Un punteggio sotto 70 indica problemi strutturali di performance, risolvibili con un'ottimizzazione mirata.

Q: Perché il mio sito Next.js è lento nonostante usi Next.js?

Next.js non è garanzia di performance: implementazioni errate possono annullare i vantaggi. Cause frequenti: flag priority mancanti sulle immagini, troppi client component al posto dei server component, script esterni che bloccano il rendering, query al database scadenti in SSR.

Q: Quanto dura un audit delle performance?

Un audit di performance di base con raccomandazioni di miglioramento dura 2–4 ore. Un audit completo con implementazione dei miglioramenti richiede 1–5 giorni a seconda delle dimensioni del progetto.

Q: Le performance migliorano davvero il tasso di conversione?

Sì, è dimostrato da numerosi studi. Google e Amazon hanno mostrato che 100 ms in più di tempo di caricamento significano l'1 % di conversioni in meno. Una pagina che carica 1 secondo più velocemente converte tipicamente il 2–5 % in più.

Q: Quanto costa un'ottimizzazione delle performance Next.js?

Un audit delle performance costa 490–990 €. L'implementazione dei miglioramenti individuati dipende dal perimetro: 1.000–5.000 € per progetti tipici. Spesso, tuttavia, il 20 % degli interventi è responsabile dell'80 % del miglioramento di performance.

Wito AI

Guida performance11 min di lettura

Guida performance

Performance Next.js Raggiungi Lighthouse 95+

Tecniche concrete per la massima performance Next.js: LCP sotto 1 secondo, CLS vicino allo zero, INP sotto 50 ms. Con questi metodi i nostri progetti raggiungono stabilmente punteggi Lighthouse superiori a 95.

Capire i Core Web Vitals

I Core Web Vitals di Google sono le metriche di performance decisive per SEO ed esperienza utente: LCP (Largest Contentful Paint): quanto tempo serve perché il più grande elemento visibile della pagina venga caricato? Obiettivo: sotto i 2,5 secondi, idealmente sotto 1 secondo. INP (Interaction to Next Paint): con quale rapidità la pagina risponde agli input dell'utente? Obiettivo: sotto i 200 ms, idealmente sotto i 50 ms. CLS (Cumulative Layout Shift): quanto si spostano gli elementi durante il caricamento? Obiettivo: sotto 0,1, idealmente 0,02 o meno. Next.js offre nativamente condizioni migliori per tutte e tre le metriche rispetto a WordPress o alle SPA classiche, ma implementazioni errate possono annullare questi vantaggi.

Google utilizza i Core Web Vitals come fattore di ranking. Le pagine con buoni vitals si posizionano in media il 15–25 % meglio rispetto a pagine paragonabili con vitals scadenti.

Ottimizzazione delle immagini con next/image

Le immagini sono il killer più comune dell'LCP. Il `` di Next.js risolve automaticamente la maggior parte dei problemi: Conversione automatica WebP/AVIF: Next.js fornisce le immagini nel miglior formato supportato dal browser. AVIF è il 40–60 % più leggero di JPEG a parità di qualità. Lazy loading: le immagini sotto la viewport vengono caricate solo quando l'utente scorre. Imposta correttamente `loading="lazy"`. Flag priority per le immagini LCP: l'immagine principale (spesso l'immagine hero) dovrebbe avere `priority` per essere caricata subito. L'assenza di questo flag è una causa frequente di LCP scadente. Dimensioni fisse: imposta sempre `width` e `height` per evitare CLS dovuto a immagini che caricano in ritardo. Placeholder sfocato: `placeholder="blur"` mostra un placeholder sfocato durante il caricamento ed evita salti visivi.

Errore frequente: l'immagine hero senza flag priority. Aggiungi priority a tutte le immagini above-the-fold: spesso migliora l'LCP di 0,5–1,5 secondi.

Scegliere la giusta strategia di rendering

Next.js offre diverse modalità di rendering: la scelta sbagliata costa in performance: Static Generation (SSG): le pagine vengono renderizzate al build time e consegnate come file HTML statici. Il tempo di caricamento più rapido possibile. Adatto a pagine che cambiano raramente (landing page, articoli di blog). Incremental Static Regeneration (ISR): le pagine statiche vengono aggiornate in background. Ideale per pagine che cambiano occasionalmente (pagine prodotto, news). Il parametro `revalidate` controlla la frequenza di aggiornamento. Server-Side Rendering (SSR): le pagine vengono renderizzate a ogni richiesta. Necessario per contenuti personalizzati, ma più lento. Attenzione: usare SSR per tutto è un errore di performance comune. React Server Components (RSC): con l'App Router i componenti possono essere renderizzati lato server, senza inviare JavaScript al client. Riduce la dimensione del bundle e migliora l'INP.

Problemi di performance nel tuo progetto Next.js?

Ottimizzare font e script esterni

next/font per Google Fonts Non integrare mai Google Fonts direttamente via CDN. `next/font/google` carica i font in locale ed elimina la richiesta di rete ai server di Google: risparmia 200–500 ms e migliora la privacy. next/script per script esterni Analytics, widget di chat, strumenti di A/B testing: integrali sempre con `