WordPress alla velocità della luce

WordPress alla velocità della luce
Enrico Ladogana
Ranked.it

PREMESSA

Pur essendo consapevole dell’importanza della velocità delle pagine web, anche in termini di posizionamento nei motori di ricerca, non avevo mai condotto una ottimizzazione, per così dire, rigorosa. In genere mi limito ad effettuare una veloce analisi tramite GTmetrix o Google Speed Online e ad attuare solo alcune delle modifiche suggerite. Del resto, come in molti sostengono, ritengo che la velocità sia uno dei tanti parametri che concorrono a migliorare il posizionamento di un sito web, non l’unico, non il più importante, per cui mi sembra inutile esasperare la sua applicazione, giacché, in tal caso, i costi superebbero sicuramente i benefici.

Per una volta, tuttavia, ho deciso di apportare tutti i correttivi proposti da quei tool proprio al sito che più mi rappresenta: Ranked.it, che utilizza la piattaforma WordPress.
Si è trattato di un “esercizio compulsivo” che presumo si possa concludere con questo articolo, giacché, difficilmente, ripeterò le medesime operazioni con altri siti, miei o di clienti.

Ebbene, al termine di parecchie ore di lavoro sono riuscito ad ottenere i seguenti risultati:

Rapporto Gtmetrix

Rapporto Google Speed

Eccellenti, oserei dire!

Prima dell’intervento, l’home page del mio blog veniva caricata in oltre 5,5 secondi, ora in poco più di 2! Come ho anticipato, tuttavia, solo alcune delle attività che ho messo in pratica determinano miglioramenti consistenti. Molte altre, pur avendo contribuito ad ottenere parte di quel risultato, hanno un costo, a mio avviso, di molto superiore al beneficio apportato.

IL METODO

L’analisi della velocità di esecuzione della pagine di Ranked è stata effettuata tramite i tool precedentemente elencati:

• GTmetrix;
• Google Speed Online.

L’attività è stata ripartita in sei step, a loro volta suddivisi in un certo numero di task:

• OTTIMIZZAZIONE DELLE COMPONENTI DEL TEMA DI WORDPRESS

  • eliminazione hack e script per browser obsoleti;
  • ottimizzazione del css;
  • compressione del css tramite Cleancss;
  • ottimizzazione immagini del tema tramite Sumsh.it e Optipng;
  • creazione di sprite css tramite Spriteme.

• DISINSTALLAZIONE PLUGIN INUTILI O OBSOLETI

  • generazione report Plugin Performance Profiler (P3);
  • disattivazione e cancellazione dei plugin non utili o inefficienti;
  • sostituzione dei plugin utili ma inefficienti;
  • sostituzione di plugin con funzioni omologhe nel tema di WordPress;
  • ottimizzazione del database e pulizia del sistema.

• DEFINIZIONE DI UN SISTEMA DI CACHING

  • installazione di W3 Total Cache;
  • installazione di Wp Smush.it.

• CONFIGURAZIONE DEL SERVER

  • attivazione della direttiva HTTP Keep Alive;
  • attivazione delle direttive gzip e deflate.

• OTTIMIZZAZIONE DEL JAVASCRIPT DI GOOGLE ANALYTICS

  • spostamento dello script prima della chiusura del body;
  • trasferimento dello javascript in locale;
  • vari esperimenti.

• UTILIZZO DI UN CDN (CONTENT DELIVERY NETWORK)

Ho utilizzato il font rosso per evidenziare le operazioni che ritengo indispensabili per aumentare la velocità delle proprie pagine web; le rimanenti possono anche essere tralasciate in tutto o in parte.

Due avvertenze:

• alcuni task potevano essere completati tramite lo stesso tool Gtmetrix (che, al termine di ogni analisi, fornisce, ad esempio, immagini e css ottimizzati), ma ho preferito utilizzare tool online specifici;
• non sono un esperto di sistemi e, soprattutto, di server, mi scuso, pertanto, se risulterò impreciso e/o omissivo nella trattazione di certi argomenti.

OTTIMIZZAZIONE DEL CSS E DELLE IMMAGINI

Ranked è realizzato tramite la piattaforma Open Source WordPress ed è on-line da diversi anni; grafica e codice del template sono stati costruiti “sartorialmente” quando ancora era attivo quel surrogato di browser denominato Internet Explorer 6. Per cui, prima dell’ottimizzazione, il sito presentava elementi che ora non hanno più ragione di essere e che, ovviamente, ho rimosso. Nella fattispecie alcuni hack nel css ed i fix per le immagini in formato .png (formato, al tempo, non supportato dal pessimo software di navigazione di Microsoft).

