Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
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
Giu 27 2008

Python può essere considerato il nuovo Basic?

Posted by Antonio Troise
Tweet

Non so voi, ma quando andavo alle scuole superiori, il primo linguaggio di programmazione che ho imparato seriamente, perché lo usavo spesso nei vari esercizi di Sistemi, è stato il Basic. A dire il vero avevo anche iniziato a programmare in Pascal, ma solitamente era usato solamente per imparare i concetti della programmazione, mentre quando dovevo interfacciare un mio programma con qualche progetto elettronico, il Basic era, all’epoca, lo strumento principe (abbinato alla compilazione con Qbasic 4.5). Alla mia professoressa piaceva spesso asserire che lei aveva deciso di farci programmare in Basic, piuttosto che con il potente C o con il complesso e strutturato Java, in quanto, per i nostri scopi didattici, era abbastanza potente e la sua sintassi poteva essere imparata molto velocemente. Se avessimo, invece, dovuto programmare in C, data la sua complessità intrinseca, avremmo dovuto perdere almeno 1 anno affinché tutti lo potessero padroneggiare. Quindi, la scelta, era ricaduta sul pratico e flessibile Basic, perché, dai tempi del Commodore 64, aveva dalla sua la semplicità di programmazione.

Vi ho narrato questi eventi perché recentemente ho letto un interessante articolo che si chiede se il Python potrai mai essere considerato, prima o poi, il degno sostituto del Basic soprattutto nelle scuole: Python is the new BASIC. Secondo l’autore del post è proprio questo giovane linguaggio di programmazione il candidato perfetto, poiché ha una curva di apprendimento gentile, una sintassi facilmente comprensibile e, fattore da non trascurare, la prima frase che ognuno di noi impara a programmare (HELLO WORLD) si scrive, proprio come in Basic, in una sola riga!
Dovete infatti sapere che questo esercizio è per molti il primo impatto alla programmazione, e più semplice risulta essere, e più facilmente ci si avvicina alla comprensione del linguaggio.

Infatti, se in C dovremmo scrivere:

in Java sarebbe:

mentre in Basic è sufficiente scrivere:

e in Python:

Ovviamente il Basic e il Python non sono gli unici linguaggi di programmazione a poter redirigere l’output con una sola riga di comando, ma tra tutti gli altri sono effettivamente tra quelli più potenti e al contempo semplici da imparare.

In realtà, però, Python è anche più potente del Basic, oltre che molto più moderno. Usato da anni da Google e dalla Nasa (e preinstallato in qualsiasi computer con Mac OS X), chi impara a programmare con Python, data la sua scalabilità, può benissimo iniziare semplicemente con un output/input testuale, per poi passare gradualmente ad una programmazione orientata agli oggetti (comunque più semplice e chiara di tanti altri linguaggi), fino ad arrivare ad integrare toolkit GUI come pyglet, pygame, wxPython (non è raro trovare libri che spiegano come programmare i giochi con Python, come “Invent Your Own Computer Games with Python”, distribuito con licenza Creative Commons, che spiega come realizzare giochi in grafica ASCII in meno di 400 righe)

L’autore del post, passa poi in rassegna tutti i più famosi linguaggi di programmazione, dal Visual Basic, PHP, Perl, a Java e Flash, scartandoli tutti per il ruolo di successore del BASIC. Si sofferma però su Ruby, un altro nuovo linguaggio, molto simile a Python e che potrebbe ricadere nella lista dei successori se non fosse che Python ha, almeno per ora, una comunità e una tale vastità di librerie da non essere paragonabile a quella per ora disponibile per Ruby.

Per terminare, vi lascio alla visione di questo simpatico video che mostra la storia del progetto open source Python, dal 1991 quando Guido Van Rossum rilasciò la prima versione del programma ad oggi, riassunto in pochi minuti.


code_swarm – Python from Michael Ogawa on Vimeo.

