I siti pigri sono i più veloci

Ho messo da parte in questi anni un bel po’ di materiale e documentazione relativi alla performance e ottimizzazione dei siti web, sia per quanto riguarda il cosiddetto lato server, sia per quello che viene chiamato front end.

Verrà – spero presto – il momento di compilare un elenco ragionato di tutte queste risorse (potete farvene un’idea visitando la sezione optimization del mio delicious), ma ora mi limito a citare un articolo che propone in modo molto chiaro uno dei nodi fondamentali da affrontare. Si tratta di Lazy web sites run faster scritto da Gojko Adzic.

Per aumentare le performance dei siti potete investire sull’hardware, quindi più processori e sistemi più veloci, migliore connettività, infrastruttura moderna. Vi accorgerete però che anche così facendo il web server fatica, per architettura, a gestire un sito il cui codice non sia ottimizzato.

Potete allora dedicarvi alla riscrittura (o refactoring) del codice per renderlo più veloce. Anche qui però arriverete ben presto a un limite.

Il segreto, secondo Gojko, sta invece nella progettazione di un sistema che si preoccupi di

  • delegare le operazioni più complesse a processi che girano in background;
  • non comunicare con sistemi esterni in modo sincrono, non importa quanto velocemente;
  • essere pigro: meglio lasciare per dopo tutto quello che non ha necessità di essere eseguito al momento.

Aggiungerei anche di eliminare le elaborazioni inutili, come per esempio l’esecuzione a ogni richiesta di interrogazioni esose (come quelle verso i database) per contenuti che non cambiano quasi mai. In questo caso potrebbe essere interessante sperimentare qualche meccanismo di caching.

Se ripenso ai colli di bottiglia dei progetti che ho visto da vicino, la maggior parte poteva essere evitata rimandando operazioni non immediatamente essenziali, come per esempio:

  • l’invio di un messaggio di posta elettronica di conferma;
  • la trasformazione di file (soprattutto in formato XML);
  • la comunicazione con sistemi di gestione;
  • il calcolo di statistiche.

Capita di trovare anche online degli esempi che fanno riflettere. Ogni volta che utilizzo la funzione “all time” di Feedburner per analizzare il traffico complessivo dei miei feed mi trovo ad aspettare almeno una decina di secondi. Probabilmente il sistema sta elaborando il consuntivo in tempo reale, quando avrebbe potuto farlo a priori. Non c’è nulla di male ad aspettare anche se a volte, per carico del server, viene restituito un timeout. Forse non proprio il modo ideale per gestire questa funzionalità, anche se utilizzata da una minoranza.

Dick Costolo – Launch late to iterate often

Quella di Costolo, che ha alle spalle l’acquisizione da parte di Google di Feedburner, è una delle sessioni più ricche dell’ultima giornata. Si chiude in bellezza.

Ecco qualche appunto tratto dalla sua vulcanica (e concentrata!) presentazione.

Nel fondare una azienda, meglio che tutti i soci abbiano la stessa percentuale, soprattutto se verrà acquisita, perché evita degli attriti. Inoltre, meglio avere il 10% di un’azienda che vale 100 che il 100% di un’azienda che vale 5

Non si fanno più i business plan: per Feedbruner non sono stati fatti. Sono cose che servono per dire cosa ci sarebbe piaciuto fare, piuttosto che quello che si fa. Anche gli investor non li leggono più.

Opportunità di mercato. E’ impossibile capire le dimensioni del mercato a cui ci si rivolge. E’ anche impossibile verificare se c’è richiesta di mercato oppure no, perché (prende come esempio sempre Feedburner) oggi le cose con più successo sono quelle per cui non c’è richiesta di mercato.

Secondo Costello non ci sono benefici particolari nell’essere localizzati in Silicon Valley, se non per una questione di “buzz”, cioè perché una società con sede lì attira l’attenzione (una questione di marketing di breve periodo, quindi).

Non raccontiamocela: per far partire un’azienda i soldi servono, eccome. Fate le vostre previsione: spenderete più del doppio delle vostre stime. Quindi, raccogliete tutto quello che potete.