Terminata quella fase, ho provveduto a rivedere il css del mio template, rimuovendo classi ed id non più utilizzati e razionalizzando i rimanenti (ridefinendo il codice in maniera virtuosa, laddove possibile, per le classi con più di due selettori discendenti). A questo punto ho compattato il file tramite il tool Cleancss.

Consiglio di non esagerare con la compressione: prima o poi sarà necessario effettuare ulteriori modifiche al foglio di stile, per cui è preferibile che sia ancora leggibile al termine dell’operazione.

Infine ho ottimizzato le immagini del tema tramite Smush.it e Optipng.

Il primo è un tool di Yahoo! (che vedremo, poi, verrà utilizzato anche tramite plugin) che permette di ottenere una versione ottimizzata delle proprie immagini in tempo reale, il secondo un software specifico per l’ottimizzazione dei file .png, che si è reso necessario in quanto l’applicazione del primo non è stata sufficiente a rimuovere un warning di GTmetrix.

Ho effettuato, a dire il vero, un ulteriore operazione: la creazione di uno sprite css. Si tratta di una tecnica di Web Design che prevede di accorpare un set di elementi grafici (ad esempio, header, pulsanti, icone e quant’altro) in una unica immagine, che verrà richiamata quale background dal codice css delle varie classi e id contenuti nella pagina. Ciascun css, tramite l’imposizione di determinate coordinate, visualizzerà solo una porzione specifica della stessa immagine, quella che, ovviamente, gli appartiene.

L’operazione, almeno per il mio sito, è risultata fine a sé stessa, lo ammetto! Mi ha, tuttavia, consentito di familiarizzare con un tool online, Spriteme, che adotta un funzionamento che ha del geniale, almeno a mio parere:

• si memorizza nei preferiti la sua home page;
• si accede al sito che si vuole ottimizzare;
• si richiama il preferito precedentemente memorizzato;
• il cambio di pagina non avviene ed appare, invece, una finestra controllata dal tool che analizza il codice e permette, poi, di effettuare il download delle immagini che compongono gli sprite e del relativo codice css.

Ho provato diversi altri tool, ma ritengo che questo sia, in assoluto, il più semplice da utilizzare.

DISINSTALLAZIONE PLUGIN INUTILI O OBSOLETI

Per ottenere una veloce installazione di WordPress ritengo sia essenziale l’installazione di P3, Plugin Performance Profiler realizzato da GoDaddy.

L’applicazione permette di determinare il peso di ciascun plugin installato nell’infrastruttura misurandone l’impatto in termini di velocità e numero di query.

Non dispongo, purtroppo, di immagini precedenti all’ottimizzazione, posso assicurare, tuttavia, che i tempi di caricamento e il numero di query, al termine dello step, si sono quanto meno dimezzati.

P3 Report

P3 Runtime

L’analisi offerta da questo strumento dovrebbe condurre ad un solo risultato: l’eliminazione dei plugin non indispensabili e/o obsoleti.

L’installazione di un plugin, infatti, consente di ampliare in maniera sensibile le funzionalità di un sito o di un blog, ma, di contro, determina anche degli effetti collaterali:

• un aumento delle query che il sistema è costretto ad effettuare;
• spesso una diminuzione del rapporto tra contenuti e html, che rappresenta un fattore determinante per il posizionamento dei siti web; tale inconveniente è dovuto alla scarsa ottimizzazione del codice utilizzato da molti developer di plugin: sovente css, javascript ed altri elementi che li compongono vengono inseriti nella sezione head della pagina o addirittura inline, anziché in file separati;
• un’affidabilità, quanto a codice e ottimizzazione, non paragonabile a quella del sistema base di Automattic, l’azienda che ha creato WordPress.

Pertanto, la permanenza di un plugin dovrebbe essere determinata sulla base di un’analisi costo – beneficio. Se il costo, espresso in termini di riduzione della velocità di esecuzione delle pagine, supera il beneficio (il cui valore, ovviamente, può stabilirlo solo chi gestisce il sito), il plugin deve essere eliminato!

Si badi bene, con quel termine intendo la cancellazione definitiva dell’elemento, operazione che può essere effettuata manualmente, tramite ftp, o dal backend del sistema. WordPress, infatti, effettua un controllo su tutti i plugin installati, per poi processare solo quelli attivi; pertanto la semplice disattivazione non è sufficiente a raggiungere lo scopo che ci siamo prefissi: la velocità della luce!

Se un plugin è utile ma inefficiente, si può provvedere ad individuare un suo sostituto che non presenti gli stessi inconvenienti.

