Come ho ristrutturato questo sito utilizzando Astro, Tailwind e Cloudflare

Se hai letto il mio articolo su perché avevo scelto Grav CMS, sai già come è andata a finire: a un certo punto sono passato ad Astro. In realtà anche prima di scrivere questo articolo ero già passato ad Astro, ma il layout era essenziale — diciamocelo: funzionava, ma era bruttino. Così ho deciso di ricominciare quasi da capo e ricostruire tutto, facendomi dare una mano da Claude, questa volta con un’idea di design più precisa e con qualche strumento in più a supporto.

Questo articolo è una carrellata degli strumenti e delle tecnologie che ho usato, con il perché di ogni scelta. Niente tutorial passo-passo: più una panoramica per chi è curioso di sapere cosa c’è sotto il cofano.

Astro: HTML statico, (quasi) zero JavaScript

Il cuore di tutto è Astro, un framework per generare siti statici. Il concetto che mi ha convinto è semplice: di default Astro produce HTML puro, senza spedire al browser JavaScript che non serve. Il codice interattivo lo aggiungi solo dove serve davvero; resta HTML leggero e velocissimo da caricare.

Per un sito come questo — fatto in gran parte di contenuti da leggere — è la scelta ideale: pagine che pesano poco, tempi di risposta ottimi e ottimo comportamento lato SEO, senza dover ottimizzare a mano.

Aggiungo un dettaglio che apprezzo: Astro non mi obbliga a un unico modo di scrivere i componenti e mi lascia usare la sintassi che preferisco, restando comunque framework-agnostic. In pratica: poca cerimonia, tanto controllo.

Tailwind per lo stile

Per la parte grafica uso Tailwind CSS. Invece di scrivere fogli di stile separati e inventare nomi di classi, lo stile lo compongo direttamente nel markup con classi già pronte (flex, text-lg, mt-4, e così via).

Perché mi trovo bene? Perché lo stile vive accanto all’elemento che sto costruendo: non devo saltare avanti e indietro tra file diversi, e non mi ritrovo con CSS “morto” che nessuno osa più toccare. In fase di build Tailwind tiene solo le classi effettivamente usate, quindi il CSS finale è minuscolo. La modalità scura/chiara è gestita nello stesso modo, con una manciata di classi dedicate.

Cloudflare Pages per l’hosting

Il sito è ospitato su Cloudflare Pages. Il funzionamento è quello che mi aspetto da una piattaforma moderna: faccio git push, Cloudflare compila il progetto e pubblica il risultato in automatico, distribuito sulla loro rete globale. Zero server da gestire, HTTPS incluso, deploy zero-downtime in pochi secondi.

C’è però un aspetto che vale la pena raccontare: essendo un sito statico, in teoria non c’è “codice lato server”. Ma qualche funzionalità dinamica la volevo lo stesso, e qui entrano in gioco le Pages Functions — piccole funzioni serverless che girano sul bordo della rete Cloudflare. Le uso per due cose:

• il widget “Now Playing” nella pagina About, che chiede a Spotify cosa sto ascoltando in quel momento (o l’ultimo brano riprodotto);
• un gate per lo staging: quando serve, posso proteggere la versione di staging con autenticazione, in modo da visualizzare un’anteprima prima di andare in produzione, il tutto senza toccare la versione pubblica.

In pratica il meglio dei due mondi: statico e velocissimo di default, con un pizzico di dinamismo dove serve.

I contenuti: Markdown + frontmatter

Per fortuna ho potuto “riciclare” tutti gli articoli pubblicati fino a quel momento (anche quelli che avevo scritto con la prima versione basata su GravCMS). L’idea di non utilizzare database, CMS, template engine, framework o piattaforme esterne alla fine si è rivelata vincente.

Ogni articolo è un semplice file Markdown. In cima al file, un blocco di frontmatter descrive i metadati: titolo, data, lingua, tag, descrizione e poco altro. Comodo, standard, facilmente trasportabile: se un domani cambiassi tecnologia, i contenuti se ne verrebbero via con me senza migrazioni dolorose.

