Progressive JPEG pro e contro

Nell’articolo Progressive jpegs: a new best practice, Ann Robson (@aronbson), analizza tutti i pro e i contro dell’utilizzare progressive JPEG invece che baseline.

Per capirci una progressive JPEG è un’immagine composta da diversi layer che presi singolarmente sono grandi quanto l’immagine originale ma sembrano “sgranati”, se “sovrapposti” ci permettono di ottenere l’immagine completa. Al contrario, una JPEG baseline è composta da un solo frame con tutte le informazioni necessarie per una corretta visualizzazione.

Utilizzare JPEG progressive conviene sotto tanti punti di vista, il primo tra tutti è la velocità nel download e la percezione che si da all’utente “che qualcosa sta succedendo”.

In un test effettuato usando Firefox/12.0 e confrontando il download di una JPEG baseline di 5.4kb e di una JPEG progressive di 78.3kb si evince che il browser impiega meno tempo a scaricare un frame completo di una JPEG progressive di 78kb che di una JPEG baseline di soli 5.4kb.

image

Allora perché non utilizzare sempre JPEG progressive?


Sembrerebbe che non ci siano motivi per non usare questo tipo di codifica, invece bisogna far attenzione ad alcuni particolari.

  • Non tutti i browser rederizzano le JPEG progressive man mano che vengono scaricati i frame e quindi si perde tutto il vantaggio della codifica.

image

  • Renderizzare un solo frame di una JPEG Progressive richiede una tempo di elaborazione uguale a quello di elaborare un’intera JPEG baseline. Motivo per il quale sulle versioni mobile dei browser non vengono renderizzate le JPEG Progressive man mano che vengono scaricate, ma solo a download completato.

Da un po’ di tempo anche il modulo Pagespeed di google suggerisce di convertire le jpeg in progressive per ottimizzare le performance. Ovviamente questo perché Chrome supporta pienamente le JPEG progressive 🙂

Javascript Cross Domain API

I moderni browser implementano la cosiddetta same-domain-policy che impedisce a qualsiasi richiesta HTTP fatta con l’oggetto XmlHttpRequest di accedere a risorse su server con un dominio diverso da quello in cui risiede lo script chiamante.

Questo può sembrare una policy molto limitante ma impedisce alle pagine di caricare codice pericoloso e accedere a sessioni non autorizzate.

Questa limitazione peròc risulta fastidiosa quando si sviluppano applicazioni web in localhost che fanno uso di API che non risiedono sulla propria macchina.

Questo è l’errore che compare quando si tenta di accedere da localhost ad un dominio diverso tramite l’oggetto XmlHttpRequest:

image

XMLHttpRequest cannot load http://192.168.0.123/dengenchronicles-backend/api/user/login/test?username=test&password=test. Origin http://127.0.0.1 is not allowed by Access-Control-Allow-Origin.

Per risolvere il problema ci sono due strade, quella più comune è usare JSONP  come data-type delle chiamate AJAX che incapsula le chiamate in dei tag script e non usa l’oggetto XmlHttpRequest. Nella documentazione di jQuery viene spiegato bene… Usare questo metodo ha alcune limitazioni nella gestione delle chiamate, per questo ho preferito la seconda strada.

Un’alternativa  è modificare il file http.conf di apache, abilitare alcuni header e impostare un parametro nella chiamate ajax.

image

http.conf

Header set Access-Control-Allow-Origin “http://localhost”
Header set Access-Control-Allow-Credentials “true”

Ovviamente la stessa configurazione può essere impostata anche sul server di produzione, inserendo i giusti domini o usando wildcards, se si vuole dare la possibilità di utilizzare le proprie API anche ad altri domini.