Tempo di Lettura: 9 minuti
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:
Nel caso di script.aculo.us dovremo caricare anche prototype:
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.
Grazie per questo articolo, presto saremo costretti anche noi ad altri interventi. 🙁
E’ per questo che secondo me faresti bene a prenderti un serverino all’estero. Magari le parti essenziali le lasci dove le hai (e probabilmente puoi tornare al piano con offerta di banda inferiore) e fare arrivare da fuori i file pesanti.
Il mio blog attualmente richiede circa 20GB di traffico mensile per via dei video… ma non ho problemi proprio perché li carico sempre su un server esterno al sito.
Riguardo alle altre ottimizzazioni… credimi, avessi il tempo mi ci dedicherei con forza. Apprezzo questo genere di attività… sono convinto che una pagina leggera è sempre più bella di una pesante. Indipendentemente dall’aspetto finale. 🙂
Ciao,
Emanuele
Ho notato in effetti che avevi finito la banda disponibile. Io avendo scritto il cms in proprio ho un buon controllo di tutto il traffico generato. Anche se lo spam e i bot da soli superano il traffico generato da utenti reali.
Ottima trattazione! 😉
@Emanuele: su che server ti appoggi?
@Tom: Se hai qualche dubbio chiedi pure! In bocca al lupo 😉
@DnaX: In effetti, credo che buona parte del traffico di un blog sia derivato dal frequente accesso di bot dei motori di ricerca e dello spam.
Pingback: links for 2008-07-02 « Andy’s Blog 2 Luglio 2008
[…] Levysoft » Come risparmiare banda: ridurre le email dei commenti e i backup via FTP, usare le AJAX … (tags: tips) […]
Antonio: HostingZoom per i dati pesanti. WebPerTe per il blog.
Fin ora sta funzionando a meraviglia… HostingZoom di banda me ne regala abbastanza (100gb/mese) e il nuovo piano adesso ne prevede 4 volte tanto. Inoltre riesce spesso a saturarmi i 4mbit dell’adsl nonostante il server sia in America, dunque hanno pure una buona connettività.
Credo che esista qualche piano più economico di HostingZoom comunque, prova a tenerlo in considerazione invece di fare continui upgrade. Considera anche il vantaggio di un carico distribuito e tutto lo spazio in più che puoi sfruttare.
Ciao,
Emanuele
@Emanuele: Ma io veri carichi pesanti non ne ho molti: se escludi le immagini e i file js (che ora ho anche hostato parzialmente su Google) mi rimane il solo carico http delle pagine del mio blog che, dato il numero di articoli e dato il numero di letture quotidiane, raggiunge soglie molto alte. Certo che 100GB al mese fanno gola…
Secondo me dovresti considerare qualche servizio di hosting estero. Per le tue esigenze, dove la banda conta più di tanto altro, potrebbero risultare convenienti. Ricordati anche del buon cambio euro-dollaro. A me l’account su HostingZoom costa meno di 30€ l’anno…
Ciao,
Emanuele
Io, essendo localizzatore software e traduttore informatico, cancellerei a priori i plugin di traduzione automatica, non fanno altro che aumentare il livello di “grasse risate nell’unita di tempo” del visitatore straniero 🙂 🙂
Meglio usare plugin per tradurre manualmente i propri post (ed il proprio blog…) che si desidera rendere disponibili in una o più lingue…
Ad esempio io uso qtranslate, ne ho parlato nel post seguente:
http://leonardomusumeci.net/2008/06/05/qtranslate-il-plugin-definitivo-per-localizzare-wordpress/
Esiste anche la possibilità di realizzare il file robots.txt antispamm o per vietare i motori di ricerca che non ti interessano,
secondo me potresti accettare benissimo solo google data la situazione.
ma anche i file .htaccess antispamm
@angelo: Beh, penso proprio che i bot (non quelli dei motori di ricerca) se ne freghino altamente dei robots.txt!!
Invece come posso usare i .htccess per bloccare un po’ di spambot?
Grazie per questo post, utilissimo, anche io devo accingermi a dare una sistemata per il traffico, i 10gb mensili offerti dal mio hosting cominciano ad andarmi stretti
@Dom93: Prego, sono contento che questo mio articolo ti possa essere utile 🙂
Ciao
Ciao, ho trovato l’articolo molto interessante, solo che non ho capito come far caricare il google.load e non quello dal mio sito?
quale file devo modificare? quale righe devo cambiare?
Grazie e complimenti
Avevo il tuo stesso problema di banda, solo che non avevo nemmeno la metà delle tue conoscenze. Senza saper ne leggere e ne scrivere ho spostato tutto il mio blog (e qualche altro sitarello) da una vps italiana ad un piccolo dedicato italiano. La spesa è rimasta più o meno la stessa, ma prestazione e banda sono, ovviamente volate a livelli ben superiori.
Si è vero in Italia i “piccoli tagli” costano più che all’estero, ma se ci tieni alla latenza, meglio passare ad un dedicato low-cost ed investirci qualcosa sopra piuttosto che rischiare di esser tagliati fuori.
All’epoca della VPS avevo solo 50gb mensili. Ero a rischio di “sforare” un mese si e l’altro pure. Adeso invece mi godo la mia 10mbps ed i 3200gb senza nemmeno pensarci più.
ps. se vuoi il nome dell’attuale provider, mandami una mail.
rivedo solo adesso il mio commento e volevo rispondere al nostro amico dnaX.
Ai ragione che o bot se ne fregano dei file robots.txt ma per correre ai rimedi puoi utilizzare appunto il file .htaccess come indicato.
Basta cercare (antispamm htaccess) su google.
che poi non fai altro che mettere questo genere di istruzione per ogni bot che visita il tuo sito e che vuoi negare.
RewriteCond %{HTTP_REFERER} ^http://www.sitospamm.com$
RewriteRule !^http://[^/.]\.perishablepress.com.* – [F,L]
Vi consiglio anche questo strumento utile che si può integrare sia lato server che lato sito. Blocca lo spamm via url, nei commenti o form, etc.. etc.. etc..
http://www.projecthoneypot.org/httpbl_implementations.php?vid=9eau2b2qhk7k8ug8o1rrfgape2
ciao
@open source cms: Penso sia difficile creare una regola per ogni host. Sono pressoché random.