L’installazione di Granola è totalmente trasparente e dal primo avvio il nostro Pc sarà già configurato per iniziare a risparmiare energia. Andando nelle Power Options di Windows torveremo un nuovo profilo configurato e dalla mia esperienza sui Pc miei e di amici non è stato necessario alterare alcun valore. Il Pc rimane performante e non ho riscontrato alcun effetto collaterale.

Nella Systray troveremo l’icona di Granola che consentirà di visualizzare la semplice interfaccia che ci mostra i KWh risparmiati, gli Euro risparmiati, gli alberi compensati e il risparmio di CO2.

Il funzionamento di Granola si basa su un semplice algoritmo che monitora l’utilizzo del CPU e permette di modificarne la velocità per risparmiare ed ottimizzare performance e affidabilità. Praticamente quando la CPU non è molto utilizzata ne abbassa il clock per evitare di avere l’assorbimento energetico che si avrebbe se fosse utilizzata al 100%.

Dall’interfaccia grafica è possibile andare nel menu opzioni dove è possibile impostare tre modalità di lavoro:

• Low Power, dove la Cpu viene configurata per utilizzare la minima potenza
• MiserWare, dove la Cpu viene rallentata quando non utilizzata
• Highest Power, dove Granola viene disattivato per far utilizzare a pieno la potenza della CPU

La possibilità di intervenire sul clock della CPU è data dalle funzionalità DVFS della scheda madre pertanto verificate che la vostra supporti questa modalità.

Granola è un utile programma che senza richiedere alcuna configurazione e senza alterare minimamente il comportamento del Pc permette di risparmiare sull’energia utilizzata dal Pc stesso.

Visto il particolare periodo che stiamo attraversando risparmiare qualche euro potrebbe tornare comodo, direi che vale la pena provarlo!!

Download Granola Windows

Download Granola Linux

Per analizzare le performance e l’impatto delle nostre modifiche su di esse ci siamo serviti del plugin “YSlow” di Yahoo e “PageSpeed” di Google che offrono la possibilità di visionare statistiche e analisi dettagliate delle varie aree del sito suggerendo le modifiche da effettuare per ottenere un punteggio migliore.

Come funziona?

Solitamente i punteggi assegnati da YSlow e PageSpeed si basano su valutazioni effettuate sui singoli oggetti di una pagina Web quali i Css, i Javacript, la loro posizione nella pagina, il peso della pagina etc.

Tutti questi fattori hanno pesi diversi ai fini della valutazione finale ma, per ottimizzare le performance del sito è necessario concentrarsi sul numero di richieste Http generate, la posizione dei Javascript e il peso della pagina che, ovviamente, è composto da tutti i singoli oggetti quali immagini, css/js, codice,etc.

Il plugin W3 Total Cache agisce in particolar modo sul peso finale della pagina e sul numero di richieste Http generate. Come è noto al momento della richiesta di una pagina il Server provvede ad inviare tutti i singoli oggetti nell’ordine previsto nel codice sorgente al Browser dell’utente. Questo avviene ad ogni click di ogni utente. Se però, come è probabile, un articolo una volta pubblicato rimane invariato per giorni non è performante far elaborare ogni volta l’intera pagina al WebServer. Il plugin serve proprio a questo ossia a creare una copia “html” dell’intera pagina elaborata dal Browser per fare in modo che alle successive richieste venga servita direttamente la pagina html (l’output generato dal Server) invece che farla elaborare ogni volta.

In questo modo, analizzando una pagina con un Http Viewer come Fiddler o Tamper Data si noterà che la prima richiesta genererà per esempio

100 richieste Http x 400 Kb x 5 secondi

mentre il seguente refresh solo

35 richieste Http x 114 kb x 2,4 secondi.

Oltre ciò è possibile applicare una compressione all’output così da ridurre ulteriormente i tempi di caricamento.

Procediamo!

Per prima cosa sono necessari i seguenti plugins:

