Nuove modalità per risparmiare banda con Wordpress 2.5: addio alla compressione Gzip direttamente da Wordpress e comprimere del 60% il file prototype.js v1.6.0
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:
Altrimenti, dovrete modificare il vostro file index.php nel seguente modo:
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
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).

ottimo post, spiegazioni complete e comprensibili.
complimentoni!
8 aprile 2008 alle 14:01 | Rispondi a pAol
@pAol: grazie
8 aprile 2008 alle 15:17 | Rispondi a Antonio Troise
Personalmente non sono del tutto convinto che comprimere sia sempre conveniente. Posso capire alleggerire i file js che – quando pieni di funzioni inutili per le nostre necessità – diventano un inutile spreco di banda, ma va ricordato che un documento compresso diventa un ulteriore carico per il server (cpu) che moltiplicato per n visitatori fa sicuramente risparmiare banda ma rallenta le prestazioni di generazione del documento. Inoltre la pagina risulta più pesante computazionalmente anche per chi la riceve. Finché navighiamo con i nostri super-computer a sedici core… non notiamo nulla, ma non so quanto possa influire sui 300/400mhz di un processore per cellulari o palmari.
La banda è giusto monitorarla, ma non è corretto farla diventare l’unico parametro da “preservare”.
Ciao,
Emanuele
8 aprile 2008 alle 16:04 | Rispondi a Emanuele
@Emanuele: Questo è in parte vero ma i test che ho condotto io dopo l’ultimo Bandwidth Exceed di fine Gennaio 2008, mi hanno fatto propendere verso la compressione delle pagine, poiché ho risparmiato quasi il 40% di banda, che su 40 GB mensili, mi lasciano un ampio margine per eventuali aumenti di accessi.
Inoltre, per quanto riguarda i dispositivi mobili, credo (ma magari potrai smentirmi) che i loro browser non supportino la compressione GZIP e quindi il server invierà loro una versione normale della pagina: inutile dire che per i dispositivi mobili è necessario creare una versione leggera del sito (magari operando opportunamente sui css) a prescindere dalla compressione che, ripeto, non credo venga supportata.
Ciao
8 aprile 2008 alle 17:02 | Rispondi a Antonio Troise
Non so se sia per tutti così, ma ad esempio Opera Mini supporta GZip. La ricezione di una pagina compressa diventa dunque un ulteriore carico computazionale per il device mobile.
Capisco il tuo problema con il limite della banda ma chi non ha questo problema non sempre dovrebbe attivare la compressione. Ci sono situazioni in cui questo risulta uno svantaggio. Come al solito ogni cosa è relativa e va valutata caso per caso.
Ciao,
Emanuele
9 aprile 2008 alle 00:45 | Rispondi a Emanuele
@Emanuele: Sagge parole
9 aprile 2008 alle 11:08 | Rispondi a Antonio Troise
Da 211 KB a poco più di 50 mi sembra un ottima compressione! Grazie mille per la dritta!
9 aprile 2008 alle 17:50 | Rispondi a vik
[...] molto più completo di questo (in italiano) con ulteriori consigli per l’ottimizzazione su Levysoft: Nuove modalità per risparmiare banda con Wordpress 2.5. Tutorial ¦ 2.5 + gzip + howto + ob_start ¦ « Category Page 2.5 howto [...]
10 aprile 2008 alle 23:52
Il tuo articolo è decisamente più completo del mio, quindi ho aggiunto un link a questa pagina. Grazie mille del link, è un onore!
10 aprile 2008 alle 23:54 | Rispondi a Paolo / Pixline
@Paolo / Pixline: Hei grazie mille a te!
Sei stato molto gentile… anche se il tuo articolo è stata la mia fonte principale di ispirazione. Quindi, grazie anche a te!
11 aprile 2008 alle 13:14 | Rispondi a Antonio Troise
Ciao, ho trovato l’articolo molto interessante, ma non ho capito come modificare wordpress per fargli caricare i js più velocemente.. dove scrivo il codice per google.load?
3 agosto 2008 alle 20:55 | Rispondi a Marco
@Marco: Se intendi come usare le AJAX Library API di Google basta editare il file header.php del tuo tema wordpress, come ho scritto in questo altro articolo, oppure più semplicemente, se non vuoi mettere mano al codice php, puoi usare il plugin Google AJAX Libraries API Plugin che, però, non usa la versatile funzione google.load() che permette di puntare dinamicamente alla ultima release stabile!
Ciao
3 agosto 2008 alle 22:19 | Rispondi a Antonio Troise