Per un designer professionista, un sito portfolio si trova in una scomoda via di mezzo. Deve apparire impeccabile, caricarsi istantaneamente e rimanere aggiornato senza sottrarre tempo alle ore fatturabili. La mia vecchia configurazione era su Webflow, che colmava il divario tra i builder drag-and-drop e il risultato professionale meglio di quasi tutti gli altri strumenti. Ma quando è arrivata la notifica di rinnovo con una fattura annuale di £300, ho dovuto farmi una domanda difficile: stavo pagando per il valore o solo per la comodità?

Ho deciso di ricostruire tutto da zero. Il nuovo stack è Astro e Sanity. Dopo averlo utilizzato per un po', ecco esattamente cosa ha funzionato, cosa no e come si posiziona rispetto agli strumenti che usavo in precedenza.

Perché Astro per un portfolio?

La maggior parte dei moderni framework web invia JavaScript prioritariamente e affronta il resto in seguito. Astro ribalta questo presupposto. Genera semplice HTML statico al momento della build e invia JavaScript al browser solo quando un componente specifico ne ha effettivamente bisogno. Lo chiamano islands architecture, ma il risultato pratico è più semplice: le pagine del mio portfolio pesano quasi zero.

Il routing si basa sui file, quindi creare una nuova pagina è facile come trascinare un file in una cartella. I componenti utilizzano una sintassi che risulterà familiare se hai mai usato React, Vue o Svelte. Non devo ricorrere a un nuovo paradigma ogni volta che voglio aggiungere un caso studio di un progetto.

Detto questo, non userei Astro per costruire un'applicazione web complessa. Se devi implementare l'autenticazione, gestire lo stato globale o gestire dati in tempo reale, finirai per lottare contro il framework. Per siti di marketing, blog e portfolio, invece, non crea ostacoli. Le pagine sembrano veloci perché sono veloci. Non c'è l'overhead dell'idratazione in attesa di renderizzare un titolo o un paragrafo.

Passare da WordPress a Sanity

Prima di questa ricostruzione, la mia soluzione di riserva era sempre WordPress con Advanced Custom Fields. ACF conferisce a WordPress dei superpoteri, ma stai comunque configurando la casa di qualcun altro. Sanity funziona al contrario. Scrivi uno schema in codice che definisce esattamente come appare il tuo modello di contenuti, e Sanity costruisce l'interfaccia di editing attorno alle tue decisioni.

Ho usato quel controllo per costruire un semplice page builder basato su blocchi riutilizzabili. Ho definito una hero section una volta. Ho definito un carosello di testimonianze una volta. Ho definito una griglia di card una volta. Ora posso assemblare nuove pagine impilando quei blocchi in qualsiasi ordine, senza scrivere nuovo codice o toccare un template di pagina.

La differenza di mentalità è importante. Con WordPress, spesso mi sentivo come se stessi lottando con uno strumento che voleva essere un blog. Con Sanity, mi sento come se stessi costruendo software. Il contenuto diventa dati strutturati puliti invece di HTML stilizzato mescolato con shortcode. Le descrizioni dei miei progetti vivono come oggetti portatili che potrei inviare a un'app mobile o a una newsletter, se lo volessi.

Un workflow di deployment pulito

Il mio vecchio workflow su WordPress era un caos di caricamenti FTP, sottodomini di staging e aggiornamenti di plugin che sembravano rompersi sempre nel momento peggiore. Avevo una checklist mentale solo per pubblicare la correzione di un refuso.

Il nuovo workflow è breve:

  • Faccio le modifiche localmente e le vedo istantaneamente.
  • Faccio il commit su GitHub quando il codice è pronto.
  • Vercel rileva il push e distribuisce il sito automaticamente.

Non c'è un client FTP. Non c'è un database di staging da sincronizzare. Il repository è la fonte della verità.

Anche il contenuto funziona allo stesso modo. Quando pubblico o aggiorno un post all'interno di Sanity, un webhook dice a Vercel di ricostruire il sito. Le pagine statiche si rigenerano con contenuti freschi e la CDN si aggiorna senza che io debba toccare un server. Tutto rimane sincronizzato senza dover copiare, esportare manualmente o pregare che una migrazione del database di un plugin sia andata a buon fine.

Unire design e codice con i token

Uno dei successi più discreti di questa ricostruzione è stata l'implementazione di un sistema di token adeguato. Mantengo un singolo file JSON che gestisce ogni colore, scala tipografica e valore di spaziatura del sito. Quel file è il capo.

Uso Token Studio per importare quegli stessi valori direttamente in Figma. Quando il mio file di design riporta surface-default, punta esattamente allo stesso numero usato nel codice. Un piccolo script converte il JSON in proprietà CSS personalizzate al momento della build, quindi i miei fogli di stile fanno riferimento a variabili come --color-surface-default invece di codici esadecimali scritti a mano.

Ecco perché questo è importante in pratica. Se mi rendo conto che il rosso del mio brand è leggermente troppo aggressivo sugli schermi mobile, cambio un singolo valore nel file JSON. La libreria Figma si aggiorna. Il CSS si aggiorna. Ogni istanza in tutto il sito si aggiorna. Non ho bisogno di fare un grep