Astro mi dà una mano in più con le Content Collections: uno schema (validato con Zod) controlla che ogni articolo abbia i campi giusti, nel formato giusto. Se dimentico un campo obbligatorio o sforo il limite di caratteri della descrizione, me ne accorgo in fase di build, non dopo la pubblicazione. È una piccola rete di sicurezza che dà tranquillità.

Bilingue IT/EN

Volevo pubblicare sia in italiano sia in inglese, e senza duplicare pagine e componenti a ogni articolo. La soluzione: l’italiano vive alla radice (/, /blog/), l’inglese sotto /en/, ma entrambe le lingue attingono agli stessi contenuti, filtrati per lingua.

Le due versioni di un articolo sono file separati che condividono una chiave di traduzione: è questo il collante che permette di mostrare il link “disponibile anche in…” e di saltare da una lingua all’altra. Un articolo può anche esistere in una sola lingua: nessun obbligo di tradurre tutto.

Cosa è migliorato rispetto a prima

La versione precedente era funzionale, ma spartana. Ricostruendola ho aggiunto parecchie cose che prima mancavano — ed è qui che sta buona parte del lavoro (e del divertimento):

• Aspetto e tipografia. Un design coerente (il tema Atlas) e una tipografia curata: Hanken Grotesk per il testo, JetBrains Mono per il codice. Prima era tutto molto essenziale (per non dire bruttino).
• Tema chiaro/scuro. Selettore chiaro/scuro, con il tema giusto applicato prima che la pagina si disegni: niente classico lampo bianco quando apri il sito in modalità scura.
• Tag negli articoli. Ogni articolo ha i suoi tag, con pagine dedicate per sfogliare i contenuti per argomento.
• Tempo di lettura. Ogni articolo mostra una stima dei minuti di lettura.
• Indice dell’articolo. Una piccola table of contents laterale con i titoli delle sezioni, per orientarsi e saltare direttamente al punto che interessa.
• Ultimi articoli in homepage. La home mostra i post più recenti del blog, così c’è sempre un punto d’ingresso ai contenuti.
• Feed RSS. Link ai feed (uno per l’italiano, uno per l’inglese) per chi preferisce seguire il blog da un lettore RSS.
• Snippet di codice gradevoli. Blocchi di codice colorati in fase di build (niente JavaScript a caricare), con due temi coordinati chiaro/scuro, numeri di riga dove servono e un pulsante “copia” su ogni blocco.
• Pulsante “Vedi in Markdown”. Ogni articolo si può aprire anche nella sua forma grezza in Markdown, per chi la preferisce.
• Form di contatto in homepage. Un modulo per scrivermi direttamente dalla home, con invio tramite un servizio esterno (Web3Forms) e un piccolo honeypot anti-spam. Nessun backend da mantenere solo per ricevere quattro email.
• Pagina “uses”. Una pagina dedicata a hardware, software e strumenti che uso ogni giorno.
• Immagini social automatiche e niente “salti”. Ogni articolo ha la sua anteprima da 1200×630 pixel generata automaticamente al build, e le immagini non causano layout shift mentre si caricano.

Conclusioni

Come dicevo nell’articolo su Grav, non credo esista uno strumento in assoluto migliore di tutti gli altri: dipende dalle esigenze (e da ciò che si conosce). Per un sito personale fatto soprattutto di contenuti, questo stack — Astro per l’HTML statico, Tailwind per lo stile, Cloudflare Pages per l’hosting — mi ha dato esattamente quello che cercavo: pagine leggere e veloci, contenuti in Markdown che restano miei, un pizzico di dinamismo dove serve e, finalmente, un layout di cui sono contento.

Se stai pensando di rifare il tuo sito o di aprirne uno, ti consiglio di dare un’occhiata ad Astro: la curva di apprendimento è dolce e, una volta preso il ritmo, è davvero piacevole da usare.