{"id":269,"date":"2012-05-23T09:07:15","date_gmt":"2012-05-23T07:07:15","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/application-cache-idiota\/"},"modified":"2012-05-23T09:07:15","modified_gmt":"2012-05-23T07:07:15","slug":"application-cache-idiota","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/application-cache-idiota\/","title":{"rendered":"Application Cache \u00e8 un idiota"},"content":{"rendered":"

Buongiorno! Al \u201ccastello Lanyrd\u201d abbiamo appena lanciato la versione mobile del nostro sito<\/a>, che memorizza i dati degli eventi a cui assistete per vederli offline. Ho ridotto i bit offline a una semplice demo<\/a> e ho pubblicato tutto il codice su Github<\/a>. Ma prima di immergerci nel codice, lasciate che vi racconti una storia vera, assolutamente vera.<\/p>\n

Mi trovavo ad un party, uno di quelli in cui gli ospiti si conoscono a malapena. Facevo parte di un piccolo gruppo che stava cercando, non senza disagi, di fare le presentazioni. Una donna piuttosto bella si rivolse ad uno dei membri pi\u00f9 timidi del gruppo, presentandosi come “Dev” e chiese: “E tu che lavoro fai?”<\/p>\n

“Oh, sono il LocalStorage.”, rispose, chiaramente a disagio. “Fornisco un’interfaccia di scripting per memorizzare del testo che viene mantenuto tra le pagine e le sessioni del browser.”<\/p>\n

“S\u00ec, praticamente \u00e8 uno scaffale!”, interruppe un altro. Il gruppo ridacchi\u00f2 alle spalle di LocalStorage. Io rimasi in silenzio, perch\u00e9 conoscevo abbastanza bene quel ragazzo.<\/p>\n

Un altro membro del gruppo si fece avanti. “Ciao, sono ApplicationCache” disse, spostandosi per stringere la mano di Dev, “Faccio diventare la tua esperienza offline da pessima a fantastica: solo un file in pi\u00f9 e voil\u00e0! Funziona. Nessuna preoccupazione, nessun bisogno di fare ‘scripting𔃷”. S\u00ec, fece le virgolette con le dita mentre diceva ‘scripting’. A quel punto stavo stringendo i denti, perch\u00e9 sapevo che aveva ingrandito enormemente le sue capacit\u00e0 senza che gli altri lo vedessero. Tuttavia, se avessi gridato “cavolate” io<\/em> avrei fatto la figura dell’idiota.<\/p>\n

Mi sono sentito male per non fatto nulla in quella serata completamente reale. \u00c8 doloroso vedere articoli che lodano la facilit\u00e0 d’uso di ApplicationCache, scritti da persone che l’hanno chiaramente visto superficialmente. Devo mettere subito le cose in chiaro: sono qui per dirvi che ApplicationCache \u00e8 una cretinata.<\/p>\n

Ora, non intendo dire che sia completamente inutile o che dovrebbe essere evitato, dovete solo essere molto cauti quando ci lavorate e nel modo in cui lo usate. Se lo usate nel modo sbagliato, la stupidit\u00e0 si diffonde tutto intorno, fino all’utente finale. Leggendo le mie esperienze traumatiche con AppCache, saprete cosa aspettarvi da AppCache e come gestirlo.<\/p>\n

\n

Quando \u00e8 utile l’accesso offline?<\/h2>\n

Siamo meglio connessi di quanto non lo siamo mai stati, ma non siamo sempre<\/em> connessi. Ad esempio, sto scrivendo questo articolo su un treno che sfreccia attraverso le pianure povere di dati del West Sussex. In alternativa, potreste scegliere di essere offline. Quando uso la connessione dati all’estero mi pare di sentire i tappi di champagne che saltano negli uffici del mio network provider. So di avere un’emorragia di soldi quando uso il roaming dati, ma internet ha dei dati di cui ho bisogno e non mi fa accedere alla maggior parte di questi senza una connessione funzionante.<\/p>\n

I siti utili offline si suddividono generalmente in due categorie: quelli che ti permettono di fare cose e quelli che ti permettono di cercare cose.<\/p>\n

I siti che permettono di “cercare cose” includono Wikipedia<\/a>, YouTube<\/a> e Twitter<\/a>. Il grosso del carico tende ad essere sul server e c’\u00e8 una gran quantit\u00e0 di dati a disposizione degli utenti, che per\u00f2 ne usano solo una parte.<\/p>\n

I siti che permettono di “Fare cose” includono Cut the Rope<\/a>, CSS Lint<\/a> e Google Docs<\/a>. Per questa tipologia di siti, il grosso del carico \u00e8 a lato client. Offrono una quantit\u00e0 limitata di dati, ma potete usare quei dati in molti modi o creare i vostri dati. Questo \u00e8 il caso per cui \u00e8 stato realizzato Application Cache, quindi cominceremo da qui per una semplice introduzione.<\/p>\n<\/div>\n

\n

Mettere offline un sito per “fare cose”<\/h2>\n

Sprite Cow<\/a> ricade nella categoria “fare cose”. Le CSS sprites sono ottime per le prestazioni<\/a>, ma trovare la dimensione e la posizione di un oggetto in una sprite \u00e8 piuttosto macchinoso. Sprite Cow carica lo sprite sheet e ritorna il CSS per mostrarne una particolare porzione. \u00c8 un file html, alcuni elementi e tutto il processing viene fatto a lato client: il server non fa nulla se non mandare i files.<\/p>\n

Sarebbe bello poter usare Sprite Cow in treno, cos\u00ec come facciamo con le app native. Per fare ci\u00f2, creiamo un manifest file che elenchi tutte gli elementi di cui ha bisogno il sito:<\/p>\n

\nCACHE MANIFEST\n\nassets\/6\/script\/mainmin.js\nassets\/6\/style\/mainmin.css\nassets\/6\/style\/fonts\/pro.ttf\nassets\/6\/style\/imgs\/sprites1.png\n<\/code><\/pre>\n
… Poi colleghiamo quel manifest alla pagina html mediante un attributo:<\/p>\n
<html manifest=\"offline.appcache\"><\/code><\/pre>\n
La pagina HTML stessa non \u00e8 elencata nel manifest. Le pagine che si associano ad un manifest ne diventano parte.<\/p>\n
In pratica, se visitate Sprite Cow<\/a> con una connessione dati, sarete in grado di visitarlo in seguito senza una connessione.<\/p>\n
Il tab “resource” nel Web Inspector di Chrome vi mostrer\u00e0 i files caricati dal manifest e quali pagine vi puntano. Se avete bisogno di svuotare quelle cache, andate su chrome:\/\/appcache-internals\/<\/a>.<\/p>\n
Sulle prime, questo pu\u00f2 sembrare una soluzione magica al problema. Sfortunatamente, stavo mentendo quando ho detto che questa sarebbe stata una semplice introduzione. La specifica di ApplicationCache \u00e8 come una cipolla: ha molti strati e man mano che li togliete, cominciate a lacrimare.<\/p>\n
Problema n.1: i files provengono sempre da ApplicationCache, anche se siete online.<\/h3>\n
Quando visitate Sprite Cow, ottenete subito la versione che avete in cache. Una volta che la pagina ha finito di essere caricata, il browser cercher\u00e0 degli aggiornamenti al manifest e ai file in cache.<\/p>\n
Tutto ci\u00f2 suona come un modo bizzarro per fare cose ma vuol dire che il browser non deve attendere che la connessione scada prima di decidere che siete offline.<\/p>\n
ApplicationCache attiva un evento updateready<\/code> per farci sapere che c’\u00e8 del contenuto aggiornato, ma non possiamo semplicemente fare il refresh della pagina a questo punto, perch\u00e9 l’utente potrebbe aver gi\u00e0 interagito con la versione che ha gi\u00e0.<\/p>\n
Non si tratta di un grosso problema, dal momento che la versione vecchia probabilmente \u00e8 sufficientemente buona. Se dovesse essere necessario, possiamo mostrare un piccolo messaggio “\u00c8 disponibile un aggiornamento. Fai refresh per aggiornare”. Potreste averlo visto in alcune app di Google come Reader e Gmail.<\/p>\n
Oh, vi ricordate quattro paragrafi fa quando dissi che ApplicationCache cerca il contenuto aggiornato dopo aver caricato la pagina? Mentivo.<\/p>\n
Problema n.2: ApplicationCache si aggiorna solo se il contenuto stesso del manifest \u00e8 cambiato.<\/h3>\n
HTTP ha gi\u00e0 un modello di caching. Ogni file pu\u00f2 definire come dovrebbe essere messo in cache. Anche ad un livello base, i file singoli possono dire “Non mettermi mai in cache” oppure “controlla con il server, ti dir\u00f2 se c’\u00e8 un aggiornamento” oppure “assumi che io vada bene fino al 1 Aprile 2022”.<\/p>\n
Tuttavia, immaginatevi di avere 50 pagine html nel vostro manifest. Ogni volta che ne visitate una di queste online, il browser dovrebbe fare 50 http request per vedere se avete bisogno di un update.<\/p>\n
Come workaround leggermente insolito, il browser cercher\u00e0 gli aggiornamenti solo dei file elencati nel manifest se il file del manifest stesso \u00e8 cambiato dall’ultima volta che il browser ha controllato. Va bene qualsiasi cambiamento che renda diverso il manifest anche di un solo byte.<\/p>\n
Questo funziona in maniera piuttosto trasparente per gli elementi statici che vengono idealmente caricati attraverso un content delivery network e che non cambiano mai. Quando il CSS\/JavaScript\/etc. cambiano, viene caricato sotto ad un differente url, il che vuol dire che il contenuto del manifest cambia. Se non avete familiarit\u00e0 con “far-future caching” e le CDN, leggete la guida con le best practices per le performance di Yahoo!<\/a>.<\/p>\n
Alcune risorse semplicemente non possono cambiare il proprio url in questo modo, come ad esempio le nostre pagine HTML. ApplicationCache non cercher\u00e0 aggiornamenti a questi files senza un piccolo incoraggiamento. Il modo pi\u00f9 semplice per farlo consiste nell’aggiungere un commento al proprio manifest e cambiarlo quando serve.<\/p>\n
\nCACHE MANIFEST\n# v1\n\nwhatever.html\n<\/code><\/pre>\n
I commenti nel manifest cominciano con un #<\/code>. Se aggiorno whatever.html<\/code> dovrei cambiare il mio commento a # v2<\/code>, facendo cos\u00ec scattare un aggiornamento. Potrei automatizzarlo con un build script che mi mandi fuori qualcosa di simile a ETAG come un commento per ciascun file nel manifest, cos\u00ec che ciascun cambiamento nel file \u00e8 certo che cambier\u00e0 il contenuto del manifest.<\/p>\n
Comunque, aggiornare il testo nel manifesto non garantisce che le risorse all’interno saranno aggiornate dal server.<\/p>\n
Problema #3: ApplicationCache \u00e8 una cache aggiuntiva, non alternativa.<\/h3>\n
Quando il browser aggiorna ApplicationCache, richiede gli url come farebbe di solito. Obbedisce alle normali istruzioni di caching: se un header di un oggetto dice “assumi che io sia valido fino al 1 Aprile 2022” il browser supporr\u00e0 che la risorsa sia davvero valida fino al 1 Aprile 2022 e non dar\u00e0 fastidio al server per un aggiornamento.<\/p>\n
Questa \u00e8 una buona cosa perch\u00e9 potete usarla per tagliare il numero di richieste che il browser deve fare quando cambia il manifest.<\/p>\n
Tutto ci\u00f2 pu\u00f2 cogliere le persone di sorpresa mentre stanno facendo esperimenti volti a capire se i propri server non mandino gli header della cache. Senza specifiche, il browser tirer\u00e0 ad indovinare sulla cache. Potete aggiornare whatever.html<\/code> e il manifest, ma il browser non aggiorner\u00e0 il file perch\u00e9 “supporr\u00e0” che non abbia bisogno di aggiornamenti.<\/p>\n
Tutti i file che inviate dovrebbero avere degli header della cache \u00e8 questo risulta specialmente importante per tutto quello che c’\u00e8 nel vostro manifest e per il manifest stesso. Se \u00e8 molto probabile che un file venga aggiornato, dovrebbe essere inviato con no-cache<\/code>. Se il file cambia poco frequentemente, \u00e8 meglio optare per must-revalidate<\/code>. Ad esempio, must-revalidate<\/code> \u00e8 una buona scelta per il file manifest stesso. Oh, gi\u00e0 che stiamo parlando di questo…<\/p>\n
Problema n.4: mai mai fare “far-future cache” nel manifest.<\/h3>\n
Potreste pensare di poter trattare il vostro manifest come un file statico, come in “assumi che io sia valido fino al 1 Aprile 2022” poi cambiare l’url al manifest quando dovete fare un aggiornamento.<\/p>\n
No! Non fatelo! *sberla*<\/em><\/p>\n
Ricordatevi il Problema n.1: quando l’utente visita una pagina una seconda volta, otterr\u00e0 la versione di ApplicationCache. Se avete cambiato l’url al manifest, sfortuna, la versione memorizzata dall’utente punta ancora al vecchio manifest, che ovviamente \u00e8 identico byte per byte, quindi non si aggiorna alcunch\u00e9. Mai.<\/p>\n
Problema n.5: le risorse non in cache non verranno caricate in una pagina in cache.<\/h3>\n
Se mettete in cache index.html<\/code> ma non cat.jpg<\/code>, quell’immagine non verr\u00e0 mostrata su index.html<\/code> anche se siete online. No, davvero, quello \u00e8 il comportamento atteso, controllate voi stessi<\/a>.<\/p>\n
Per disabilitare questo comportamento, usate la sezione NETWORK<\/code> del manifest.<\/p>\n
\nCACHE MANIFEST\n# v1\n\nindex.html\n\nNETWORK:\n*\n<\/code><\/pre>\n
L’*<\/code> indica che il browser dovrebbe permettere tutte le connessioni alle risorse non memorizzate da una pagina in cache. Potete qui vederlo applicato all’esempio precedente<\/a>. Ovviamente queste connessioni falliranno mentre siete offline.<\/p>\n
Ben fatto: siete arrivati alla fine dell’esempio di ApplicationCache. S\u00ec, davvero, abbiamo visto il caso semplice. Mi spiace. Cerchiamo qualcosa di pi\u00f9 difficile.<\/p>\n<\/div>\n
\n
Mettere offline un sito che “fa cercare cose”<\/h2>\n
Come ho detto all’inizio di questo articolo (ricordate quant’ero felice?), Lanyrd ha recentemente lanciato un sito mobile<\/a> che permette alla gente di guardare i programmi, i luoghi, chi partecipa alle conferenze e altro ancora. L’accesso offline a questi dati \u00e8 importante mentre si \u00e8 in viaggio e si devono affrontare dei costi di roaming.<\/p>\n
C’\u00e8 troppo contenuto per poter mettere tutto offline, ma a ciascun utente di solito interessano solo gli eventi a cui partecipa.<\/p>\n
Il vecchio Dive into HTML5<\/a> ci mostra un esempio in cui si mette offline<\/a>, un altro sito che permette di cercare cose. Funziona usando un manifest quasi vuoto a cui sono collegate tutte le pagine, cos\u00ec man mano che gli utenti navigano nel sito, quelle pagine diventano implicitamente parte della loro cache. Quando saranno offline, saranno in grado di visitare ciascuna delle pagine che hanno precedentemente visitato.<\/p>\n
Questa soluzione \u00e8 incredibilmente semplice, ma grazie ad alcuni “goffi pezzi” della specifica, si rivela essere un completo disastro. Tanto per cominciare, all’utente non viene data nessuna indicazione di quale sia il contenuto disponibile mentre si \u00e8 offline e non c’\u00e8 una API JavaScript che possiamo usare per arrivare a tale informazione. Potremmo scaricare e analizzare il manifest con JavaScript, ma tutte queste pagine Wikipedia sono memorizzate in cache implicitamente e pertanto non sono elencate.<\/p>\n
Inoltre, ricordatevi del Problema n.1: viene visualizzata la versione in cache piuttosto che la versione proveniente dal server. La pagina viene congelata per l’utente quando questo la guarda per la prima volta, ma come abbiamo visto nel Problema n.2 possiamo fare in modo che il browser cerchi degli aggiornamenti cambiando il testo nel file manifest. Tuttavia, quando cambiamo il file manifest? Ogni volta che viene aggiornata una voce di Wikipedia? In questo modo, gli aggiornamenti sarebbero troppo frequenti, infatti se un manifest cambia tra l’inizio e la fine di un aggiornamento, il browser considerer\u00e0 fallito questo aggiornamento (step 24)<\/a>.<\/p>\n
La frequenza di questi aggiornamenti \u00e8 un problema, ma il vero killer \u00e8 il peso di questi aggiornamenti. Prendete ad esempio il numero di pagine di Wikipedia che avete visitato: un centinaio? Migliaia? Un aggiornamento AppCache implica lo scaricamento di ogni singola<\/strong> pagina. AppCache non ci d\u00e0 un modo per rimuovere implicitamente gli oggetti memorizzati, cos\u00ec quel numero continuer\u00e0 a crescere e crescere finch\u00e9 non raggiunger\u00e0 un qualche tipo di limite della cache del browser ed il mondo esploder\u00e0. Non va bene.<\/p>\n<\/div>\n
\n
Cosa vogliamo da un sito di riferimento che possiamo mettere offline?<\/h2>\n
I requisiti che vorrei per un sito di riferimento con capacit\u00e0 offline sono le seguenti:<\/p>\n