Infine, qualora si sia sufficientemente esperti, è raccomandabile sostituire, laddove possibile, i plugin con funzioni all’interno della pagina functions.php del tema di WordPress. Per esempio, nel mio caso specifico, ho inserito a mano il codice di Analytics e quello relativo alla paginazione degli articoli e altrettanto potrei fare con i pulsanti di condivisione social.

In rete vi sono centinaia di siti che propongono snippet che attivano funzionalità omologhe a quelle ottenibili tramite l’uso di plugin, che consentono, rispetto a questi ultimi, di ridurre notevolmente il consumo di risorse.

ATTENZIONE: la disinstallazione di un plugin elimina tutti i file che lo compongono, ma, molto spesso, non tutti i suoi riferimenti nel database. Per effettuare l’operazione di eliminazione di questi elementi è possibile utilizzare il plugin Clean Option: il procedimento è piuttosto complesso e presenta qualche rischio, pertanto deve essere effettuato da utenti esperti e, comunque, previo backup del database.
Può, inoltre, essere installato, anche contemporaneamente, il plugin WP Cleanfix che permette di ottimizzare il database e di rimuovere gli elementi del sistema (revisioni, commenti in spam, bozze, file cestinati, ecc.) che non hanno più ragione di esistere.

DEFINIZIONE DI UN SISTEMA DI CACHING

Nella fase successiva ho implementato il sistema di caching. Esistono numerosi plugin che permettono di attivare tale funzionalità. Ho notato, tuttavia, che la maggioranza delle pagine che trattano dell’argomento consigliano di utilizzare W3 Total Cache e così ho fatto.

Il plugin, di fatto, ottimizza le prestazioni del server, consente di ridurre i tempi di caricamento degli elementi html, css, javascript e media che compongono un sito web attraverso compressione e Minify (operazione che elimina spazi bianchi, commenti e tutto ciò che non è strettamente indispensabile per eseguire un file di codice).

La configurazione del plugin è piuttosto ostica: ritengo, tuttavia, che le impostazioni di default siano adeguate per la maggioranza dei siti web. Ad ogni modo, per approfondire, sono presenti in rete numerose guide sull’argomento.

A questo punto ho installato Wp Smush.it che, in maniera totalmente automatica, utilizza le Api del servizio di Yahoo! (di cui ho parlato in precedenza) al fine di ridurre il peso delle immagini di cui si è effettuato l’upload.

Infine, qualora il vostro tema utilizzi custom query, è possibile attivare una procedura di caching modificando lo snippet che segue.

<?php 
// Get any existing copy of our transient data
if ( false === ( $special_query_results = get_transient( 'special_query_results' ) ) ) {
// It wasn't there, so regenerate the data and save the transient
$special_query_results=new WP_Query('cat=5&amp;order=random&amp;tag=tech&amp;post_meta_key=thumbnail');
set_transient( 'special_query_results', $special_query_results );
}
// Use the data like you would have normally...
?>

CONFIGURAZIONE DEL SERVER

Nonostante le ottimizzazioni precedenti l’indice Page Speed Grade di Gtmetrix difficilmente si discosta dal valore C se non sono attivate nel server che ospita il sito due direttive di Apache:

• Keep alive (si tratta di una componente di Apache che permette di realizzare connessioni persistenti con uno stesso TCP; si tratta di un concetto alquanto complicato, che va al di là dello scopo dell’articolo, per cui, volendo approfondire l’argomento, consiglio questa lettura);
• Gzip e deflate (si tratta di direttive che si occupano di gestire la compressione di alcuni degli elementi che compongono un sito web, potete ottenere maggiori informazioni tramite Wikipedia).

Ovviamente l’attivazione di tali direttive deve essere richiesta al proprio hosting.

JAVASCRIPT DI GOOGLE ANALYTICS

Forse è eccessivo dedicare un intero paragrafo all’ottimizzazione del codice di Google Analytics. Si tratta, tuttavia, di un javascript un po’ “scomodo” e piuttosto pesante, anche se invocato in modalità asincrona. Peraltro le conclusioni a cui sono giunto possono essere applicate a qualsiasi Javascript che, per vari motivi, Total Cache non riesce a processare correttamente.

Le istruzioni di Google impongono il caricamento dello stesso nella sezione head della pagina html; io però mi sono chiesto se potevo ottenere qualche vantaggio ponendolo, invece, giusto prima della chiusura body. In effetti, così facendo, si ottiene un leggero aumento delle prestazioni.

Di contro, non vengono più tracciati gli utenti che chiudono il browser prima che sia completamente caricata la pagina web, particolare trascurabile, per quanto mi riguarda.

Al riguardo consiglio la lettura degli articoli che seguono:

• http://www.websiteoptimization.com/speed/tweak/google-analytics/
• http://mathiasbynens.be/notes/async-analytics-snippet

