Come ho creato un sito Next.js multilingue in 3 giorni

Un'app mobile senza un sito web è come un ristorante senza insegna. Puoi avere la migliore cucina del mondo, ma nessuno ti troverà. Quando ho capito che TAMSIV aveva bisogno di un sito vetrina — landing page, prezzi, FAQ, pagine legali — mi sono posto un obiettivo ambizioso: 3 giorni, non uno di più.

72 ore dopo, tamsiv.com era online. Multilingue (6 lingue), responsive, con un hero animato, pagine ottimizzate per la SEO e un punteggio Lighthouse di 94/100/100. Ecco il resoconto completo di questo sprint, le scelte tecniche, le insidie e cosa farei diversamente.

Punti chiave da ricordare:
- Next.js 16 con App Router è ideale per un sito vetrina multilingue performante
- L'internazionalizzazione con next-intl deve essere configurata fin dall'inizio, non aggiunta dopo
- Lancia sempre npm run build localmente prima di distribuire su Vercel
- Il responsive richiede più iterazioni del previsto — prevedi il 30% del tempo totale
- Un punteggio Lighthouse 90+ è raggiungibile in 3 giorni con le giuste scelte architetturali

Perché Next.js piuttosto che Gatsby, Astro o un semplice HTML?

La scelta del framework non è insignificante. Ho considerato diverse opzioni:

• HTML/CSS statico: Il più semplice, ma ingestibile per 6 lingue e oltre 20 pagine. Ogni modifica deve essere replicata 6 volte.
• Gatsby: Buono per i siti statici, ma il tempo di build e l'ecosistema di plugin invecchiato mi hanno scoraggiato.
• Astro: Eccellente per i contenuti statici, ma sapevo che avrei avuto bisogno di componenti interattivi (autenticazione, dashboard) in seguito.
• Next.js 16: App Router, React Server Components, rendering ibrido (statico + dinamico), i18n nativo. E soprattutto, conosco React — è lo stesso ecosistema del frontend mobile TAMSIV.

La scelta di Next.js si è imposta anche per una ragione pratica: sapevo che il sito si sarebbe evoluto oltre un semplice sito vetrina. Il sistema di autenticazione QR code, la dashboard dell'app, il pannello di amministrazione — tutto ciò richiede un framework in grado di gestire pagine dinamiche protette.

Come organizzare uno sprint di 3 giorni in modo efficiente?

Tre giorni sono pochi. Senza pianificazione, passi il primo giorno a configurare il tuo ambiente e arrivi al terzo senza contenuti. Ecco come ho suddiviso lo sprint:

Giorno 1: Fondamenta tecniche (10 ore)

Il primo giorno è interamente dedicato all'infrastruttura tecnica. Niente di visibile per l'utente, ma tutto il resto dipende da questo:

• Setup Next.js 16 con TypeScript, App Router, Tailwind CSS 4
• Internazionalizzazione con next-intl — 6 lingue (FR, EN, DE, ES, IT, PT) configurate fin dall'inizio
• Routing localizzato: /fr/funzionalita, /en/features, /de/funktionen... ogni pagina ha un URL tradotto
• Layout di base: Header, footer, navigazione responsive, tema scuro (#101922)
• Configurazione Vercel: Repo Git connesso, preview deployments automatici

Il routing localizzato mi è costato 2 ore di configurazione da solo. Con next-intl, ogni rotta deve essere dichiarata con le sue traduzioni di slug. È verboso ma offre URL puliti e SEO-friendly in ogni lingua.

Giorno 2: Contenuto e design (12 ore)

Il giorno più intenso. È qui che il sito prende forma:

• Hero animato: Sfondo di particelle su sfondo scuro #101922, con una CTA principale. Ho usato una scena 3D Spline per l'elemento visivo principale.
• Pagine di contenuto: Casi d'uso (4 scenari), funzionalità (griglia responsive), prezzi (3 piani con confronto delle funzionalità), FAQ (accordion)
• Copywriting: Ogni pagina prima in francese, poi tradotta. Il tono: diretto, informale, incentrato sui benefici per l'utente
• Responsive: Dove ho passato più tempo. Le griglie delle funzionalità (3 colonne → 2 → 1) hanno richiesto 3 iterazioni. L'hero animato su mobile ha richiesto un fallback statico per le prestazioni.

Giorno 3: SEO, prestazioni e distribuzione (8 ore)

L'ultimo giorno è dedicato a tutto ciò che rende il sito "professionale":

• SEO tecnica: generateMetadata() per pagina con Open Graph, alternati lingue, sitemap XML dinamica
• Analytics: GA4 con Consent Mode RGPD (nessun tracciamento senza consenso)
• Pagine legali: Note legali, politica sulla privacy, CGU, cookie
• Performance: Ottimizzazione delle immagini, lazy loading, preloading dei font critici
• Distribuzione Vercel: E qui... la battaglia.

Perché la prima distribuzione Vercel è fallita?

Il momento della verità. git push, il build Vercel si avvia... e fallisce. Errore TypeScript. Poi un altro. Poi un terzo.

Cosa è successo: in sviluppo locale, Next.js è tollerante con alcuni errori di tipo. Il build di produzione (next build) è rigoroso. Tipi impliciti any, importazioni mancanti, props opzionali non gestite — tutto ciò passa in dev e si rompe in prod.

La lezione, imparata a caro prezzo: lancia sempre npm run build localmente prima di fare il push. Ci vogliono 30 secondi e si evitano 3 ore di debug sui log di Vercel (che sono meno leggibili dell'output locale).

Gli errori più comuni che ho corretto:

• Tipi impliciti: function Component({ data }) → function Component({ data }: { data: DataType })
• Importazioni non utilizzate: Il build le tratta come errori, non come avvisi
• Variabili d'ambiente: Prefisso NEXT_PUBLIC_ obbligatorio per le variabili accessibili lato client
• Alternates metadata: Gli URL di ogni lingua devono essere assoluti, non relativi

Come configurare l'internazionalizzazione con next-intl fin dall'inizio?

L'i18n è l'argomento che mi ha richiesto più tempo il primo giorno. Con next-intl, la configurazione iniziale richiede rigore:

1. File di messaggi: Un file JSON per lingua (messages/fr.json, messages/en.json...). Struttura identica, chiavi identiche, valori tradotti.
2. Middleware: Rilevamento automatico della lingua del browser, reindirizzamento al prefisso corretto (/fr/, /en/).
3. Routing: Ogni pagina è in una cartella [locale]. Gli slug sono tradotti tramite un file di mappatura.
4. Componenti: useTranslations('section') per accedere alle traduzioni in ogni componente.

La trappola classica: iniziare senza i18n e aggiungerla dopo. Ho visto progetti in cui questo è costato settimane di refactoring. Mettendolo fin dal primo giorno, ogni componente è già pronto per 6 lingue. La traduzione automatica tramite LLM se ne occupa in seguito.

Un punto importante: il contenuto HTML del blog è memorizzato in file separati (content/blog/{locale}/{slug}.html), non nei file JSON. Perché? Perché next-intl interpreta i tag HTML come variabili ICU e genera errori. Questa separazione mi ha evitato ore di debug.

Come ottenere un punteggio Lighthouse 90+ con Next.js?

Il punteggio Lighthouse finale: 94 Performance, 100 Accessibilità, 100 SEO. Ecco le ottimizzazioni chiave:

• Immagini ottimizzate: Componente <Image> di Next.js con sizes e priority per il LCP. Formato WebP automatico.
• Font critici: next/font per i Google Fonts con display: swap. Zero layout shift.
• Lazy loading: Tutti i componenti below-the-fold caricati su richiesta. L'hero animato è l'unico a essere caricato immediatamente.
• CSS atomico: Tailwind CSS 4 genera un CSS minimale — solo le classi utilizzate sono incluse.
• Static Generation: Tutte le pagine di contenuto sono pre-renderizzate al build. Zero server al runtime per il contenuto statico.

Il punto di performance più critico era l'hero animato. L'animazione di particelle su sfondo scuro era bella ma pesante. Ho dovuto implementare una soglia: su mobile, l'animazione è sostituita da un gradiente statico. Su desktop, si avvia solo dopo il LCP (Largest Contentful Paint).

Quali pagine sono indispensabili per un sito vetrina di app mobile?

Per un lancio, non hai bisogno di 50 pagine. Ecco il minimo indispensabile che ho creato in 3 giorni:

1. Landing page: Hero + casi d'uso + funzionalità + prezzi + FAQ + CTA. Rappresenta l'80% del traffico.
2. About: Chi c'è dietro il progetto. Per uno sviluppatore singolo, è un vantaggio di credibilità.
3. Privacy Policy: Obbligatoria per il Play Store e il RGPD.
4. Terms of Service: Obbligatoria per gli abbonamenti in-app.
5. Cookie Policy: Obbligatoria con il cookie consent RGPD.
6. Blog: Opzionale al lancio, ma ho messo in atto la struttura fin dal giorno 3. Il blog è diventato un importante canale di acquisizione SEO.

Ogni pagina esiste in 6 lingue grazie all'i18n. Questo significa oltre 30 pagine generate da 6 template. Il rapporto sforzo/impatto dell'i18n è enorme — ne parlo in dettaglio nel mio articolo sull'i18n come canale di acquisizione.

Come si è evoluto il sito dopo lo sprint iniziale?

I 3 giorni hanno gettato le basi. Da allora, il sito si è evoluto considerevolmente:

• Dashboard app (/app/tasks, /app/memos, /app/agenda): Interfaccia web completa per gestire attività e memo da un browser. Autenticazione tramite QR code o email.
• Pannello di amministrazione (/admin/dashboard): Metriche utente, grafici Recharts, avvisi. Dettagliato nell'articolo sulla dashboard di amministrazione.
• Blog SEO: Oltre 40 articoli tecnici ottimizzati per il posizionamento, con immagini generate da IA.
• Roadmap pubblica: Pagina della roadmap con funzionalità rilasciate e future.
• Guida utente: Documentazione interattiva per i nuovi utenti.

Tutto ciò non sarebbe stato possibile senza le solide fondamenta dei primi 3 giorni. L'App Router di Next.js, l'i18n nativa, la distribuzione automatica di Vercel — ogni mattone posato all'inizio ha facilitato le aggiunte successive.

Quali consigli per uno sviluppatore singolo che lancia il suo sito in sprint?

Se sei uno sviluppatore singolo e vuoi lanciare un sito vetrina rapidamente, ecco i miei 5 consigli:

1. Scegli un framework che conosci: Non è il momento di imparare. Usa ciò che padroneggi.
2. Configura l'i18n il primo giorno: Anche se traduci in una sola lingua, la struttura è già pronta. Aggiungere le traduzioni in seguito sarà banale.
3. Build locale prima di ogni push: npm run build. Sistematicamente. Senza eccezioni.
4. Mobile first per il CSS: Inizia dal mobile, aggiungi i breakpoint desktop. Il contrario costa sempre più tempo.
5. Ship early, iterate later: Un sito imperfetto online è meglio di un sito perfetto che esiste solo su localhost. Le correzioni arriveranno.

FAQ

Quanto costa l'hosting di un sito Next.js su Vercel?

Il piano gratuito di Vercel è sufficiente per la maggior parte dei siti vetrina. Include SSL, CDN globale e preview deployments. Utilizzo ancora il piano gratuito per tamsiv.com, anche con oltre 40 pagine e traffico regolare.

È necessario Tailwind CSS o un altro framework CSS?

Tailwind CSS è ideale per uno sprint veloce. Codifichi il design direttamente nel JSX, senza bisogno di file CSS separati. Lo svantaggio: il codice HTML è verboso. Ma per uno sviluppatore singolo che vuole andare veloce, il sovraccarico di leggibilità è ampiamente compensato dalla velocità di sviluppo.

Come gestire le traduzioni senza un traduttore professionale?

Utilizzo uno script di traduzione automatica tramite OpenRouter (LLM). Lo script rileva le chiavi modificate (delta-only), traduce solo ciò che è cambiato e costa circa 0,05 EUR per passaggio. La qualità è molto buona per testi tecnici. I dettagli sono nell'articolo sull'i18n in 6 lingue.

Il SEO è sufficiente con generateMetadata di Next.js?

generateMetadata() gestisce il titolo, la descrizione, gli Open Graph e gli alternates (hreflang). Questo è sufficiente per il 90% delle esigenze SEO on-page. Ho aggiunto una sitemap dinamica e un robots.txt per il crawling. Il resto (backlink, contenuto, autorità) dipende dal blog e dal marketing.

Si può fare lo stesso sprint con Astro invece di Next.js?

Sì, Astro sarebbe anche più veloce per un sito puramente statico. Ma se prevedi di aggiungere pagine dinamiche (autenticazione, dashboard) in seguito, Next.js rimane la scelta migliore. Il passaggio da statico a dinamico è trasparente con l'App Router.