Il video è stato creato grazie al progetto code_swarm di Federated Media, un software che permette di visualizzare in video tutti i cambiamenti e le modifiche che un software Open Source subisce. Se siete curiosi potete dare una occhiata anche alla storia visuale del famoso webserver Apache.

Tag:basic, java, Javascript, pascal, Php, programmazione, Python, Ruby
CONTINUE READING >
3 comments
Giu 3 2008

Come realizzare siti con interfaccia Touch Friendly per iPod Touch e iPhone con i kit IUI e WebApp.net e analisi sulla mancanza di una versione per iPhone di Wikipedia

Posted by Antonio Troise
Tweet

Touch Friendly La rivoluzione della tecnologia touch di un iPhone o un iPod Touch è tale che, per forza di cosa, è stato necessario coniare un nuovo termine per i siti o gli applicativi dedicati a questa serie di dispostivi mobili: touch friendly, ovvero che sia compatibile col tocco delle dita, tipico della navigazione con i nuovi dispositivi di casa Apple.

Pochi pensano alla versione Touch Friendly del proprio sito

Purtroppo, nonostante esistano versioni mobili di molti siti, in pochi hanno realizzato versioni per iPhone, forse perché ancora considerato, ingiustamente, di nicchia. In realtà, visto che oramai è certo che già entro Giugno 2008 anche nel nostro bel paese approderanno ufficialmente gli iPhone, allora è bene familiarizzare con questi neologismi e iniziare a pensare a come realizzare diversamente i propri siti.
Infatti, se si analizza il traffico Web dei dispositivi mobili, si vede che una fetta consistente è costituito, appunto, da iPhone. E la ragione è una sola: navigare con Safari Mobile è una vera delizia poiché non è necessario alcun adattamento ed è possibile visualizzare la pagina perfettamente come la si vedrebbe con un pc (ad eccezione dei file flash che ancora non sono supportati).

Il problema del dito come dispositivo di puntamento

Finger iPhone Ma dopo questa affermazione allora ci si potrebbe chiedere perché è necessario creare dei siti touch friendly? La ragione è semplice: è facile navigare su qualsiasi sito con un iPhone ma, spesso, visto che la risoluzione nativa dell’iPhone è di 320 x 480 pixel, per visualizzarne correttamente uno o per cliccare su qualche elemento, è necessario zoomare più volte con le dita. Cosa che di per sè è molto semplice ma, a lungo andare può risultare noiosa. Ecco perché il lavoro del webmaster dovrebbe essere rivolto ad adattare il proprio sito anche a questi evoluti dispositivi che, secondo me, presto invaderanno il mercato del mobile.

iPhone Site Specs

Lo screen dell’ iPhone visualizza infatti 160 pixels ogni pollice, e per utilizzarlo si usano le dita. Il problema è che, il dispositivo di puntamento di un iPhone/iPod non è un cursore o la freccetta del mouse, bensì esclusivamente le nostre dita! Se, quindi, si preme in un punto del display, lo spazio premuto sarà compreso tra i 40 e gli 80 pixels. Quindi, la prima regola base nella costruzione di un sito Touch Friendly è quello di distanziare due elementi selezionabili di almeno di 40 pixel, altrimenti l’utente che visiterà il portale tramite iPhone difficilmente riuscirà ad effettuare una selezione senza zoomare più volte. Per questo è sempre bene ingrandire i font e gli elementi della pagina, magari raddoppiandone le dimensioni; ad esempio, se si ha impostata la dimensione di un font a 18px, buona idea sarebbe portarlo a 32px.

iPhone Site Specs

Una delle caratteristiche più particolari dell’ iPhone è il supporto nativo alla “viewport“, ovvero quella funzione che permette di visualizzare solo uno spezzone alla volta di sito. Questo perchè le pagine web sono adattate alle dimensioni degli schermi da PC, mentre lo schermo dell’ iPhone è di dimensioni ben minori.
Per evitare, quindi, caratteri microscopici e selezioni impossibili, si è ricorso a questo stratagemma. Di default, aprendo una pagina web, la viewport è impostata per mostrare un riquadro del sito delle dimensioni di 980-pixel.

