bandwidth | Rev0lut1on 2.0 of my mind engine

Lug 7 2008

Automatizzare le operazioni del cPanel da shell unix con i comandi wget, ftp e curl: download automatico del DB Mysql e monitorare la banda disponibile

Il vantaggio di possedere un computer con Mac OS X è quello di avere sempre a disposizione, perché inclusa nativamente nel sistema operativo, una shell unix completa, per i più esperti, o Automator, per i meno esperti. Quest’ultimo strumento è una applicazione davvero potente perché consente di creare in maniera visuale, grazie ad un diagramma di flusso (workflow) e trascinando le azioni una dopo l’altra (drag & drop), programmi di automazione davvero complessi e articolati.

Ma dopo aver lavorato anni sui sistemi unix, avere sottomano una potente shell unix, è una tentazione di cui davvero non posso fare a meno. Infatti, con la semplice concatenazione di comandi (pipeline) come grep, sed e awk (altri comandi utili possono anche essere sort, uniq tail, head, cut e wc) in una sola riga, è possibile estrarre (scraping) informazioni da pagine web. Infatti, struttando il fatto che le pagine html sono, anche se in misura minora ad un più ordinato e formattato file xml, strutturate con i TAG, con pochi comandi è possibile fare del sano Web_scraping.

WGET

Il comando più potente da riga di comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione è, come noto, WGET.
Per scaricare un file è possibile usare una sintassi tipo:

<br /> wget http://www.miosito.it/directory/file.zip<br />

Ma la vera potenza di wget risiede nella possibilità di realizzare, con una sola riga di comando, un mirror ad un sito web.
Quindi per scaricare un intero sito in locale basta scrivere:

<br /> wget –mirror http://www.miosito.it/<br />

mentre, per scaricare solo una pagina con tutti i link interni:

<br /> wget -r -np http://www.miosito.it/index.htm<br />

Il problema è che sui sistemi MAC OS X, wget non è installato di default e, quindi, per chi non volesse passare per la fase di compilazione (anche se in giro esistono versioni già compilate per Tiger e Leopard) o, comunque, ha semplicemente la necessità di scaricare solo una file o una pagina web, allora è possibile usare una delle due alternative preinstallate su Mac OS X: ftp e curl.

FTP

Il comando FTP può essere usato anche per scaricare file HTTP.
La sintassi è molto semplice:

<br /> ftp http://www.miosito.it/directory/nomefile.html<br />

Come vedremo, in seguito, per i nostri scopi molto spesso il comando FTP è più che sufficiente per la maggior parte delle operazioni comuni.

CURL

CURL è un tool da riga di comando estremamente potente perché permette di scaricare in maniera molto flessibile ed automatizzata un qualsiasi numero di files da internet, secondo i protocolli HTTP o FTP, e di visualizzarli a schermo o di scriverli su disco.
La sintassi semplice, simile a quella dell’FTP, è:

<br /> curl -O http://www.miosito.it/directory/nomefile.html<br />

In realtà la sintassi completa è:

<br /> curl “URL del file da scaricare” -o “nome da assegnare al documento scaricato su disco”<br />

Ma la vera flessibilità del comando nasce dalla possibilità di usare nella sintassi dell’URL le parentesi quadre per indicare una serie di URLs incrementali.
Per esempio una sintassi tipo:

<br /> curl “http://www.miosito.it/image/129-[2947-2996]_img.jpg” -o “immagine#1.jpg”<br />

creerà in modo automatico tutti gli URLs compresi nell’intervallo numerico specificato, e scaricherà in successione i file corrispondenti. Ai files sull’HD verrà assegnato il nome specificato dopo la flag -o, usando l’indice #1 per creare nomi univoci, incrementati allo stesso modo della sorgente.
In poche parole la singola riga di cui sopra equivarrà ad aver digitato in successione tutti i comandi:

<br /> curl “http://www.miosito.it/image/129-2947_img.jpg” -o “immagine2947.jpg”<br /> curl “http://www.miosito.it/image/image/129-2948_img.jpg” -o “immagine2948.jpg”<br /> …<br /> curl “http://www.miosito.it/image/image/129-2996_img.jpg” -o “immagine2996.jpg”<br />

Attenzione: il flag -O dell’ultimo esempio differisce dal flag con la o minuscola usato in precedenza, in quanto per nominare il file sul disco rigido usa lo stesso nome del file remoto.