Fare crescere l’azienda insieme significa condividere i successi. Tutti i dipendenti devono avere lo stesso trattamento contrattuale, soprattutto se condividete le quote societarie.

Assunzioni. Cercate persone con ottime competenze per area di esperienza, ma non con competenze troppo specifiche. Altrimenti, se il mercato cambia, se ne andranno o non le potete riposizionare. In molte organizzazioni le gerarchie sono controproducenti, perché introducono burocrazia. Di contro devono essere sviluppate delle metriche di performance condivise con chi le deve fare. In questo modo è semplice e oggettivo riuscire a valutare i risultati personali.

Lanciare il prodotto tardi e iterare di continuo. Non rilasciare mai prodotti con problemi perché bisogna andare verso il mercato. Anzi, vanno previste a priori eventuali funzionalità che potrebbero rivelarsi vincenti. Ad esempio dotandosi di una architettura che sia estensibile in futuro.

Le architetture aperte, inoltre, possono essere influenzate facilmente dalla richiesta di mercato. E attaccano anche la concorrenza, che si trova a rivaleggiare non con un prodotto in scatola, ma con un’architettura estensibile.

Questo intervento è stato scritto in live blogging dalla conferenza Future of Web Apps di Londra, il 3 e 4 Ottobre 2007. Leggi tutti gli interventi di Fucinaweb dal FOWA

Feedburner e Google: c’è modo e modo

Davvero brutta la precisazione che compare al login di FeedBurner da qualche giorno, dopo l’acquisizione di Google.

Eccola tradotta in italiano con qualche libertà:

Gli account di FeedBurner non saranno cancellati come risultato dell’acquisizione di Google. Avete 14 giorni di tempo, fino al 15 Giugno 2007, per decidere di non consentire il trasferimento del vostro account verso Google. Se non lo fate esplicitamente, i diritti di gestione dei vostri dati passeranno da FeedBurner a Google. Il mancato trasferimento terminerà invece il vostro accordo con FeedBurner, porterà alla cancellazione del vostro account FeedBurner, dei feed, di tutte le statistiche con relativo archivio, e non trasferirà i vostri dati a Google.

Accidenti, come stride questa scritta nelle pagine di FeedBurner, solitamente piene di ironia e con un copywriting studiato ad arte.

Non si poteva scrivere qualcosa del tipo:

Ehi, c’è un importante aspetto che riguarda il tuo login e l’acquisizione di FeedBurner da parte di Google. Hai 14 giorni di tempo per decidere. Clicca qua per i dettagli.

Ma anche se avesse dovuto rimanere tutto in una pagina, si sarebbe sicuramente potuto studiare qualcosa di meno arrogante, indipendentemente dall’importanza dell’informazione.

Lo stato dell’arte dei feedreader secondo Feedburner

Feedburner ha recentemente pubblicato un intervento in cui sono presentati i trend d’uso degli aggregatori web, come Google Reader, MyYahoo!, Bloglines e altri. Una posizione privilegiata quella di Feedburner, visto che può contare su più di 600.000 feed iscritti al proprio servizio.

Ecco qualche spunto interessante per capire come interpretare le statistiche dei propri feed:

  • i feedreader funzionano molto spesso con modalità diverse, ed è difficile riuscire a produrre un report d’uso che si riveli coerente. My Yahoo!, per esempio, riporta il numero di iscritti su base mensile, mentre altri reader forniscono (o tentano di fornire) una stima giornaliera
  • attenti a considerare il numero di iscritti a un feed un’importante misura del suo successo del vostro blog. Misure forse più importanti sono il numero di visite al singolo elemento del feed, e i click che dal feed portano sul vostro sito (audience engagement)
  • i principali feed reader che spingono gli utenti a cliccare sul feed per andare al vostro sito sono, nell’ordine, MyYahoo!, Google Reader e Bloglines. Per MyYahoo! la spiegazione è semplice: presenta solo poche righe dell’intervento, richiedendo al lettore di cliccare per procedere alla visualizzazione completa dell’intervento nel sito principale.
  • Google (Reader/Personalized Home Page), con il 59%, è lo strumento più usato per “leggere” gli elementi in un feed. Questo successo, aggiungo io, è probabilmente dovuto alla modalità di funzionamento di Google Reader, a “scorrimento”, in cui la lettura degli interventi di interesse prevede quasi sempre una rapida lettura dei precedenti
  • Google Reader si conferma anche il lettore a cui sono iscritti più feed tra quelli gestiti con Feedburner, il 76%, seguito da Bloglines e MyYahoo!

