Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
Feb 2 2011

E’ arrivato jQuery 1.5

Posted by Antonio Troise
Tweet

IL 31 Gennaio 2010 è stato finalmente annunciato il rilascio della release stabile di jQuery 1.5. La novità più grande è sicuramente che questa nuova versione beneficerà complessivamente di performance migliori, grazie alla parziale riscrittura del codice relativo alle chiamate Ajax, e ad un netto miglioramento riguardo il traversing, ovvero quelle funzioni che permettono di scorrere gli elementi all’interno della pagina (come, per esempio, i metodi .children(), .prev() e .next()).

Oltre ad essere state aggiornate, le API Documentation per jQuery 1.5, questa nuova versione ha corretto 83 bug, chiuso 460 ticket, e ha passato ben 4437 test su tutti i browser che prevedono la compatibilità con jQuery (compreso l’odiato e vecchio Internet Explorer 6):

  • Safari 5.0.3 / 4.0.5 / 3.2.3 / 3.1.2
  • Opera 11.01 / 11 / 10.63 / 10.54 / 10.10 / 9.64
  • IE 6 / 7 / 8
  • Firefox 4.0b9 / 3.6.13 / 3.5.11 / 3.0.19 / 2.0.0.20
  • Chrome 8.0.552.215 / 8.0.552.237 / 9.0.597.67 Beta / 10.0.642.2 Dev

Se volete, quindi, beneficiare delle nuove performance, potete scaricare la nuova versione qui:

  • jQuery Minified (29kb Gzipped)
  • jQuery Regular (207kb)

oppure potete linkarli direttamente dai server CDN di Google e Microsoft:

  • Microsoft CDN
    http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.min.js
  • Google CDN
    https://ajax.googleapis.com/ajax/libs/jquery/1.5.0/jquery.min.js
Tag:Ajax, jquery
CONTINUE READING >
1 comment
Ott 14 2008

Come seguire la diretta del Keynote Apple con Site Reloader e lista di tutti i siti che seguono l’evento in live blogging

Posted by Antonio Troise
Tweet

Se non potete fare a meno di seguire il Keynote Apple di oggi martedi 14 Ottobre 2008 presso il Town Hall di San Francisco, bombardati dalle decine di rumors e segnalazioni fotografiche di presunti nuovi modelli di Macbook, Macbook Pro e Apple Cinema, allora sicuramente, alle 19:00 di questa sera, sarete tra quelli che resteranno davanti al PC, pronti a cliccare sul tasto refresh del vostro browser. Se volete evitare questa noiosa procedura, laddove i vostri siti preferiti non supportino l’auto-refresh delle pagine che seguono il live dell’Apple Event, allora non potrete di certo fare a meno di Site Reloader (sito simile ma più evoluto di Page Reboot, comunque valido se non si hanno particolari esigenze), una utility web che ci permette di aggiornare una o più pagine web caricate attraverso delle finestre popup, con un intervallo di tempo del reload che va da 5 secondi a 30 minuti (di default è impostato un tempo ragionevole, anche per il live blogging di questa sera, di 30 secondi).

Come funziona Site Reloader

La procedura è molto semplice: andiamo sul sito, inseriamo l’indirizzo del sito a cui siamo interessati e clicchiamo su Add. Quindi, verrà aggiornata in ajax una lista presente sotto il textbox, con l’elenco di tutte le url inserite e il relativo tempo di reload modificabile a piacere. E’ possibile anche eliminare un sito, cliccando sull’icona rossa con la X, e automaticamente verrà chiusa anche la finestra popup relativa. Oppure, molto più semplicemente, chiudere la finestra popup di un sito e, automaticamente, verrà eliminata anche la riga nella lista dei siti di Site Reloader.

Site Reloader

A differenza di altre applicazioni web simili, questo sito sfrutta le Google App Engine e, per poter salvare la lista dei siti da monitorare, occorre loggarsi con un account Google (lo stesso che usate per la vostra Gmail o per uno delle decine di servizi messi a disposizione dal motore di ricerca).

