Dal 2004 il blog di Antonio Troise

Tempo fa scrissi un paio di guide su come risparmiare banda sul proprio sito comprimendo tutte le pagine con Gzip e riducendo le dimensioni del file javascript prototype. Le operazioni che, però, avevo descritto in quei tutorial non sono più del tutto valide in WordPress 2.5. Ecco, in particolare, cosa è cambiato e come agire di conseguenze.

Addio alla compressione Gzip da WordPress

Su WordPress 2.3, per attivare la compressione delle pagine web, era sufficiente andare nel Pannello di Controllo di WordPress e, nella sezione Opzioni/Lettura (Options/Reading per la versione in lingua inglese), spuntare la voce “WordPress deve comprimere gli articoli (gzip) se il browser lo richiede“. Questo permetteva, in tutta semplicità, di comprimere in formato Gzip (attivando la compressione HTTP) prima di inviarlo al browser, in modo da alleggerire la dimensione della pagina (risparmiando quasi il 70% di dimensioni in una pagina di puro testo) e diminuirne il tempo trasferimento facendo lavorare un po’ di più il computer dei vostri lettori.

Ora, con WordPress 2.5, tutto questo non è più possibile. Sono andato a vedere in tutti i menu e sottomenu dell’Area di Amministrazione di WordPress, ma della voce per la compressione del contenuto delle pagine web tramite gzip, non ve ne era più traccia. Ho trovato la conferma anche qui: pare che in In WordPress 2.5 questa opzione non sia più presente!

Pare che la spiegazione, data da Ryan Boren, sia quella che era nata nel Team di Sviluppo di WordPress, l’esigenza di voler spostare la decisione della compressione delle pagine web al server stesso; infatti, oramai, qualsiasi webserver è in grado di gestire la compressione del contenuto, e la maggioranza dei piani di hosting prevede questa funzione, sia abilitata per default, sia opzionale (come nel caso di cPanel). Evidentemente questo dovrebbe avere ovvi vantaggi prestazionali, anche se non ho ben chiaro quanto possa essere.

Riattivare la compressione gzip da php

Se, però, il vostro webserver è tra i pochi che non supporta la compressione gzip (sul mio per esempio no ho trovato la funzione), potete verificare, come suggerisce Elliott C. Back, se almeno il vostro interprete php offre le funzioni di controllo dell’output, e attivarle tramite .htaccess con queste due righe di comando:

<br /> php_flag zlib.output_compression on<br /> php_value zlib.output_compression_level 2<br />

Altrimenti, dovrete modificare il vostro file index.php nel seguente modo:

<br /> <?php /* Short and sweet */ define('WP_USE_THEMES', true); ob_start(”ob_gzhandler”); require('./wp-blog-header.php'); ob_end_flush(); ?><br />

Attenzione, però: se attivate la compressione via php, dovrete modificare il file tiny_mce_config.php (in wp-includes) come suggerito da Andrew Ozz nella lista wp-testers, e disabilitare la compressione in questo file, altrimenti l’editor visuale verrà compresso due volte!

Riattivare la compressione gzip con un plugin per WordPress

Se, però, come immagino, non volete mettere mano ai file php e non potete comunque attivare la compressione sul vostro webserver, potete allora installare il plugin realizzato da Sergej Müller. Si chiama Compress for WordPress 2.5, ed è un plugin che agisce pressoché allo stesso modo descritto nel capitolo precedente senza, però, richiedere alcuna modifica manuale. Purtroppo è in tedesco ma è abbastanza chiaro quello che fa: è sufficiente attivarlo e lui comprimerà e vostre pagine web da php.

Come verificare che il plugin Compress for WordPress 2.5 svolga il suo lavoro

Di solito mi fido delle descrizioni che gli autori danno dei propri plugin, ma siccome, in questo caso, ci troviamo di fronte ad un plugin che non rilascia alcun feedback su quello che fa e risulta essere del tutto trasparente a tutti tranne che al browser, ho deciso di verificare se Compress for WordPress 2.5 funzionava correttamente, anche perché non volevo segnalare qualcosa di cui non ero neanche io certo sul suo funzionamento!