La successione di URLs incrementali non deve essere necessariamente numerica, ma anche alfabetica, ad esempio [a-z]. Inoltre in uno stesso comando si possono combinare più indici incrementali (notate come nel nominare il file è possibile usare anche i due indici #1 e #2)

<br /> curl “http://www.any.org/archive[1996-1999]/volume[1-4].html” -o “archive#1-vol#2.html”<br />

Monitorare la banda del proprio sito da riga di comando

Dati gli ultimi problemi di esaurimento della banda che hanno afflitto il mio sito, era evidente che una delle prime necessità che avevo era quello di monitorare costantemente la banda usata. Il problema è che, per farlo, dovevo ogni volta accedere al cPanel, il Pannello di Amministrazione del mio sito, dove, in un menu laterale, era possibile visualizzare la banda usata.

Allora ho deciso di crearmi un semplice script che, scaricasse la pagina html del mio cPanel, andasse a selezionare, con il comando grep, la riga che conteneva la frase “Monthly Bandwidth Transfer” e attraverso due comandi awk (i file separator usati in Awk sono relativi alla mia pagina cPanel e potrebbero variare a seconda delle diverse versioni e configurazioni del pannello di controllo), estrarre la banda usata:

<br /> ftp http://username:password@www.miosito.it:3456/frontend/x3/index.html</p> <p>grep “Monthly Bandwidth Transfer” index.html | awk ‘BEGIN {FS = “</td> <p>“} {print<br /> $4}’ | awk ‘BEGIN {FS = “>”} {print $2}’</p> <p>rm index.html<br />

Come potete notare, per semplicità ho incluso, direttamente nella URL, lo username e la password per accedere al Pannello di Amministrazione. Questo è possibile solo perché il metodo di autenticazione del cPanel si basa su htpasswd ma ricordiamo che non è un metodo sicuro perché, oltre a lasciare memorizzati informazioni personali, nella barra degli indirizzi del proprio browser o nella history del terminale usato, si lasciano tracce anche nei vari proxy in cui si passa e nei log del webserver, oltre, come comunque avviene l’autenticazione classica se non passa per SSL, con un semplice sniffer.

Ci tengo a precisare che quello sopra illustrato è solo uno dei tanti modi per risolvere il problema: questo, in particolare, è il primo che mi è venuto a mente, forte delle decine di script shell realizzati negli anni. Ovviamente è possibile anche renderlo più complesso ed efficiente, parametrizzando username, password e url e, magari, notificando con una mail o con un messaggio a video (magari anche con Growl), quando la banda è prossima all’esaurimento. Il tutto ovviamente potrebbe anche essere inserito nel crontab di sistema in modo da girare ogni ora.

Per esempio, un metodo non ortodosso, sarebbe quello di visualizzare l’output non a video ma direttamente in TextEdit usando il comando open con le pipeline. Per farlo, ho riunito i tre comandi sopra elencati in un file bash di nome: monitora_banda.bash.
Quindi lanciando:

<br /> ./monitora_banda.bash | open -e -f<br />

avremo questo risultato:

Più in generale questo è il risultato del comando ‘open’ presente su Mac OS X.
Altri esempi, potrebbero essere:

<br /> curl ‘http://example.com/encodingerror.html’ | open -a ‘Hex Fiend’ -f<br /> curl ‘http://example.com/example.html’ | open -a ‘TextMate’ -f<br /> curl ‘http://example.com/example.png’ | open -a ‘Preview’ -f<br /> curl ‘http://example.com/example.m4v’ | open -a ‘QuickTime Player’ -f<br />

Ma le possibilità, come vedete, sono infinite. Ma lo scopo di questo articolo era solo di illustrare alcuni metodi per automatizzare da riga di comando delle procedure. Il resto è lasciato all’inventiva di ciascuno di voi.

Download automatico del backup del DB Mysql

Il mio hosting non supporta il backup automatico del DB di Mysql perché non gestisce correttamente le schedulazioni di comandi da riga di comando. E’ per questo che ho realizzato un semplice script da inserire nel crontab, per scaricare quotidianamente il backup del proprio database.
Infatti, sempre nel cPanel, è presente una sezione “Backups” che permette di scaricare, manualmente e con un link statico, un full backup del sito, oppure un backup parziale del solo database Mysql o della sola home directory (il concetto esposto rimarrà comunque analogo per qualsiasi soluzione adottiate).
E’ evidente che, a questo punto, con un semplice comando, è possibile scaricare da terminale i backup:

<br /> ftp http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz</p> <p>Requesting http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz<br /> 401 Access Denied Still Working<br /> Username for `cPanel’: username<br /> Requesting http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz<br /> (with authorization)<br /> 2106 KB 849.95 KB/s<br /> 2156900 bytes retrieved in 00:02 (849.92 KB/s)<br />

Basterà quindi inserirlo (con il comando crontab -e) nel crontab (se non siete esperti potrete usare il Easy Crontab Creation Tool) in modo da fargli scaricare il backup del DB, per esempio, ogni giorno alle ore 11:30 del mattino:

<br /> 30 11 * * * * ftp http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz<br />

Attenzione: come ogni comando da terminale, FTP (ma lo stesso vale se usate WGET o CURL) andrà ad operare nella directory corrente di lavoro, quindi se volete archiviare i file scaricati in una directory apposita, spostatevici preventivamente con il comando cd nome_directory.
Inoltre, dovete tenere presente che tutti i downloads andranno a scrivere lo stesso file e, quindi, ogni giorno ci si ritroverà con solo l’ultimo file scaricato. Se avete intenzione di tenere traccia di tutti i backup scaricati, dovrete rinominare il file, per esempio, aggiungendoci un suffisso come la data di download (realizzabile o con il comando curl o con uno script bash).

Tag:automator, awk, backup, banda, bandwidth, bash, cpanel, curl, database, download, ftp, grep, html, ksh, Mac os x, Mysql, password, sed, shell, unix, url, wget

5 comments

Lug 2 2008

Come risparmiare banda: ridurre le email dei commenti e i backup via FTP, usare le AJAX Library API di Google con il plugin per WordPress e disattivare Google Translator che non porta traffico utile ad Adsense

Posted by Antonio Troise

Più volte mi sono dovuto imbattere in ottimizzazioni certosine per ridurre i consumi di banda mensile sul mio sito: riducendo le dimensioni dei file javascript, attivando la compressione HTTP e, a volte, anche spostando le immagini su un altro server. Ma non ho mai dovuto affrontare incrementi di banda di oltre 10/20 GB in un solo mese.
Infatti, lo scorso Giugno, con mia grande sorpresa a soli 20 giorni dall’inizio del mese, il mio sito aveva già esaurito la banda di 40 GB messa a disposizione dal Blooweb, arrivando, a fine mese, ad oltre 50 GB di banda totale. Grazie alla gentilezza dello staff del mio hosting, mi hanno ripristinato temporaneamente il servizio in attesa che capissi da cosa fosse dipeso questo improvviso aumento di banda.

Sicuramente nell’ultimo mese avevo ricevuto un incredibile aumento di visitatori e questo aveva sicuramente influenzato le statistiche: oltre 30.000 visitatori unici in più (103.000 solo a Giugno) rispetto alla media dei mesi scorsi con un incremento di banda sproporzionato di oltre 16 GB in più (giungendo a 39.52 GB a fine mese di solo traffico HTTP).

La banda è la somma del traffico HTTP, FTP, SMTP e POP

Quello che mi aveva colto impreparato, però, era che il traffico HTTP (evidenziato da tool statistici com Awstats) non era l’unico elemento che veniva conteggiato nella soglia di banda messa a disposizione da un hosting (ed evidenziato nella homepage del mio cPanel): infatti, oltre al traffico HTTP, veniva conteggiato anche quello FTP, SMTP e POP. Normalmente, però, questi valori sono sempre trascurabili rispetto alla banda generata dal traffico delle pagine web. Questo, però, fino a questo mese, visto che il 20 Giugno, a fronte di un traffico HTTP di soli 28.76 GB, il sistema misurava una banda totale che superava i 40 GB! Ovvero, stavo consumando oltre 10 GB tra traffico FTP, SMTP e POP! Una cosa davvero incredibile rispetto alla media dei mesi precedenti.

Troppi commenti con false email generano traffico SMTP

Analizzando con calma la situazione ho scoperto che la funzione di segnalazione dei commenti (del plugin per WordPress Subscribe To Comments) inviava quotidianamente molti messaggi che non venivano mai recapitati correttamente (nell’ordine di alcune centinaia al giorno), probabilmente perché molti utenti che lasciavano commenti sul mio blog non inserivano email reali. Ciò creava un indubbio traffico SMTP anche se credo non della portata di 10 GB mensili, visto che i messaggi recapitati erano solo ASCII.
Comunque, onde evitare problemi, ho provveduto ad eliminare tutte le email che si erano registrati su un solo articolo del mio sito (oltre il 95% delle mail memorizzate), supponendo che chi scrive un commento con una email fittizia sia un visitatore di passaggio e quindi non un commentatore abituale. In tal modo non ho dovuto disattivare completamente questa funzione.

Fare spesso via FTP i backup di siti molto grandi riduce la banda mensile

Un altro problema che ho messo in luce è che, se è vero che nel conteggio del traffico totale mensile, era prevista anche la banda FTP usata, allora ogniqualvolta eseguivo un backup del mio sito, questo erodeva la quota mensile. Ora siccome dal cPanel è possibile eseguire un backup di tutta la mia home directory e non solo della directory in cui risiedono le mie pagine web, ogni volta che faccio il backup del sito, scarico ben 639 MB (a fronte di un peso effettivo del mio blog di poco più di 200 MB). Se in un mese, come è accaduto a Giugno, eseguo 4-5 backup, consumo oltre 3 GB di banda mensile.
Per risolvere questo problema ho deciso di scaricare solo il contenuto effettivo del mio sito e, laddove possibile, sempre verso fine mese, in modo da tenere sotto controllo il consumo di banda.

Il problema ricorrente delle dimensioni dei file Javascript e le AJAX Library API di Google

Se questi ultimi 2 punti sono stati volti a risparmiare quel fattore di banda invisibile e difficilmente monitorabile, ho deciso anche di intervenire, ancora una volta, su quella HTTP. Devo dire che, mano a mano che avanza lo stato di ottimizzazione del sito, affrontare il problema della banda, è un lavoro davvero certosino e occorre considerare diverse variabili prima trascurate e, non da ultimo, alcuni elementi nuovi (come l’installazione di nuovi plugin) che sono intercorsi dall’ultima analisi.

Tra questi troviamo anche un vecchio problema: i file javascript. Infatti, nonostante la precedente volta li abbia compressi più che mai, nel solo mese di Giugno, i soli file JS occupavano ben 8.96 GB di banda mensile!

Per risolvere parzialmente questo problema, ho pensato, quindi, di poter sfruttare le AJAX Library API di Google. In pratica, Google, recentemente ha messo a disposizione di tutti le maggiori librerie javascript e ajax compresse, linkabili direttamente dai loro server: jQuery, Prototype, script.aculo.us, Mootools e Dojo!

Centralizzando la distribuzione dei framework javascript e sfruttando le infrastrutture della rete di Google è possibile ottenere innumerevoli vantaggi: caching (utilizzando il medesimo URL per i file, c’è la probabilità che il browser dell’utente abbia già scaricato la libreria precedentemente), compressione Gzip/Minify, e file ospitati sui server veloci di Google e quindi riduzione del traffico generato dal proprio sito.

E’ possibile richiamare gli script all’interno delle proprie pagine utilizzando la classica sintassi:

oppure con il metodo google.load(), che di fatto è molto più potente e performante, perché permette di indicare anche la versione desiderata della libreria:

<br /> <script src="http://www.google.com/jsapi"></script><br /> <script> google.load("prototype", "1.6"); </script><br />

Nel caso di script.aculo.us dovremo caricare anche prototype:

<br /> <script src="http://www.google.com/jsapi"></script><br /> <script> google.load("prototype", "1.6"); google.load("scriptaculous", "1.8.1"); </script><br />

Infatti, per garantire la compatibilità delle applicazioni, Google offre anche una serie di versioni diverse per ogni libreria Javascript e permette di specificare quella desiderata. Il versioning è, però, anche intelligente. Infatti, se si specifica una versione parziale della libreria (p.es 1.8), Google ci farà scaricare l’ultima release stabile di quella revision (p.es. 1.8.4), mentre se si specifica solo la versione “1” allora lui scaricherà l’ultima disponibile, ovvero, la “1.9.1”.

Plugin per WordPress per le Google AJAX Libraries API

Se non volete mettere mano al codice della funzione wp_head() di WordPress per eliminare il riferimento al file prototype residente sul server ed inserire il link a quello residente sul server di Google, esiste un comodissimo plugin: Google AJAX Libraries API Plugin. Una volta attivato non farà altro che sostituire (con un add_filter()) il riferimento a tutti i framework gestiti con la versione ospitata sui server di Google.

L’unico svantaggio è che non usa la versatile funzione google.load() (che permette di puntare dinamicamente alla ultima release stabile) bensì il classico link diretto al file javascript. Ciò vi costringerà a tenere sotto controllo la versione di Prototype usata da WordPress e aggiornare di conseguenza il plugin (che ancora non è inserito nella Repository Ufficiale dei Plugin per WordPress) oppure modificarlo a mano.
Inoltre, non punta neanche alla versione compressa del file javascript, il che comunque non rallenta minimamente il caricamento della pagina.

Infatti, come è possibile vedere, eseguendo i test con i Pingdom Tools, usando la versione non compressa di Google abbiamo un peso di 123,2 KB (che comunque non influenza la banda del proprio sito) e un tempo di caricamento di 0.5 secondi

mentre usando la versione ospitata sul mio server, a fronte di un peso complessivo di 46,6 KB abbiamo un tempo di caricamento di oltre 1,2 secondi!

Disabilitazione di alcuni plugin

Inoltre, tra i file più letti ho trovato tutta una serie di plugin per i commenti:

quoter.php (plugin: Quoter)
ajax-comment-preview-js.php (plugin: AJAX Comment Preview)
lmbbox-comment-quicktags.php (plugin: LMB^Box Comment Quicktags)

Ho deciso, quindi, in via del tutto sperimentale, di disattivarli (visto che comunque non sono essenziali per l’inserimento di un commento), per capire che influenza avevano sulla banda totale e sulla velocità del sito (monitorabile facilmente con i Pingdom Tools).

Disattivare Google Translator che non porta traffico utile ad Adsense

Al termine di queste mie analisi ho scoperto che un plugin che avevo installato stava producendo un aumento di banda non indifferente in maniera totalmente indiretta e difficilmente monitorabile: sto parlando del plugin per WordPress Global Translator, un tool per la traduzione automatica delle pagine nelle principali lingue sfruttando le API di Google Translator.

Infatti, da quando a fine Maggio lo avevo installato, il traffico proveniente dagli Stati Uniti è quasi raddoppiato, passando da 15.08 GB a ben 28.06 GB! Considerando che il mio sito è scritto in italiano, è facilmente intuibile che quel plugin aveva avuto il pregio di allargare la mia fetta di visitatori ad un pubblico che solitamente non mi leggeva.

Ma allora mi sono chiesto: il traffico in più proveniente dagli Stati Uniti era traffico utile e valido e poteva essere vantaggioso per il mio sito oppure era solo uno spreco inutile di banda? Il fatto che la traduzione automatica di Google non potrà mai rispecchiare fedelmente il testo scritto nella propria madre lingua, può portare gente realmente interessata a quello che dico o solo a visitatori passivi che incappano per errore nelle mie pagine? Devo dire che, per certe keyword specifiche, il mio sito risultava primo anche in lingua inglese, e ciò conferma il fatto che Google ha svolto un ottimo lavoro di indicizzazione delle mie pagine. Ma la mia esperienza con le pagine tradotte in automatico non è delle migliori, perché spesso non si riesce a cogliere il senso più profondo delle frasi ma solo una descrizione sommaria. E purtroppo non è questo quello che desidero dare ad un lettore!

Inoltre, per i più veniali, un altro indubbio svantaggio è che, a fronte di un raddoppio di banda usata e di pagine viste, ciò non portava ad alcun incremento degli introiti di Google Adsense che si attestavano sempre sugli stessi valori dei mesi precedenti. Questo capita perché, come ho potuto constatare, anche se la pagina risulta tradotta in inglese (o in qualsiasi altra lingua), i banner Adsense risultano sempre visibili in italiano, vanificando quindi il loro scopo perché nessun inglese cliccherà mai su una pubblicità scritta in un’altra lingua.

Quindi, a ragione, ho provvedduto a disabilitare la traduzione automatica del sito, sperando che, quando Google avrà tolto dal suo indice le pagine scritte in un altra lingua al di fuori dell’italiano, la quota mensili di banda consumata si possa attestare su valori ragionevoli.

Il problema della banda dei server italiani

Il problema dei server che risiedono in Italia è che la banda viene ceduta quasi a peso d’oro: un upgrade di soli 5 GB di traffico mensile mi viene a costare bene 42.00 € in più; considerando che, in teoria, avrei bisogno di almeno altri 20 GB di banda, il costo di gestione del mio sito lieviterebbe di oltre 120.00 €!
Capite bene perché, ogni 2-3 mesi, sono costretto ad ottimizzare al massimo le prestazioni del mio sito riducendo inutili sprechi! Spero che questa mia testimonianza possa essere utile a qualcuno che, come me, combatte quotidianamente con il traffico mensile.
Se poi avete qualche altra idea o suggerimento sono sempre disponibile ad ascoltarvi.

Tag:adsense, Ajax, api, backup, banda, bandwidth, blooweb, compressione, ftp, Google, google translator, Javascript, Php, Plugin, prototype, Wordpress

17 comments

Apr 8 2008

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

Posted by 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:

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).

Tag:Ajax, banda, bandwidth, browser, compressione, cpanel, gzip, Javascript, Php, prototype, Web 2.0, Wordpress, wordpress 2.5

12 comments

Gen 5 2008

Dove scaricare i framework Prototype compressi per WordPress per risparmiare banda e velocizzare il caricamento delle pagine

Posted by Antonio Troise

Quando descrissi come risparmiare banda per il proprio sito comprimendo, tra le altre cose, il voluminoso framework Prototype (un file JavaScript che ha loscopo di facilitare lo sviluppo di applicazioni web dinamiche di tipo Ajax) in uso su WordPress, ho detto che era possibile comprimerlo usando alcuni interessanti compressori javascript online: Dean Edwards’ Javascript Compressor, Dojo ShrinkSafe e MemTronic’s HTML/JavaScript Cruncher & Compressor.
Tra questi avevo suggerito di usare il Dean Edwards’ Javascript Compressor, perché aveva, in assoluto, il miglior rapporto di compressione, oltre il 50%, portando il prototype.js da 94.05 KB a 39.23 KB, con risultati significativi sia in termini di banda che di tempi di caricamento della pagina.
Il problema era che, ad ogni upgrade di WordPress, bisognava verificare la release del framework Prototype e ed eseguire ogni volta la compressione.

Se però volete risparmiare tempo ed evitare di dover, ogni volta, comprimere i nuovi file Prototype.js che vengono rilasciati insieme alla distribuzione di WordPress, potete, allora, fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi le versioni di Prototype 1.4, 1.5, 1.5.1.1, 1.6.0.

Quello che dovrete fare voi, quindi, è scaricare il file protopacked_v2.17.zip, scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous. In particolare questo package contiene la release 1.4, 1.5, 1.5.1.1, 1.6.0 di Prototype e la release 1.7.1_beta3, 1.8.0 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora dovete far riferimento al file Protoculous, che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

In generale, però, una volta scompattato il pacchetto zip, aprite la cartella “files” e vi troverete 3 cartelle: qui scegliete di aprire la cartella “compressed“, quindi la cartella “prototype” e, infine, entrate nella directory “v1.5.1.1“. Qui, vi troverete, dinanzi a due differenti versioni compresse dello stesso file Prototype.js:

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

La differenza sta nelle dimensioni: il prototype-1.5.1.1-packer.js è grande neanche 40 KB mentre prototype-1.5.1.1-shrinkvars.js arriva fino a 60 KB. Io, per il mio sito, ho usato prototype-1.5.1.1-packer.js che ho, ovviamente, rinominato in prototype.js e, quindi, salvato nel percorso “wp-includes/js” sostituendo il precedente file.

Quindi, in definitiva, ad ogni aggiornamento di WordPress, quello che dovrete fare è, andare su Prototype: Core e scaricare la versione desiderate del framework Prototype compresso.

Tag:Ajax, bandwidth, Javascript, prototype, Wordpress

3 comments

Gen 2 2008

Come risparmiare banda del proprio sito riducendo le dimensioni dei file javascript e attivando la compressione HTTP da WordPress

Posted by Antonio Troise

Il 28 Dicembre 2007 il mio sito aveva finito la banda messa a disposizione dal mio server di hosting Blooweb: ben 40 GB mensili. Se questo, da un lato, non poteva che farmi contento perché significava che avevo un discreto numero di visitatori quotidiani, da un altro correvo il rischio di rendere inaccessibile il mio sito per ben 3 giorni consecutivi. Fortuna che i ragazzi del servizio di assistenza tecnica mi sono venuti incontri e gentilmente mi hanno concesso qualche giga in più per arrivare a fine mese! Il problema però rimaneva: se qualche mese prima arrivavo a 20-25 GB di banda mensile adesso in soli 31 giorni superavo la quota di 40 GB. Cosa era accaduto in questo periodo? Sicuramente un aumento del numero di utenti era stata una delle cause ma qualcos’altro era latente nel codice html del mio sito.

Analisi del log degli accessi

Dalle statistiche mensile di Awstats ho scoperto che se le pagine html/xhtml occupano al mese 10 GB di banda (in teoria questo valore dovrebbe essere direttamente proporzionale al numero di articoli che scrivo), quello che mi sconcertava era che i file Javascript occupavano ben 15.31 GB complessivi! Una cifra davvero spropositata.

Ecco allora che era venuto il momento di porre rimedio alla situazione.

Analisi del codice HTML

Come prima cosa ho analizzato il codice html della homepage e ho preso nota dei file javascript che caricava.
Così ho visto che nell’header caricava:

mentre nel footer

<br /> <br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shCore.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushCpp.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushCss.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushJScript.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushPhp.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushSql.js"></script><br /> <script type="text/javascript" src="http://www.levysoft.it/wp-content/plugins/syntax/Scripts/shBrushXml.js"></script><br /> <script type="text/javascript">dp.SyntaxHighlighter.HighlightAll('code');</script><br /> <br />

Rispettivamente abbiamo, quindi:
prototype.js?ver=1.5.1.1 -> 94.05 KB addicted_live_search/js/prototype.js -> 53.86 KB addicted_live_search/js/live_search.js -> 692 bytes audio-player/audio-player.js -> 767 bytes syntax/Scripts/shBrush*.js -> 42.13 KB

Eliminare le ridondanze

Come vedete il plugin Addicted To Live Search caricava il file prototype.js che è lo stesso che nativamente usa WordPress. Cambia solo la release: se WordPress usa la versione 1.5.1.1, questo plugin usava la 1.5.0_rc0 (attualmente esiste la release 1.6).
Come primo passo, quindi, era inevitabile che modificassi il plugin “Addicted To Live Search” in modo da non caricare inutilmente due volte lo stesso framework javascript. Quindi ho editato il file live_search.php e commentato la riga relativa al framework prototype:

Con questa piccola modifica ho risparmiato 53.86 KB che, moltiplicato il numero di visite mensili, è sicuramente un valore non trascurabile, dato che questi codici javascript vengono caricati ad ogni singola pagina!

Per intenderci meglio, se un sito ha un numero giornaliero di pagine viste pari a 1.000, al mese abbiamo 31.000 pagine viste che moltiplicato quasi 54 KB, abbiamo un risparmio netto di oltre 1,6 GB di banda mensile (in questi calcoli ho considerato trascurabili gli effetti cache dei browser)! Con 100.000 visite al mese, avremmo un risparmio di 5,4GB di banda. Insomma, a conti fatti, risparmiare 54 KB non sembra poi una operazione inutile!

Comprimere i file Javascript

A questo punto bisognava risolvere anche il problema dell’eccessiva dimensione del file Prototype.js: ben 94.05 KB. Per farlo non ho fatto altro che comprimere il contenuto di questo file con uno dei tanti compressori di file javascript che si trovano in giro per la rete, in grado di ridurne le dimensioni, il tempo di caricamento di una pagina e, conseguentemente, la banda complessiva occupata!

Per scegliere quale fosse il miglior compressore per il file Prototype.js 1.5.1.1 ho eseguito diversi test con i seguenti 3 popolari compressori javascript online: Dean Edwards’ Javascript Compressor, Dojo ShrinkSafe e MemTronic’s HTML/JavaScript Cruncher & Compressor.
I risultati sono visualizzati in questa tabella riepilogativa:

	Original	Dean Edwards’	ShrinkSafe	MemTronic’s
file size(kb)	94.0	39.2	64.5	40.4
gzipped size(kb)	20.6	16.7	18.4	20.4

Anche se per pochi kilobyte, ho deciso, quindi, di prendere in considerazione Dean Edwards’ Javascript Compressor. Come risultato ho ottenuto, quindi, una riduzione delle dimensione di oltre il 50%, da 94.05 KB a 39.23 KB, per un risparmio complessivo di ben 54,82 KB.

Ovviamente, per continuare ad adottare questa soluzione, ad ogni upgrade della propria piattaforma di blogging WordPress, ci si dovrà ricordare di comprimere il nuovo file JS, operazione che consta in appena 2 minuti di attività.

UPDATE: Se però volete risparmiare tempo ed evitare di dover, ogni volta, comprimere i nuovi file Prototype.js che vengono rilasciati insieme alla distribuzione di WordPress, potete, allora, fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi le versioni di Prototype 1.4, 1.5, 1.5.1.1, 1.6.0. Quello che dovrete fare voi è scaricare il file protopacked_v2.17.zip, scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous. In particolare questo package contiene la release 1.4, 1.5, 1.5.1.1, 1.6.0 di Prototype e la release 1.7.1_beta3, 1.8.0 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora dovete far riferimento al file Protoculous, che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

Quindi, in definitiva, ad ogni aggiornamento di WordPress, quello che dovrete fare è, andare su Prototype: Core e scaricare la versione desiderate del framework Prototype compresso.

Attivare la compressione HTTP da WordPress

Un’altra cosa da fare è quello di andare nel Pannello di Controllo di Wordpress e, nella sezione Opzioni/Lettura, spuntare la voce “WordPress deve comprimere gli articoli (gzip) se il browser lo richiede“.
Infatti, WordPress permette di comprimere in formato Gzip (attivando la compressione HTTP), se il browser del visitatore lo supporta, in modo da alleggerire la dimensione della pagina e diminuirne il tempo trasferimento facendo lavorare un po’ di più il computer dei vostri lettori.

In pratica, quindi, quando un visitatore richiede una pagina questa viene creata dal server, compressa in Gzip ed inviata al browser del nostro lettore che provvederà in automatico a scompattarla e successivamente a visualizzarla.
Fate attenzione però che, se usate dei plugin che velocizzano il blog mediante lavoro sulla cache, come WP-Cache o WP Super-Cache (di fatto l’evoluzione di WP-Cache) e attivate la compressione Gzip, i plugin potrebbero non funzionare.
In particolare, nel caso di WP-Cache, per far convivere entrambe le soluzioni, dovrete modificare il file wp-cache-phase1.php seguendo la procedura indicata da Davide Salerno.

In definitiva questa operazione dovrebbe influenzare il valore della banda occupata dalle pagine HTML/XHTML static page (che, ne mio caso, a Dicembre 2007 era di ben 10.80 GB senza alcuna compressione attiva!)

C’è da dire che la compressione Gzip era sempre stata attiva sul mio sito: presumo quindi che, in seguito all’ultimo grande cambio release alla versione 2.3 di WordPress, questo opzione deve essere stata disabilitata per errore. Sono curioso, ora, di vedere quanto possa influenzare sulle banda complessiva.

Non resta che attendere

Per ora, mi sono fermato così. Al momento ho risparmiato complessivamente, per ogni pagina caricata ben 109 KB di Javascript, e un valore imprecisato di kilobyte attivando la compressione html, che al mese significa (sempre riportando un valore medio di 100.000 pagine) un risparmio di quasi 11 GB di bandwidth!

Al momento, gli altri file javascript non li ho compressi e forse, ad una analisi successiva, potrei anche rimuovere i plugin ad essi correlati (sostituendoli con altri più leggeri). Per il momento ho intenzione di aspettare 15 giorni per capire se tutte queste modifiche sono state sufficienti per recuperare un po’ di banda. Se così non fosse potrei provare a comprimere tutti i file Javascript e, magari, spostare su un altro server le immagini JPG, GIF e PNG che complessivamente occupano 4.81 GB di banda.

Infine, potrebbe anche essere utile comprimere i file CSS (nel mio caso arrivo a circa 18.14 KB complessivi): in questo caso vi suggerisco Compressor, una applicazione online in grado di comprimere sia codice Javascript o i fogli di stile CSS.

Intanto, per fosse interessato, metto a disposizione il file Prototype.js 1.5.1.1 compresso di WordPress 2.3.2: lo potete scaricare qui.