Inoltre, sempre solamente per gli utenti che effettuano il login e che hanno, quindi, potuto salvare la lista dei siti da monitorare, è presente anche la funzione di autocaricamento dei siti salvati sulla nostra lista, appena si aprirà la pagina di Site Reloader. Unica nota: per funzionare correttamente, Site Reloader necessita della disabilitazione (o dell’abilitazioni delle eccezioni) dell’eventuale Popup Blocker presente oramai di default su qualsiasi browser.
In definitiva, Site Reloader è indubbiamente un servizio molto utile per seguire cronache di eventi in diretta.

La lista dei siti che seguono il Keynote Apple

Per finire, ecco una lista di siti, che potrete inserire su Site Reloader, che questa sera, verso le ore 19:00 ora italiana (ore 10 am ora locale) effettueranno il live blogging dell’evento Apple:

  • Engadget (live)
  • Crunchgear (qui il live con le pagine che effettuano il refresh automatico)
  • MacRumorsLive
  • MacWorld (live)
  • Gizmodo
  • The Apple Lounge Live Twitter
  • Melablog
Vantaggi e svantaggi

Il vantaggio di usare servizi web online (piuttosto che applicazioni standalone come plugin per Firefox come ReloadEvery) è, indubbiamente, oltre ad essere indipendenti dalla piattaforma e dai browser usati, anche quello di avere la lista dei siti da monitorare ovunque si sia. Lo svantaggio è che, come spesso accade in eventi mondiali che riscuotono un notevole successo mediatico che, in termini pratici, corrisponde ad un numero elevato di visitatori, è possibile che siti come Site Reloader possano andare offline, come accaduto durante il Keynote Apple del 15 Gennaio 2008 in cui servizi online come Twitter e CoverITLive non hano retto l’intenso traffico che da tutto il mondo transitava sui loro servers, venendo meno l’interessante diretta che stavano realizzando.

Non credo questo possa essere il caso di Site Reloader, nel qual caso dovremmo ricorrere al vecchio metodo del refresh manuale delle pagine internet, oppure, molto più semplicemente, collegandosi ad evento finito bypassando le spasmodiche cronache del Keynote Apple!

Tag:Ajax, Apple, browser, firefox, Google, keynote, liveblogging, macbook
CONTINUE READING >
0 comments
Ago 4 2008

La moda del Coverflow: alla ricerca di una soluzione web completa che preveda anche lo scroll delle immagini con la rotellina del mouse

Posted by Antonio Troise
Tweet

Da quando su iTunes e, in seguito, sui vari iPod Touch, iPhone e Mac OS X, è comparsa la funzionalità di CoverFlow, tutti cercano di emularla sui propri siti web. Ed è per questo che sono nate tantissime soluzioni che permettono di replicare l’accattivante interfaccia grafica che permette di sfogliare fluidamente le immagini.
Purtroppo, una delle grandi pecche di molte di queste librerie è di non permettere, per quanto comunque ben fatte, lo scrolling orizzontale delle immagini con le rotellina del mouse. Trovo, infatti, che quest’ultimo metodo risulta essere la migliore esperienza possibile di CoverFlow e tutte le soluzioni, per quanto accattivanti, che non lo prevedono, secondo il mio parere, sono solo parziali. E così, tra queste, troviamo il plugin per Rapidweaver, coverFlow, oppure molte soluzioni in Flash ben descritte sul sito di Julius Design.

Coverflow Quindi, in questo post, vorrei elencare tutte quelle soluzioni che prevedono anche l’uso della rotellina del mouse per scorrere fluidamente le immagini. Starà poi al lettore scegliere la migliore secondo i propri gusti ed esigenze.
In questo elenco troviamo quindi:

  • Protoflow, una libreria che utilizza Prototype.js e Script.aculo.us per mostrare cover di immagini con effetto Coverflow e che si avvale anche dello script Reflection.js per creare gli elementi canvas che rappresentano le immagini riflesse.
  • ImageFlow (demo), di cui esiste anche u plugin per WordPress, che si integra con NextGEN Gallery, che risulta molto utile per integrare coverflow nei propri post.
  • SlideFlow (demo)
Coverflow nei motori di ricerca

Ma l’effetto CoverFlow è stato anche molto sfruttato nei motori di ricerca. Infatti, con CreativeSpace è possibile navigare, tutto in Ajax, in modalità Coverflow attraverso i risultati restituiti dalle ricerche su Google Images.
Mentre con Searchme è possibile sfogliare, sempre in coverflow, i risultati delle ricerche con l’anteprima delle pagine, rendendo di fatto più semplice la scelta del risultato. Peccato che il database di Searchme non è nulla in confronto allo sterminato db di Google, e, spesso, accade di non riuscire a trovare ciò che si cerca!