Per farlo ho installato una comoda estensione per Firefox, Live HTTP Headers 0.13.1, che permette di catturare e analizzare l’headers delle pagine HTTP che il browser visualizza. Infatti, l‘informazione che ci dice se la pagina è stata compressa, è contenuta in una variabile: Content-Encoding.

Se, quindi, attivo il plugin Compress for WordPress 2.5, e ricarico l’homepage del mio sito, vedrò che la maschera di Live HTTP Headers (raggiungibile da Firefox dal menu Strumenti/Live HTTP Headers) mostra il parametro suddetto settato come:

Content-Encoding: gzip

Se, invece, disabilito il plugin, il parametro di Content-Encoding non viene neanche passato e, l’unica cosa che è possibile trovare (e che si trova anche nel caso) precedente, è il parametro “Accept-Encoding: gzip,deflate” che sta ad indicare che il nostro browser è in grado di gestire i contenuti compressi.

Quindi, in soli due minuti, abbiamo verificato che il plugin svolgesse correttamente il suo lavoro!

Compressione del 150% del file prototype.js 1.6.0

Per quanto riguarda, invece, la compressione del voluminoso framework Prototype (un file JavaScript che ha loscopo di facilitare lo sviluppo di applicazioni web dinamiche di tipo Ajax) in uso su WordPress, non è cambiato molto se non la versione da utilizzare. Infatti, rispetto a WordPress 2.3, che usava la versione 1.5.1.1, la nuova release di WordPress 2.5 usa la versione 1.6.0.
Potete controllarlo voi stessi: basterà leggere la prima riga del file wp-includes/js/prototype.js

<br /> /* Prototype JavaScript framework, version 1.6.0<br />

Quindi, se non volete comprimere voi stessi il file javascript (che di per sé è grande 121 KB), con un dei tanti tool online che ho descritto in precedenza, dovete fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi tutte le versioni di Prototype.

Quello che dovrete fare voi, quindi, è scaricare il file protopack_v2.19b.zip dal sito Prototype: Core (nel vecchio tutorial era il protopacked_v2.17.zip), scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous.
In particolare questo package contiene le release 1.4, 1.5, 1.5.1.2 e 1.6.0.2 di Prototype e la release 1.7.1_beta3, 1.8.1 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora potete far riferimento direttamente al file Protoculous (esistono le versioni 1.5.1.2 + 1.7.1_beta3 e 1.6.0.2 + 1.8.1), che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

In generale, però, nel nostro caso sarà sufficiente scegliere la versione compressa del file prototype.js. Quindi, una volta scaricato e scompattato il pacchetto zip protopack_v2.19b.zip, aprite la cartella “files” e vi troverete 3 cartelle: qui aprite la cartella “compressed“, quindi la cartella “prototype” e, infine, entrate nella directory “v1.6.0.2“ (non è esattamente la stessa versione rilasciata con WordPress 2.5, ma i cambiamenti sono davvero minimi e comunque compatibili con una release inferiore).
Qui, vi troverete, dinanzi a due differenti versioni compresse dello stesso file Prototype.js:

prototype-1.6.0.2-packer.js : compresso con Dean Edward’s Packer 3 \w con le opzioni “Base62 encode” e “Shrink variables”
prototype-1.6.0.2-shrinkvars.js : compresso con Dean Edward’s Packer 3 \w con la sola opzione “Shrink variables”.

La differenza, sostanzialmente, sta nelle dimensioni: il prototype-1.6.0.2-packer.js è grande 48 KB (la versione 1.5.1.1 compresso, che si usava con WordPress 2.3, invece, era grande solo 40 KB) mentre prototype-1.6.0.2-shrinkvars.js arriva fino a 76 KB.
Io, per il mio sito, ho usato prototype-1.6.0.2-packer.js (risparmiando oltre il 60% di spazio) che ho, ovviamente, rinominato in prototype.js e, quindi, salvato nel percorso “wp-includes/js” sostituendo il precedente file (magari fatene un backup per sicurezza).