I kit IUI e WebApp.net per realizzare siti Touch Friendly

Webapp.net Se non volete impazzire col codice, allora vi consiglio di usare alcuni framework javascript per realizzare in pochi minuti un sito iPhone Style. Il primo a nascere fu IUI: User Interface (UI) Library for Safari development on iPhone, un progetto davvero interessante giunto alla release 0.13 ma che, dalle prove che ho fatto, è mancante di molti elementi di una pagina web.
Ho trovato, invece, molto interessante il fork di quest’ultimo progetto: WebApp.net. L’ho trovato molto più completo del primo e ho già realizzato un paio di siti in questo modo e devo dire che, nonostante qualche differenza sintattica rispetto ad IUI, e una volta presa la mano, è davvero semplice realizzare un sito Touch Friendly con WebApp.net, anche grazie al set grafico fornito di serie. Giunto alla versione 0.2.0 qui trovate una demo della sue potenzialità e qua sotto un video che illustra cosa è possibile fare con questo kit:

Qui, invece, trovate tutta la documentazione per iniziare (è ancora in fase di scrittura)

ATTENZIONE: Ovviamente su Explorer non è possibile visualizzare correttamente questo genere di siti, ma potete visualizzarli correttamente con Safari, Firefox e Camino.

I siti Touch Friendly e la mancanza di Wikipedia

Touch Friendly Meebo Già esistono numerosi plugin per WordPress allo scopo, Meebo e Mundu, due servizi di messaggistica istantanea via web, hanno già pensato di creare una versione adatta allo scopo, ed è già è stata creato un client web per Twitter, Hahlo, Google Reader, ma Wikipedia, nonostante le dimensioni di questa comunità non ha ancora pensato a sviluppare una versione per iPhone.

Fin’ora si era solo pensato ad installare wikipedia sull’iPhone/iPod Touch per dare la possibilità a tutti di consultare l’opera offline senza necessariamente esser connessi ad internet. Il trucco stava nell’usare il programma Wiki2Touch e Scaricare il database di wikipedia in italiano da questa pagina (il dump è grande circa 2 Gb). Seguendo questa procedura è molto semplice, in pochi minuti, installare l’intera enciclopedia sui nostri dispositivi mobili.

Ma se noi volessimo semplicemente navigare su Wikipedia online con una interfaccia touch friendly? Allora dovremmo rivolgerci ad un prodotto di terze parti: iPodia. iPodia, infatti, grazie alla tecnologia Picklr Engine, rende l’enciclopedia Wikipedia ottimizzata per i dispositivi avanzati della Mela. In pochi tap di dito potrete selezionare la lingua e scrivere la parola da ricercare. Le pagine si adattano perfettamente al formato dello schermo e basta spostare il dito dall’alto verso il basso per leggerne il contenuto.

Tag:Css, firefox, iPhone, iPod, ipod-touch, Javascript, Plugin, safari, touch friendly, Wordpress
CONTINUE READING >
1 comment
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 29 2008

Perché spesso le guide html non dicono che l’attributo TARGET per aprire nuove finestre non è HTML Strict? Tre soluzioni per avere lo stesso effetto senza invalidare il codice e avere un sito accessibile

Posted by Antonio Troise
Tweet

Quando ho iniziato a programmare, il tag A (per la definizione di link ipertestuali) supportava pienamente l’attributo TARGET per aprire in una nuova finestra un sito web magari esterno al proprio, con lo scopo (illusorio) di non perdere visitatori. Ricordo ancora, quando farcivo le mie pagine html con formule tipo:


Link esterno

