Blog in WordPress: cambiamo?

Sia ben chiaro, è ormai da quasi tre anni che utilizzo WordPress per gestire il mio blog e non posso dire che non faccia il suo dovere.
Ultimamente, però, mi sto sempre più distaccando dal mondo PHP: sto esplorando linuguaggi di programmazione come Ruby e Scala con i relativi framework Rails e Lift… ogni volta che apro WordPress e trovo quei 2-300 commenti di spam (bloccati) e quei 4-5 plugin da aggiornare che poi provocano sempre qualche rogna, mi sento come il famoso calzolaio che ha le scarpe rotte.
Ieri sera su Facebook un mio amico e collega, ha reso pubblico il suo pensiero negativo sulla piattaforma WordPress, motivandolo con questioni di qualità del codice: francamente non mi sono mai messo a guardare il codice PHP di WordPress, però visto che conosco la persona e la qualità del codice che scrive, non posso che credergli ciecamente.
A questo punto ho fatto qualche ricerca su piattaforme di blogging alternative: ho analizzato le mie esigenze (anzi quelle del mio blog) e, soprattutto, quello che WordPress mette a disposizione che a me non interessa assolutamente.
Ad esempio, WordPress è multiutente mentre sul mio blog scrivo solo io, uso un plugin (WPTouch) per rendere il blog fruibile da cellulari, mentre con un CSS responsive si avrebbe un risultato migliore, non uso mai l’editor WYSIWYG ma scrivo i miei articoli in HTML… insomma mi sono convinto che esistano delle alternative più snelle rispetto al pachiderma WordPress che si adatterebbero meglio alle mie esigenze.
Sono andato alla ricerca di alternative: la maggior parte sono offerte come servizio (vedi blogger), altre sono dei CMS veri e propri (Drupal, Joomla, ecc.)… quello che cercavo io inizialmente è un sistema di weblog scritto in un linguaggio diverso da PHP (non perchè mi faccia schifo, ma perchè così avrei la possibilità di aumentare le esperienze con altri linguaggi) e che non fosse Python per il quale ammetto l’idiosincrasia.
L’ideale per me sarebbe stato un sistema scritto in Ruby on Rails, framework con il quale sto lavorando in questo periodo, e che si potesse adattare ad una base dati non relazionale come MongoDB per una questione di velocità in ambienti cloud.
Purtroppo non ho trovato nulla di già pronto, però ho trovato parecchi tutorial su come usare Rails per creare un blog e, in effetti, mi sono reso conto che la base dati alla base di un Blog è davvero molto semplice e non richiede obbligatoriamente le funzionalità relazionali avanziate dei DB Relazionali (ad es. union e join).
Nella ricerca, però, mi sono imbattuto in un paio di progetti relaizzati in ruby davvero alternativi: octopress e nanoc. La differenza tra questi sistemi e “il resto del mondo” è che si tratta di generatori di blog statici. In pratica, si scrive il codice del post, lo si da in pasto al preprocessore che genera dei contenuti statici html e lo si carica sul server. E’ un po’ più macchinoso da utilizzare, però non si ha alcuna base dati alle spalle del blog, a beneficio della velocità per il visitatore.
A questo punto mi sono levato lo sfizio di aprire uno spazio web sui miei server e caricare un miniblog di un post realizzato con Octopress; quindi ho fatto alcune prove comparative tra la home page del mio blog in WordPress, la home page del blog in Octopress e la home page di un work in progress realizzato in Rails con base dati MongoDB.
Ecco i risultati che condivido con tutti voi.

Google Page Speed:
Wordpress: 83/100
Errori gravi: abilitare la compressione (c’ho provato in tutti i modi con NGINX e W3 Total Cache, ma ogni tanto il browser non riesce a visualizzare la pagina per cui ho disabilitato il plugin) e utilizzo di URL non coerenti (alcuni CSS vengono presi da altri siti)
Errori medi: sfruttare al cache del browser (causa mancanza di W3 TC), combinare le immagini in sprite css, rimanda l’analisi del codice JS e riduci al minimo i reindirizzamenti

Octopress: 91/100
Nessun errore grave o medio

Rail con CSS Twitter Bootstrap: 97/100
Nessun errore grave o medio

Test con Pingdom da Amsterdam
Wordpress: 3,46 Sec – 77% perf. grade
Octopress: 322 ms – 75% perf. grade
Rails con CSS Twitter Bootstrap: 388 ms – 87% perf. grade

In tutti i casi, come frontend, abbiamo nginx (con apache il tempo di download del sito in wordpress mi raddoppia); nel caso di WordPress il php è gestito con PHP-FPM, nel caso del sito in Rails abbiamo Unicorn (nel sito realizzato con Octopress non c’è nulla in quanto sono pagine statiche).
Il confronto tra i siti Rails e Octopress vs WordPress è impietoso ma veritiero in quanto in entrambi i casi si tratta di siti ospitati sugli stessi server, con la stessa banda e completi di CSS, javascript ecc. Solo il peso non è analogo, a causa di alcuni contenuti statici presenti sul sito wordpress: abbiamo un peso di circa 800 KB per WordPress e di circa 350 per gli altri due, ma c’è da dire che un peso doppio non può equivalere ad un tempo di download 10 volte maggiore. Immagino che un “WordPress Guru” sia in grado di migliorare le performance facendo funzionare la compressione e lavorando sul layout, però difficilmente riuscirà ad abbassare il tempo di download ai livelli di Rails anche se il peso della pagina fosse identico.
Il confronto tra il sito statico generato da Octopress e il sito dinamico in Rails è meno semplice da valutare: i tempi di risposta sono equivalenti e il peso è simile, però sul sito in Octopress troviamo il link ad alcuni CSS esterni che non incidono sul valore di Google Pagespeed ma, al contrario, incidono sul Performance Grade di Pingdom.

Sinceramente, fare un “passo indietro” ed avere una struttura totalmente statica, ha dei vantaggi non trascurabili in termini di portabilità, velocità di download, scalabilità (per quanto possa servire al mio blog) e semplicità di gestione lato server, però bisogna vedere se all’atto pratico scrivere i post in linguaggio Jekyll, lanciare il parser e l’upload sul server sia funzionale come l’utilizzo dell’editor (non WYSIWYG) di WordPress.
D’altro canto, un weblog scritto da zero con Rails o Lift sarebbe certamente più d’immagine e probabilmente sarebbe “meno base”: difatti, ad esempio, avrei la possibilità di continuare a gestire direttamente i commenti senza affidarmi a servizi esterni come disquss, oppure potrei scrivere il codice per l’autopost sui social network, anche se bene o male quasi tutti hanno la possibilità di essere “agganciati” all’rss feed.

In sostanza, alla fine della prova, di sicuro ha ragione Luigi che ha reso palese una mia idea mai collaudata sul campo. Sicuramente nei prossimi mesi il sito WordPress sarà migrato su qualcosa d’altro, anche se non so ancora se varrà la pena realizzare una struttura dinamica da zero in Rails/MongoDB oppure se mi affiderò ai preprocessore di Octopost o nanoc.