Coverflow su Windows Mobile

Per finire, la moda del CoverFlow, oltre al web, attira anche altre piattaforme, come quella mobile che, dopo aver sfornato decine di cloni dell’iPhone, tenta di integrare questo effetto grafico anche sugli smartphone già esistenti con Windows Mobile, grazie al plugin Face Contact.

Face Contact per Windows Mobile
Tag:Ajax, coverflow, Javascript, Plugin, prototype, Search Engine, windows-mobile, Wordpress
CONTINUE READING >
1 comment
Lug 23 2008

Come abilitare lo scrolling infinito della homepage del proprio blog su WordPress caricando dinamicamente gli articoli

Posted by Antonio Troise
Tweet

Ecco un nuovo plugin per WordPress che permette di rendere l’homepage del proprio blog virtualmente infinita: Infinite Scroll.

Questo plugin sfrutta il concetto di pageless pagination (letteralmente, paginazione senza pagine), avvistata per la prima volta sul sito di Google Reader e che permetteva di caricare dinamicamente, in presenza di una lunga lista di item non letti, le informazioni mano a mano che si proseguiva nella lettura; da quel momento, poi, questa tecnica ha iniziato ad essere inclusa silenziosamente (come ogni cosa che semplifica le operatività maggiore è suo grado di trasparenza e immediatezza e maggiore è il suo successo) nelle varie applicazioni del web 2.0 fino ad arrivare, finalmente, grazie al contributo di infinite-scroll.com, anche sui nostri blog con piattaforma WordPress.

Caricamento dinamico degli articoli

Sino ad ora, a sfruttare le caratteristiche ajax, erano solo plugin quei che permettavano di passare da una pagina all’altra di un blog senza ricaricare l’intero sito. Ma ora, finalmente, siamo giunti alla piena usabilità, grazie ad un plugin che richiede pochissime conoscenze per il suo corretto funzionamento.
Il contenuto della propria homepage, infatti, viene normalmente caricato col normale numero di articoli impostabili dal Pannello di Amministrazione di WordPress (Gestione -> Lettura) ma, quando si arriva in prossimità dell’ultimo post in fondo alla pagina, vengono caricati un altrettanto numero di articoli e così via fino ad arrivare, con un po’ di pazienza, alla fine degli post scritti.

Il sistema è davvero semplice e al contempo geniale perché permette, soprattutto ai nuovi visitatori che vogliono avere una rapida panoramica di quello che viene scritto in un blog, di scorrere rapidamente i vari articoli, che vengono svelati mano a mano che si scorre la pagina verso il fondo, senza dover aspettare che la pagina si ricarichi nuovamente cliccando sul classico link di navigazione “Pagina Successiva”. E’ facile immaginare che questa sorta di scrolling infinito della pagina, permette di far conoscere un maggior numero di articoli ai nuovi visitatori perché, si sa, un po’ come accade nei motori di ricerca, è difficile andare oltre la seconda o terza pagina di navigazione!

Installazione
  1. Scaricare il plugin
  2. Dopo averlo scompattato il pacchetto zip, installare il contenuto nella directory dei plugin di WordPress (/wp-content/plugins/)
  3. Attivare il plugin
  4. Nella pagina Impostazioni/Infinite Scroll occorre settare alcuni selettori css (Content CSS Selector, Post CSS Selector, Navigation links CSS Selector, Previous Posts CSS Selector) che si trovano nel proprio template (nel file index.php del tema installato). L’autore garantisce che, per la maggior parte dei temi, il plugin dovrebbe funzionare senza alcuna modifica e con i selettori di default. Personalmente sul mio sito ho dovuto personalizzare i selettori css relativi alla barra di navigazione (div.navigation_bottom e div.navigation_bottom a:first) dove si installa l’ajax loader che visualizza il caricamento in corso degli articoli (e che sostituisce i link Pagina Successiva e Pagina Precedente)
  5. Di default il plugin funziona solo se si è loggati come utente Administrator ed è disabilitato a tutti gli altri utenti o a chi non è loggato. Lo scopo è permettere la corretta messa a punto del plugin senza disservizi. Terminata la fase di configurazione, nella pagina Impostazioni/Infinite Scroll è possibile abilitare a tutti la funzionalità di scrolling dinamico.