• W3 Total Cache by W3 EDGE – consente di gestire in maniera avanzata il caching delle pagine, del Database e il Minify dei Css e Javascript. A mio avviso si tratta del miglior plugin disponibile attualmente per la gestione della cache e non appena lo si installa e attiva si riscontrano subito dei miglioramenti nei tempi di caricamento.
• No Frames -  permette di evitare che il proprio sito venga visualizzato in Frames aumentandone così il punteggio Seo.
• Javascript To Footer – utilizzando questo plugin tutti gli scripts Javascript del proprio sito verrano posizionati a fine pagina garantendo una maggior velocità di caricamento del sito.
• SEO Friendly Images – Aggiunge automaticamente i tag Html “ALT” e “TITLE” alle immagini utilizzate nei post così come consigliato dal W3C.

W3 Total Cache by W3 EDGE

Per il plugin si suddivide in più aree ognuna delle quali è personalizzabile dall’utente.

A seconda dell’Hosting utilizzato alcune funzionalità possono non essere supportate e per evitare di impazzire nella configurazione ho provveduto a creare il file di configurazione adatto all’Hosting Linux Aruba. Se dovessero verificarsi degli errori nel suo utilizzo non esistate a contattarmi.

W3 Total Cache Configuration – Hosting Linux Aruba

Una volta scaricato è necessario modificare il riferimento alla sitemap. Per fare ciò aprite il file e andate alla riga 407 che apparirà nel seguente modo:

‘pgcache.prime.sitemap’ => ‘http://www.xxxxxxx.xxx/sitemap.xml’,

e sostituite l’url con quello della vostra sitemap. Per questo sito, quindi, andrà inserito:

‘pgcache.prime.sitemap’ => ‘http://www.capn3m0.org/sitemap.xml’,

Eseguita tale modifica rinominate il file da:

w3-total-cache-config.txt

a

w3-total-cache-config.php

ed importatelo nel plugin.

Accedete al vostro Pannello Admin del WordPress e seguite il percorso:

Performace -> General Settings

In basso troverete le opzioni di “Import/Export” come nella seguente figura:

Importate il file “w3-total-cache-config.php” e il gioco è fatto!

Navigate un po’ il sito e tornate sulle stesse pagine almeno due volte per verificare come appaiono dopo che sono state cachate. Se si dovessero verificare dei problemi con Javascript o Css provvedete a disabilitare tutte le opzioni di Minify del plugin.

N.B. – Potrebbero verificarsi degli errori “500 Internal Server Error” poiché il plugin modifica automaticamente il file “.htaccess” di WordPress e non tutti gli Shared Hosting supportano alcune istruzioni che vengono inserite. No panic!

Scaricate il file “.htaccess” seguente e sostituitelo a quell presente nella root di WordPress e il problema è risolto.

.htaccess WordPress + W3 Total Cache + Mod_Deflate On

Come indicato all’inizio dell’articolo oltre al caching, che riduce notevolmente il numero di richieste e la dimensione delle pagine, è possibile applicare una ulteriore compressione. Nel file .htaccess fornito ho provveduto ad inserire le istruzioni che abilitano il Mod_Deflate di Apache che, appunto, applicano la compressione all’output inviato all’utente.

Le righe che svolgono tale compito sono le seguenti:

SetOutputFilter DEFLATE
AddOutputFilter DEFLATE text/plain
AddOutputFilter DEFLATE text/xml
AddOutputFilter DEFLATE application/xhtml+xml
AddOutputFilter DEFLATE text/css
AddOutputFilter DEFLATE application/xml
AddOutputFilter DEFLATE image/svg+xml
AddOutputFilter DEFLATE application/rss+xml
AddOutputFilter DEFLATE application/atom_xml
AddOutputFilter DEFLATE application/x-javascript
AddOutputFilter DEFLATE application/x-httpd-php
AddOutputFilter DEFLATE application/x-httpd-fastphp
AddOutputFilter DEFLATE application/x-httpd-eruby
AddOutputFilter DEFLATE text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

In seguito procedete con l’installazione degli altri plugins indicati; la loro configurazione di default andrà bene.