Quale sia la posizione dello script, sottoponendo il sito a Google Speed Online, si ottiene comunque un warning:

Le seguenti risorse memorizzabili nella cache hanno una durata di aggiornamento breve. Specifica una scadenza di almeno una settimana in futuro per le seguenti risorse:
http:// www. google-analytics. com/ga.js (2 ore).

Esaminando tutte le opzioni di Total Cache non ho trovato alcun elemento con data di scadenza posta a due ore; per cui sono giunto alla conclusione che questo parametro è immodificabile e viene determinato da Google stessa e che il plugin di caching non è in grado di processarlo correttamente, ma non ho certezze su questa affermazione e, soprattutto, su quelle che seguiranno.

Un ulteriore modifica mi ha consentito, comunque, di risolvere, almeno in parte, il problema: anziché inserire direttamente il codice di Analytics in footer.php del tema di WordPress, ho creato un action e l’ho posta in functions.php. Di seguito il suo codice:

Lo script viene caricato automaticamente tramite wp_footer() che, ovviamente, deve essere presente nella pagina footer.php del tema e posto giusto prima della chiusura del body. Nella quarta riga dell’action è necessario inserire il codice dello script fornito da Google. Codice che, volendo, potrebbe pure essere ottimizzato attraverso un tool Minify.

<?php 
add_action('wp_footer', 'add_googleanalytics');
function add_googleanalytics() { ?>


// Inserire codice Analytics
<?php } ?>

Al termine di questa operazione l’indice di Page Speed Online ha raggiunto il 100%, mentre GTmetrix presentava un ulteriore warning, argomento dello step successivo.

Ma non ero ancora del tutto soddisfatto, per cui, complicando ulteriormente le cose (ne sono consapevole!) ho provato anche a “prendere il controllo” del Javascript di Analytics copiandolo in locale, nella cartella del tema di WordPress, modificando, di conseguenza, lo script che lo invoca (a questo punto, per poter disporre di un Javascript sempre aggiornato, sarebbe necessario creare una procedura di cron job nel server che, periodicamente, confronti l’esemplare in locale con quello fornito da Google e provveda alla sostituzione del primo qualora il secondo sia più aggiornato).

Questa procedura ha portato un incremento di velocità del sito meno che trascurabile (perlomeno quando ho effettuato la misurazione, nulla si può dire, tuttavia, nel caso in cui la rete sia congestionata) ma, soprattutto, ha generato un nuovo warning: il Javascript di Analytics, infatti, non viene compresso da Total Cache. A questo punto ho sospeso, almeno temporaneamente, i test.

UTILIZZO DI UN CDN (CONTENT DELIVERY NETWORK)

La posizione di questo step è volutamente ultima: non ho effettuato, infatti, tale ottimizzazione che, presumo, mi avrebbe consentito di ottenere 100% nell’indice Yslow di Gtmetrix.
Un servizio di Content Delivery Network consente di effettuare la copia della maggior parte dei contenuti del proprio sito web (in genere, i cosiddetti media) presso una rete distribuita di server. L’uso di tale applicazione permette, molto sinteticamente, di:

• offrire all’utente la copia dei contenuti posta nel nodo a lui geograficamente più vicino, aumentando quindi la velocità di fruizione degli stessi;
• migliorare la distribuzione dei contenuti in caso di congestione delle rete (se, ad esempio, un server è sovraccarico, in un dato istante, può esserne utilizzato un altro che dispone di una copia degli stessi elementi);
• gestire in maniera automatica la propagazione degli aggiornamenti dei contenuti tra tutti i server che ne ospitano una copia.

Total Cache è già predisposto per l’utilizzo del CDN offerto da Cloudflare (gratuito o a pagamento), ma consente anche di utilizzare qualsiasi altro servizio similare.

Personalmente ho ritenuto del tutto inutile l’attivazione di tale funzionalità per un sito di modeste dimensioni quale Ranked; in effetti Gtmetrix consiglia di utilizzare il CDN per sole dieci immagini del mio blog, il beneficio sarebbe alquanto limitato.

La pratica, invece, può risultare piuttosto efficace per siti di dimensioni più generose, soprattutto per quelli che contengono numerosi media. Aggiungo, inoltre, che l’attivazione del servizio comporta delle modifiche ai DNS, operazione che, per la maggior parte degli utenti, risulta alquanto complessa e che, generalmente, deve essere demandata all’hosting.
A questo punto l’ottimizzazione può dirsi terminata!

Di seguito propongo uno schema visuale che riassume tutto il procedimento adottato.

WordPress alla velocità della luce
Enrico Ladogana
Ranked.it