Impressioni

Devo dire che rispetto al Live Scrolling di Google Reader, il sistema mi sembra meno reattivo, nel senso che mentre nel primo caso neanche ci si accorge del caricamento dei nuovi item, con questo plugin occorre arrivare all’ultimo post per iniziare il caricamento dei successivi (secondo me dovrebbe iniziare almeno a due o tre articoli dalla fine) e attendere qualche secondo. Credo, però, che ciò in parte sia da imputarsi alla ovvia differenza prestazionale di un server come quello di Google rispetto a quello usato da me; inoltre queste differenze si notano soprattutto perché scorrevo la pagina con la rotellina del mouse senza leggere, ma in condizioni normali, un visitatore darebbe una occhiata agli articoli e quindi, forse, neanche si accorgerebbe del caricamento.
In teoria è possibile anche impostare un basso numero di articoli visualizzabili in homepage (2 o 3 al massimo) perché i successivi verrebbero caricati dinamicamente mentre si scorre la pagina.

Bug

Ho incontrato una non perfetta compatibilità con il plugin SyntaxHighlighter, in quanto non riesco a visualizzare correttamente il codice incluso negli articoli caricati dinamicamente. Ho intenzione di contattare l’autore del plugin per metterlo a conoscenza di questa problematica.

In conclusione

Non so quanto questo plugin possa incidere a livello prestazionale e di banda occupata ma non credo che possa apportare grossi problemi, a tutto vantaggio di una navigazione più veloce e fluida.
Se volete vedere il plugin in azione, andate nella homepage di Levysoft e scorrete la pagina verso il basso.

Tag:Ajax, Blog, Css, Javascript, Php, Plugin, template, Web 2.0, Wordpress
CONTINUE READING >
14 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
Tweet

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

Google AJAX Libraries API

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!

Prototype self hostes

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
CONTINUE READING >
17 comments
Mag 19 2008

Google Translate ora è più completo

Posted by Antonio Troise
Tweet

Non so quanti di voi hanno mai avuto la necessità di tradurre in italiano con Google Translate un sito scritto in una lingua che non fosse l’inglese: fino a qualche tempo fa non era possibile e tutte le traduzioni dovevano essere ricondotte prima alla lingua inglese e, poi, eventualmente si poteva ritradurre il tutto dall’inglese all’italiano. Non c’è bisogno che vi dica che il risultato era sempre scadente poiché le informazioni contenute si degradavano: il principio, infatti è quello, discusso più volte su questo sito, dell’entropia delle traduzioni (altri spunti di riflessione li trovate anche qui e qui).

Ebbene, finalmente, Google Translate, il servizio di Google che permette di tradurre parole o intere porzioni di testo da una lingua all’altra, oltre ad avere aggiunto altre dieci nuove lingue ( per cui gli idiomi disponibili diventano 23), è possibile tradurre da una qualsiasi delle 23 lingue in un’altra, con tutte le combinazioni possibili, divenendo di fatto il traduttore online gratuito più completo. Così ora, se vi va, sarà possibile tradurre un testo italiano in cinese, e uno norvegese in croato!

Infatti le lingue disponibili per le traduzioni sono: Inglese, Arabico, Bulgaro, Cinese, Croato, Ceco, Danese, Tedesco, Finlandese, Francia, Olandese, Greco, Hindi, Italiano, Giapponese, Coreano, Norvegese, Polacco, Portoghese, Rumeno, Russo, Spagnolo, Svedese.

Cosa non da poco per tutti i programmatori, è l’introduzione delle nuove Google AJAX Translation API, con cui sarà possibile interfacciare le nostre applicazioni web 2.0 con il servizio di traduzione di Google.
Se volete approfondire l’argomento, vi consiglio di leggere, oltre che la Developer’s Guide di Google con i relativi esempi esplicativi, anche questa interessante guida: Google AJAX Language API: tutorial sul funzionamento.

Infine, nel caso non sappiate che lingua avete davanti, Google ha aggiunto anche una funzione, chiamata “detect language”, in grado di “capire” in automatico, incollata una porzione di testo, di che lingua si tratti.