A questo punto le operazioni sono terminate e, se tutto è andato bene, il vostro sito guadagnerà qualche punto nelle valutazioni di YSlow e PageSpeed.

Ma non ci fermiamo qui!

Faccio presente che in alcuni Shared Hosting è presente anche il Modulo Apache chiamato “Mod_expire” che consente di indicare al Browser di salvare gli oggetti nella cache locale del Pc per un periodo da noi prefissato.

Questa configurazione aumenta notevolemente i tempi di caricamento del sito poiché tutti gli oggetti quali parti del template, immagini, css e javascript saranno già presenti nell’Hard Disk del visitatore e pertanto i dati REALMENTE da scaricare saranno minimi.

Come è facile intuire aprendo due articoli a caso di questo sito le differenze tra le due pagine sono limitate all’immagine dell’articolo, il testo di esso e altri pochissimi dati. Ogni volta che navighiamo, quindi, scarichiamo per intero delle pagine da 400 kb (template,css,testo,immagini,javascript,video,etc) in cui in realtà le differenze sono solo di 10 kb (testo,immagini).

Il Mod_Expire consente proprio di evitare questo inutile spreco di banda, richieste DNS e request HTTP, facendo salvare tutto nel Browser locale e interrogando realmente il sito solo per richiedere i pochi dati necessari.

Ecco di seguito i risultati ottenuti applicando quanto indicato in questo articolo:

Come si può constatare è stato classificato come Grade B in YSlow tra gli “Smaller Site or Blog” e le richieste sono passate da 49 a 10 con una riduzione di 300k sul peso delle pagine.

Postate i risultati per i vostri siti !!!

Quest’oggi vi illustro come poter attivare e ottimizzare la compressione tramite Mod Deflate di Apache quando attiva nel proprio spazio in Hosting.

Attivando tale compressione unita ad apposite modifiche al sito per ottimizzarlo al meglio (attivazione del Minify, attivazione della cache, etc) sono riuscito ad ottenere una compressione da 266Kb originari della mia Home Page a 16 K come dimostra l’immagine sottostante realizzata utilizzando il plugin “YSlow“.

Grazie a ciò e alle modifiche apportate al sito attualmente “capn3m0.org” è passato da “Grade F” a “Grade C” di Yahoo riuscendo a ottimizzare ed ottenere A e B in tutte le categorie dove è possibile intervenire.

Di seguito vi incollo il link al file “.htaccess” da utilizzare per abilitare la compressione HTTP tramite Deflate.

Download .htaccess – Compressione HTTP ON

Qui invece, potete leggere direttamente il codice da utilizzare:

SetOutputFilter DEFLATE
AddOutputFilter DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml text/javascript
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
 
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
 
# MSIE masquerades as Netscape, but it is fine
 BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
 
# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
 
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary

Le righe in questione sono le seguenti:

<?
ob_clean();
flush();
?>

Cosa sono?

ob_clean() – E’ il comando che cancella/svuota il contenuto dell’output_buffer senza, però, eliminare il buffer stesso.

flush() -E’ il comando che elimina il buffer.

Perché? Cos’è l’Output Buffer?

Il mio Hosting attuale ha l’output_buffer attivo di default e anche provando a disattivarlo tramite override con php.ini resta comunque abilitato. Solitamente non crea problemi in quanto si tratta di un buffer creato appositamente per migliorare le performance del Web Server e del Php. Una volta, quando ancora avevamo 56K e ISDN eravamo abituati a vedere la pagina caricarsi piano piano, pezzo per pezzo. Appariva il logo, poi il menu e via dicendo si componeva tutta la pagina. Con l’avvento delle attuali ADSL questa situazione non si verifica più, almeno a livello visivo. A livello prettamente tecnico l’intepretazione e la visualizzazione di una pagina Web continuano ad avere questo comportamento.