e magicamente, a mo’ di popup, si apriva un’altra finestra del browser (all’epoca ancora non esisteva il concetto navigazione a schede o tab).

Da qualche anno, però, l’attributo TARGET del tag A è stato completamente abolito dalle specifiche Strict dell’HTML per la realizzazione di un sito accessibile. Il motivo è ben chiaro a tutti: solo l’utente dovrebbe decidere se aprire o no un link in una nuova finestra (ad esempio tenendo premuto Shift) e non dovrebbe essere obbligato a subire le scelte del webmaster di turno: il rischio, infatti, è quello di trovarsi lo schermo invaso da finestre flottanti o, se usate Firefox ben configurato, decine di tab aperte! Inoltre aprendo una nuova finestra si pregiudica l’utilizzo del tasto “Indietro” che è il tasto di navigazione più utilizzato.

Una informazione spesso omessa nelle guide html

Purtroppo non tutti lo sanno e in molti corsi html sparsi per la rete, questo fatto viene ancora ignorato o comunque non messo bene in evidenza (provate a cercare su google ‘corso html‘ e vedrete che i primi risultati portano a dei corsi che non accennano a questa nuova regola).

Addirittura, ho trovato un riferimento spensierato all’attributo TARGET sulla pagine delle FAQ del Centro assistenza clienti AdSense, quando spiega come creare un link ipertestuale:

Utilizza target=”_top”: questo codice dice al browser quale finestra utilizzare per il caricamento della pagina di destinazione dell’immagine cliccabile. Se non includi nel codice questo tag (il punto in cui inserirlo è descritto più avanti), il browser tenterà il caricamento della pagina di destinazione all’interno del formato degli annunci.

Non che il concetto di TARGET sia errato ma essendo oramai obsoleto e deprecato, questa omissione può portare molta gente, che decidendo oggi di imparare il linguaggio html, apprende un concetto errato e quando si dovrà a dover validare il codice, si troverà dinanzi ad un attributo target che inspiegabilmente non passa il check. Sarebbe stato auspicabile almeno un cenno a questo fatto, per evitare di commettere errori all’inizio della propria carriera di programmatori web.

Dove trovare informazioni sulle specifiche HTML Strict

Basterà, però andare, per esempio, su w3schools e notare che, nella tabella riepilogativa, l’attributo TARGET (il cui valore può essere _blank, _parent, _self, _top) non è non previsto nelle DTD Strict, ma è previsto solo nella DTD Transitional.

Una ulteriore conferma, basta andare a leggere il regolamento attuativo della L. 4/20041 (“Decreto Ministeriale 8 luglio 2005—Requisiti tecnici e i diversi livelli per l’accessibilità agli strumenti informatici. Allegato A”) e si noterà che nell’elenco dei requisiti di accessibilità per i siti Internet, al primo punto, compare la voce:

  • per tutti i siti di nuova realizzazione utilizzare almeno la versione 4.01 dell’HTML o preferibilmente la versione 1.0 dell’XHTML, in ogni caso con DTD (Document Type Definition – Definizione del Tipo di Documento) di tipo Strict;
  • per i siti esistenti, in sede di prima applicazione, nel caso in cui non sia possibile ottemperare al punto a) è consentito utilizzare la versione dei linguaggi sopra indicati con DTD Transitional, ma con le seguenti avvertenze:
    1. evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi ed attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;
    2. evitare la generazione di nuove finestre; ove ciò non fosse possibile, avvisare esplicitamente l’utente del cambiamento del focus;
    3. pianificare la transizione dell’intero sito alla versione con DTD Strict del linguaggio utilizzato […]

Come si vede, quindi, in ogni caso, sia che il sito è esistente da anni o di nuova realizzazione, la generazione di nuove finestre andrebbe evitata, a meno che non si avvisi esplicitamente l’utente del cambiamento del focus!
Tra le altre cose da evitare per avere un sito accessibile vi sono: i frame e le scritte lampeggianti. Tutte cose che spopolavano anni fa nei primi siti web che comparivano su internet e che, tutt’oggi, le guide html ancora raccontano omettendo che sono deprecate per avere un sito accessibile.