Tag:Ajax, entropia, Google, google_translate, Internet, Web 2.0
CONTINUE READING >
10 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
Tweet

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.

Wordpress Content-Encoding Gzip
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).

Tag:Ajax, banda, bandwidth, browser, compressione, cpanel, gzip, Javascript, Php, prototype, Web 2.0, Wordpress, wordpress 2.5
CONTINUE READING >
12 comments
Gen 21 2008

La sconfitta dei servizi web 2.0 come Twitter e CoverItLive per il live blogging. Racconto di come il Keynote ha mandato in crash la blogosfera

Posted by Antonio Troise
Tweet

Se vi annoverate tra gli appassionati di tecnologia, sicuramente non avrete potuto fare a meno di notare il riflesso mediatico che il Keynote del 15 Gennaio 2008 ha avuto sulla blogosfera e sui quotidiani di tutto il mondo. Che siate appassionati o meno dei prodotti della mela, sicuramente un occhio sul loro sito o su qualche articolo relativo all’evento lo avete buttato, anche solo per capire fino a che punto si fosse spinta la tecnologia.
Ebbene, in questa tempesta mediatica, di rumors e di commenti, in molti hanno organizzato dei live blogging per dare notizia in tempo reale su quello che si dicevano al Macworld Expo di San Francisco. I veri vincitori della diretta sono stati i tradizionalisti (come Engadget o il nostrano Melablog), che hanno optato per un aggiornamento live sulle pagine del proprio blog, creando una pagina apposita che veniva aggiornata ogni pochi minuti con immagini e testi.
Altri, invece, hanno tentato audacemente la strada dell’innovazione ma per farlo si sono dovuti appoggiare su servizi esterni web 2.0 come Twitter e CoverITLive che, per quanto siano gratuiti e diffusi, hanno tradito le loro aspettative.

Twitter Error
Il caso CoverItLive

Molti siti famosi si sono appoggiati su CoverItLive, come nel caso dell’italiano TheAppleLounge, che ha voluto testare sul campo CoverItLive, il nuovissimo servizio per fare blogging di event in tempo reale (liveblogging appunto), nato con lo scopo di eliminare servizi adattati per l’occasione come Twitter o gli update multipli di un post su un blog, quando si voglia raccontare di eventi, convegni, BarCamp, partite, seminari e, perché no, anche Keynote! L’indubbio vantaggio è quello di non allontanare i nostri lettori dalla pagina del nostro blog ma nemmeno costringerli a fare refresh della pagina di continuo per vedere se abbiamo inserito qualche aggiornamento, mostrando una finestra di liveblogging stile IM (ma senza pubblicità) in cui è possibile inserire anche audio, presentazioni, video e immagini

Purtroppo, forse perché ancora troppo giovane, CoverItLive non ha retto l’intenso traffico che da tutto il mondo transitava sui loro servers ed è venuta meno l’interessante diretta che stavano realizzando.

Altri blogger più o meno famosi hanno scelto la piattaforma CoverItLive non pensando minimamente che potesse essere così instabile: è il caso di GeekBrief.tv che ha rivisto funzionare il servizio solo al termine del Keynote! Lo stesso è accaduto a CrunchGear che verso le 10.00, dopo oltre mezz’ora di fermo, consigliava:

if you’re visiting here, hit crunchgear.com/index.html to view the live text

Sono stati talmente tanti blogger che si erano affidati a CoverItLive, che il suo presidente Keith McSpurren, il giorno dopo ha inviato una missiva di pubbliche scuse:

We would like to apologize to all of our users and their readers for the service outage that happened mid-day on January 15. CoveritLive was specifically designed to handle small and very VERY large live blog events like the Steve Jobs Keynote at MacWorld. Our issue appears to have been a very minor technical one on our end that was amplified dramatically by the extremely heavy traffic from around the world as many new users and hundreds of thousands of first time readers visited our customers who were hosting live blogs. We do not need to make any structural changes to handle this type of load in the future but we do need to make sure our Quality Assurance process is tighter. This was a case of one loose screw taking us down.
We very much appreciate your patience and understand any frustration you experienced. To our new users, we hope you see the benefit in our software and will give it another try. To our existing users, most of you have given us great feedback in the past and we have been very responsive. Please stick with us and have faith that we will adjust quickly to stop this kind of thing happening again.

Il caso Twitter