L’output_buffer server a migliorare tutto ciò aggiungendo un buffer dove viene caricata la pagina prima ancora che venga “servita” al Client, ossia il vostro Browser. In questo modo quello che una volta era il vedere il singolo pezzo caricato ora diventa un’attesa temporale, seppur minima. Utilizzando un buffer è necessario attendere che si riempia tutto prima che vengano inviati i dati al Browser (e quindi prima che iniziate a vedere la pagina visivamente).

Come e Dove?

Da quel che ho scoperto facendo varie prove è consigliato inserire le due righe di codice prima di qualsiasi output della pagina. Io nel caso di WordPress l’ho inserito prima di qualsiasi cosa nella pagina header del mio Template che si trova a questo percorso:

/<root_di_wordpress>/wp-content/themes/<nome del template utilizzato>/header.php

Ho inserito le righe prima della dicitura “<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0…” nel seguente modo:

<?
ob_clean();
flush();
?>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

Risultati

Da quel che ho potuto constatare sul mio sito e su quello di (pochi) altri le performance e soprattuto i tempi di risposta del Server migliorano.

Tengo a precisare che al momento non ho prove “scientifiche”  a sostegno della mia tesi e, quindi, vi invito a provare e se avete voglia ad informarmi dell’eventuale miglioramento (e speriamo non peggioramento) del vostro sito commentate questo post fornendo quante più informazioni possibili.

Il mio attuale Hosting ha il Php configurato come Cgi di Apache e l’output_buffering impostato a 4096.

Configurazione Php come CGI

Configurazione output_buffering a 4096

Non vi sono consigli veri e propri da dare in merito ma, per mia esperienza personale, l’utilizzo di un “php.ini” con abilitate alcune funzioni quali, ad esempio, la “Compressione Gzip“, permette di diminuire il numero di volte in cui il proprio sito va in Timeout o in errore “500 – Internal Server Error“.

La Compressione Gzip consente di far si che il Server comprima alcuni oggetti delle pagine ottimizzando così le performance in quanto il “peso” generale della pagina risulta ridotto.

Per attivare tale opzione vi sono vari modi ma, sinceramente, io preferisco utilizzare l’override tramite “php.ini”. Tale file contiene tutte le configurazioni del Web Server che sono, praticamente, quelle che vengono visualizzate quando si esegue il comando “phpinfo()” del Php. Per vederlo in azione basta creare e, successivamente, caricare via browser una pagina .php contenete le seguenti righe:

<?php

phpinfo();

?>

Utilizzando un php.ini opportunamente modificato è possibile variare (quando consentito del Provider) alcuni parametri come, ad esempio, il “memory_limit“, il “max_execution_time“, l’”output_buffering“, etc.

A questo link potete leggere tutti i parametri impostabili in tale file e la loro descrizione.

Tornando al discorso “Compressione Gzip” eccovi di seguito il codice da inserire nel vostro “php.ini” per abilitarla.

Io utilizzo il metodo che si appoggia alle Librerie Zlib. Il file “php.ini” per utilizzarle è il seguente:

output_buffering = 4096
output_handler =
zlib.output_compression = On
zlib.output_compression_level = 3
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

Per chi non avesse sbattimento eccovi il file già preparato da copiare nella root del proprio sito (o dove richiesto):

Php.ini – Compressione Gzip On – Librerie Zlib

In alternativa a tale metodo è possibile abilitare la compressione utilizzando le Gzip e, in tal caso, il codice da inserire è il seguente:

output_buffering = 4096
output_handler = ob_gzhandler
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

e questo il file già preparato:

Php.ini – Compressione Gzip On – Librerie Gzip

NOTE – Il file “php.ini” ha la particolarità di resettare alle impostazioni di default di Apache le eventuali impostazioni  omesse. Se inserite solo una riga contenente l’impostazione da cambiare le restanti verrebbero resettate ai valori minimi. E’ quindi importante inserire sempre tutte le impostazioni di base necessarie per evitare il crearsi di tale situazione. Il file da me pubblicato vale per il mio Hosting e, quindi, è possibile che su altri Provider crei problemi oppure necessiti di maggiori impostazioni inserite.

Se riscontrate problemi contattatemi tramite i Commenti che provvederò a darvi una mano.