I migliori (o quasi) plugin per WordPress

Questo sito impiega WordPress, cioè un sistema di publishing per weblog, come piattaforma di gestione dei contenuti.

Worpress è sempre più usato non solo come software per pubblicare i propri weblog, ma anche per gestire veri e propri siti che non necessitano della complessità (o completezza) di un CMS.

E’ però inevitabile che, come per tutti i siti, anche in Fucinaweb le richieste di funzionalità aumentino. Grazie alla vastissima disponibilità di plugin, trovare qualche estensione di interesse non è troppo difficile.

Ecco allora una breve lista di plugin che ho scoperto in questi mesi e trovo particolarmente utili, oltre a utilizzarli spesso in questo sito. Non sono l’unico ad aver avuto questa idea, anzi, lo spunto per provare nuovi plugin è arrivata leggendo l’intervento Must-have WordPress plugins di Joe ‘Zonker’ Brockmeier.

  • Worpress Database Backup e Wp-cron – L’accoppiata vincente. Il primo vi permette di creare dei backup del database di WordPress direttamente dall’interfaccia di amministrazione. Il secondo rende l’operazione periodica, così potete salvare, o farvi mandare per posta ogni giorno, una copia di backup dei vostri dati (non è necessario un crontab installato sul server). Insostituibili
  • Category visibility – Un utile plugin se volete associare degli interventi a delle categorie, ma non volete che la categoria compaia nell’elenco proposto da WordPress nella spalla del vostro sito. Attenzione però all’impiego, a volte è meglio utilizzare opportuni tag (vedi prossimo plugin)
  • Jerome’s keywords – Volete far comparire in qualche punto del vostro intervento un elengo di tag in stile “web 2.0″? Questo plugin fa per voi. Attivatelo e nella schermata di inserimento degli interventi comparirà una nuova casella di testo, Keywords, che separete con delle virgole. A questo punto potete intervenire nei template e decidere di far comparire questo elenco come tag in fondo al post (potete guardare questo stesso articolo in Fucinaweb per capire cosa intendo) o anche nei meta tag nel codice sorgente della pagina. Infine, ma molto importante, verranno inseriti nel feed Rss del vostro sito degli opportuni tag per l’inclusione e categorizzazione in Technorati
  • Google Analytics – Se non volete inserire a mano il javascript di collegamento a Google Analytics, questo plugin fa per voi. Ma non è tutto. In un precedente intervento ho spiegato come Google Analytics possa essere utilizzato anche per tracciare i collegamenti verso siti esterni al nostro. Attivate il plugin e avrete anche questa comodità. Esiste in realtà un altro ottimo plugin che fa le stesse cose, anzi, sulla carta ben di più. Si tratta di WordPress Reports, un plugin che oltre a integrarsi con Google Analytics lo fa anche con Feedburner. Molto bella anche la parte di report integrata con WordPress. Ma questo prodotto manca ancora un po’ di maturità e il tracciamento di link esterni, per entrare nello specifico, non funziona troppo bene
  • Google Sitemaps – Un plugin che non può mancare e che automatizza il processo di creazione del file Xml utilizzato da Google Sitemaps (in passato ho parlato di Sitemap anche qui su Fucinaweb)
  • Feedburner feed replacement – WordPress già rende disponibili flussi Xml in diversi formati. Perché ricorrere a Feedburner, potreste chiedere. Per diversi motivi, di cui il principale è capire se qualcuno dei vostri lettori li sta utilizzando, e come…
  • Search and replace – Un’utility, pregevole soprattutto se vi trovate a dover sostituire massicciamente un testo nello storico dei vostri interventi. Da usare con opportuna cautela

Altri di meritevoli?