Altri, invece, hanno provato ad usare la famosa e oramai consolidata piattaforma di microblogging, Twitter. Anche se questo servizio non è nato per effettuare un live blogging è facile poterlo adattare a tale scopo in quanto permette un aggiornamento reale a tutti i propri iscritti. Ma, nonostante, però, questo servizio permetta solo il semplice inserimento di testo (niente immagini e video che potrebbero appesantire i server) durante tutta la durata del keynote Twitter è rimasto completamente inutilizzabile e dal team di sviluppo non è trapelata alcuna informazione circa l’origine del problema, che comunque sembrava ovvia!

Twitter Fail

Infatti, se provate a vedere la sezione di Twitter di Macworld, alle 08:56 AM compare un gioioso:

Hello from Moscone West

e, dopo più di un’ora, alle ore 10.07 compare un laconico ed ultimo messaggio:

Apple has crashed Twitter, I think

La stessa cosa si evince da un messaggio del live blogging su Twitter di Ars Technica alle 11.43 (ma credo che ci sia un fuso orario di +1 ora):

Sorry guys hard to keep up here

Anche il famoso Fake Steve Jobs è stato coinvolto dal down di Twitter:

twitter is BROKEN!

La notizia del fallimento di Twitter è riportata anche da TechCrunch con il titolo: “Twitter Fails Macworld Keynote Test“.

Il crash della blogosfera e possibili alternative

E’ forse un po’ catastrofico come titolo, ma da quanto leggo su webware, ci è mancato davvero poco. Infatti, dopo il down di servizi come Twitter e CoverItLive sui cui anche i più famosi blog facevano affidamento anche per ridurre la banda di uso, molti siti sono andati offline perché non riuscivano a sopportare le continue richieste dei proprio lettori che, in media, ogni 5 secondi aggiornavano le pagine dei blog che erano costretti a fare il live blogging del Keynote sulle pagine del proprio sito. E’ il caso, per esempio, di Engadget,

Engadget

mentre Gizmodo è rimasto online ma era estremamente lento. Su MacDailyNews, invece, nel suo Live Coverage, si supplicava di:

Please DO NOT RELOAD this page manually to minimize server activity due to expected high traffic. Thank you

Diversa sorte è capitata, invece a MacRumors, che, forse più intelligentemente, ha approntato per l’occasione un sito live, Macrumorslive.com, che si aggiornava automaticamente con le tecniche Ajax (e quindi risultava molto più leggera). Sarà forse questo il futuro?

Oppure forse sarà il caso, come dice qualcuno, di trasformare i social network centralizzati in una più naturale rete di social network P2P, decentralizzati e, magari, fondati sul trust: in pratica si tratterebbe di creare un sistema ad eventi basato sul web e decentralizzato in cui Twitter sarebbe semplicemente uno dei tanti servizi presenti su questa infrastruttura.

In ogni caso, forse sarà il caso di cambiare qualcosa nelle regole della blogosfera e forse gli eventi passati possono far riflettere sulla debolezza di internet in occasione di eventi ad interesse mondiale.

Tag:Ajax, Apple, blog-power, keynote, liveblogging, macworld, microblogging, twitter, Web 2.0
CONTINUE READING >
2 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
Tweet

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.

Prototype Ajax

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
CONTINUE READING >
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
Tweet

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.

Banda Dicembre 2007

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

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.

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.

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.

Gzip WordPress

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.

Tag:Ajax, bandwidth, browser, Css, Javascript, Php, Plugin, prototype, Wordpress
CONTINUE READING >
26 comments
SeguiPrezzi - Risparmia con Amazon.it

Categorie

Commenti Recenti

  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Fioredicollina on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Emanuele on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Luca on iDatabase: la valida alternativa di Bento per macOS e iOS per i database personali
1 2 3 NEXT

Meta

  • Accedi
  • Entries RSS
  • Comments RSS
  • WordPress.org

Friends Link

  • GamerTagMatch
  • SeguiPrezzi.it – Risparmia con Amazon.it
  • Trendy Nail

Seguimi su:

  • facebook
  • twitter
  • rss
Creative Commons License
Levysoft by Antonio Troise is licensed under a Creative Commons Attribuzione-Non commerciale 2.5 Italia License.
© Copyright 2004 - 2014 - Levysoft by Antonio Troise