Jeeeeeekyll? No, Hugo!

Mentre descrivevo come ero passato da Wordpress a Jekyll, sapevo già che avrei dovuto cambiare di nuovo.

Da un punto di vista tecnico, Jekyll è una piattaforma fantastica: è facile da programmare, ha una documentazione ineccepibile e funziona perfettamente durante la fase di sviluppo, quando il numero di pagine e di post di test è limitato. Ma, come ho sperimentato in prima persona, una volta che Jekyll si trova a dover gestire un sito vero con centinaia di post, le prestazioni calano drasticamente e i tempi di risposta aumentano in modo intollerabile (e piuttosto imbarazzante).

A fine anni ‘90 era normale aspettare diversi secondi prima di visualizzare una pagina web.¹ Ma oggi siamo abituati a pagine che si caricano immediatamente, e una attesa di tre, quattro secondi è inaccettabile.

Un prezzo troppo alto da pagare

Prima di iniziare a lavorare sul nuovo sito sapevo bene che Jekyll era lento, ma questa lentezza si riferiva sempre alla fase di generazione del sito, una operazione che si esegue di rado e può essere facilmente automatizzata. E in effetti è proprio così: durante lo sviluppo, con poche decine di post, rigeneravo il sito in 10-20 secondi, una cosa seccante ma non drammatica; ora ci vogliono 15 minuti per rigenerare l’intero melabit.com.

Quello che non sapevo era che anche il sito generato avrebbe sofferto dello stessa problema, come è diventato evidente non appena ho terminato la fase di sviluppo e ho iniziato a lavorare con tutti i post.

In quel momento ero ancora convinto che l’ottimizzazione del codice e delle immagini e un caching aggressivo avrebbe potuto attenuare il problema. E comunque ero andato troppo avanti per fermarmi. Ma dopo poco mi sono accorto che questa strategia non era sufficiente, e che ci voleva un ripensamento radicale. E ho cominciato a guardarmi attorno.

Alternative

I generatori di siti statici sono come le distribuzioni di Linux: abbondano e quasi sempre non si capisce il senso della loro esistenza. In questo momento, Jamstack ne elenca 366, mentre Static Site Generators arriva a quasi 500. La maggior parte è stata abbandonata, magari perché nessuno le utilizzava o perché lo sviluppatore non era interessato a continuarne lo sviluppo. Diciamo che quelle interessanti sono una decina o poco più.

Fra queste ho considerato (brevemente, lo ammetto) Bridgetown, che deriva da Jekyll e quindi, a prima vista, sembrava una evoluzione naturale. Ma poi mi sono accorto che lo usano in pochi, che i plugin sono scarsi e i temi ancora meno. E poi, se Bridgetown discende da Jekyll, non è che soffre dello stesso problema di lentezza? Meglio stare alla larga e tenersi l’originale.

Altro candidato era Middleman, sviluppato in Ruby come Jekyll, Ma Middleman è destinato a generare il classico sito web, e ci vuole una estensione specifica per fargli supportare le funzioni tipiche di un blog (liste di articoli, tassonomie, feed, commenti). E poi il linguaggio di templating è ERB (Embedded Ruby), che in sé è una scelta sensata dato che è integrato nello stesso Ruby, ma che per me significava dover reimparare tutto da zero.

Ve la faccio breve: alla fine dei conti l’unico candidato serio era… il solito Hugo.

Alla ricerca della velocità

Di Hugo avevo già scritto molti anni fa, trovandolo interessante, ma azzoppato da una documentazione che definire scarsa era un complimento.²

Però la qualità non è in discussione, non a caso Hugo, proprio come Jekyll, finisce sistematicamente in cima a tutte le classifiche che si prefiggono di valutare la qualità dei vari generatori di siti statici.

E poi Hugo ha un vero asso nella manica: è veloce, anzi è velocissimo.

Non so dire se Hugo sia davvero il più veloce framework al mondo per la costruzione di siti web, come sostiene lo slogan in cima alla sua home page. Ma ho verificato in prima persona che Hugo è in grado di generare questo sito in meno di un minuto, cioè 15 volte più rapidamente di Jekyll. E, quello che più conta, anche il sito generato risulta essere veloce e reattivo, proprio come ci si aspetta da un sito web moderno. Questo fa passare tutto il resto in secondo piano.

Hugo

E allora da oggi melabit.com passa ad Hugo, con una nuova grafica³ e cercando di mantenere tutte le funzioni della versione basata su Jekyll. Prima fra tutte il sistema di commenti basato su Comma, che dopo il trapianto ha funzionato praticamente al primo colpo.

I permalink sono cambiati e ora distinguono esplicitamente la lingua del post, che è una cosa più razionale. Anche il feed è cambiato, per ora è il vecchio RSS, prima o poi verificherò se è possibile aggiungere ATOM.

La funzione di ricerca per ora è basata su Google, e non funzionerà finché il sito non sarà indicizzato di nuovo. La paginazione va rivista, così come la logica che mostra il post in evidenza anche nella lista di tutti i post. Ma ci sarà tempo per sistemare questi dettagli.

Per formazione mentale mi piacerebbe entrare nei dettagli di come ho modificato Hugo e il tema grafico prescelto, ma temo di risultare noioso, soprattutto dopo tutti gli articoli, dettagliatissimi ma ormai praticamente inutili, scritti su Jekyll. Ci penserò un po’ su, nel frattempo se qualcuno è interessato a saperne di più può scriverlo nei commenti.

– Immagine generata da Google Gemini.