Prima soluzione

Quindi, se l’apertura incondizionata di nuove finestre o di “popup” è deprecata e da evitare, se proprio non se ne vuole fare a meno, allora è necessario avvisare l’utente che si aprirà una nuova finestra.
Per adottare questa tecnica, bisogna, però, è necessario ricorrere a Javascript, sfruttando comandi come window.open() e all’evento onclick, da associare all’attivazione del link, evitando, comunque, di generare elementi o attributi non consentiti.

Qui ho trovato un semplice esempio di come utilizzare un accorgimento particolare che sfrutta javascript senza però andare ad invalidare il codice e soprattutto avvisando l’utente del cambiamento di focus:

E’ ovvio che, questo genere di soluzioni, andrebbero usate solo laddove non se ne può fare a meno, come, per esempio, la generazione di una pagina stampabile.

Seconda soluzione

Un’altra alternativa, la propone Ecologia dei siti web, che, nel tentativo di rispettare la legge L. 4/2004 (come pure le WCAG) che, indica, giustamente, di non vincolare l’utente all’uso di uno specifico dispositivo di input, consiglia di usare l’evento onclick sempre assieme all’evento onkeypress controllando che il tasto premuto corrisponda al tasto ENTER.

Ecco la sua soluzione:

Mentre i collegamenti da aprire in una nuova finestra sono identificati semplicemente tramite l’associazione alla classe blank:

Terza soluzione

Per finire non mi resta che citare un’ultima interessante alternativa tutta italiana: si chiama Wi.Li. (Windowed Links) ed è opera di Diego La Monica che l’ha realizzata partendo da un’idea di Carlo Filippo Follis.

Wi.Li. è uno script che ha il compito di eseguire una scansione di tutti i link sulla pagina in cui è inserito verificandone la destinazione. Nel momento in cui un utente effettua un click su un collegamento, Wi.Li. adotta un comportamento differente in base alla decisione dell’utente che può essere: aprire la pagina in una nuova finestra oppure rimanere nella stessa finestra di navigazione.

Il vantaggio di Wi.Li., quindi, è quello di poter integrare nel proprio sito “finestre popup discrezionali” accessibili, senza dover intervenire manualmente sul codice HTML che rimane validato.

Dagli esempi, si evince il suo funzionamento che, per quanto intuitivo, non rispetta comunque una delle direttive del regolamento attuativo della L. 4/20041, ovvero quella relativa all’avviso esplicito all’utente del cambiamento del focus.

Tag:Css, html, html_validators, Javascript
CONTINUE READING >
4 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
Ago 19 2007

Eloquent JavaScript: corso interattivo di Javascript

Posted by Antonio Troise
Tweet

Il linguaggio di programmazione Javascript è tornato a nuova vita dopo l’avvento di Ajax; è per questo che è opportuno conoscerlo approfonditamente per poter sviluppare bene le proprie applicazioni web 2.0.

In questo ci viene in aiuto Eloquent JavaScript, segnalato da Daniele, un’interessante guida su Javascript pubblicata da Marijn Haverbeke che ha il pregio, se visualizzata su un brower, di essere interattiva.

Infatti, per ogni esempio visualizzato è possibile (cliccando su un tasto al lato della pagina) eseguirlo direttamente o modificarne il codice sorgente su un comoda console che mostra l’output del codice js modificato, un editor con syntax highlighting e un comodo debugger javascript incorporato.

Inoltre, a complemento di ogni capitolo, sono presenti degli esercizi, con le relative soluzioni nascoste.

Oltre alla versione online sono disponibili la versione offline e quella da stampare.

Tag:Ajax, Javascript, Web 2.0
CONTINUE READING >
0 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 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