è realistico utilizzare la memoria locale HTML5 per memorizzare CSS e JavaScript

È assolutamente OK utilizzare la memoria locale per archiviare JS e CSS. Tuttavia, lo spazio di archiviazione locale ha 5 milioni di limiti per dominio. Potrebbe essere necessario riconsiderare questa strategia.

Per il Web desktop, puoi sfruttare la cache del browser predefinita per fare il trucco. Basta impostare il JS & Risposta HTTP CSS per essere memorizzabile nella cache. È semplice e facile.

Per il Web mobile, la latenza è elevata. Quindi, la riduzione delle richieste HTTP è fondamentale. Quindi, avendo JS & I CSS negli URL esterni sono ottimali. Sarebbe molto meglio avere JS & CSS in linea. Questo riduce le richieste HTTP, ma gonfia il contenuto HTML. Allora cosa? Proprio come hai detto, usa la memoria locale!

Quando un browser visita il sito per la prima volta, JS & I CSS sono messi in linea. Il JS ha anche altri due posti di lavoro: 1) Store JS & CSS nella memoria locale; 2) Imposta cookie per segnalare che JS & I CSS sono nella memoria locale.

Quando il browser accede al sito per la seconda volta, il server riceve il cookie e sa che il browser ha già JS & correlati; CSS. Quindi il rendering HTML ha JS in linea per leggere JS & CSS dall'archiviazione locale e inserimento nell'albero DOM.

Questa è l'idea di base su come viene creata la versione per cellulari di bing.com. Potrebbe essere necessario prendere in considerazione il controllo della versione di JS e CSS quando lo implementa in produzione.

Grazie

Il browser non lo fa già per te e probabilmente è meglio?

Qual è il punto?

Esiste già una tecnica consolidata chiamata memorizzazione nella cache sul lato client. Che cosa porta in questo caso l'archiviazione locale HTML5 che cosa manca nella cache?

Potresti avere una specie di strana applicazione che deve caricare dinamicamente blocchi di codice JavaScript, quindi non puoi usare efficacemente la cache, ma è un caso estremamente raro.

Inoltre, sii consapevole di un'altra cosa. I browser hanno politiche specifiche per la cache, e la maggior parte dei browser è abbastanza buona per gestire bene la cache (rimuovendo solo il contenuto più vecchio, ecc.). Implementando la cache fatta in casa, impedisci ai browser di gestirlo correttamente. Non solo può essere criticato da solo, ma ti farà anche male presto o tardi. Esempio: quando gli utenti di un'applicazione Web segnalano bug, spesso rispondi chiedendo loro di svuotare la cache. Non sono sicuro di cosa chiederai nel tuo caso, poiché la cancellazione della cache non risolverà mai i problemi con la tua app web.

In risposta alla prima modifica (la seconda modifica è off-topic):

I do aware browser cache, there will be still some header access checking

Sembra che manchi una certa comprensione del caching del browser. Ecco perché è essenziale capire come funziona prima di iniziare a implementare il tuo meccanismo di caching domestico . Reinventa la tua ruota solo quando comprendi abbastanza le ruote esistenti e hai una buona ragione per non usarle. Vedere il punto 1 di la mia risposta alla domanda "Reinventare il ruota e NON rimpiangerlo ".

Quando si forniscono alcuni dati tramite HTTP, è possibile specificare alcune intestazioni relative alla cache:

• Last-Modified specifica quando il contenuto è stato modificato,
• Expires specifica quando il browser deve chiedere al server se il contenuto è cambiato .

Queste due intestazioni consentono al browser di:

• Evita di scaricare il contenuto ancora e ancora. Se Last-Modified è impostato sull'ultimo mese e il contenuto è stato già scaricato poche ore prima, non è necessario scaricarlo di nuovo.
• Evita di eseguire query per la data in cui il file è stato modificato l'ultima volta. Se Expires di un'entità cache è 5 maggio ^th , 2014, non devi presentare alcuna richiesta GET né nel 2011 né nel 2012 o 2013, poiché sai che la cache è attiva -to-date.

Il secondo è essenziale per i CDN. Quando Google serve JQuery a un visitatore di Overflow dello stack o cdn.sstatic.net serve immagini o fogli di stile usati da Stack Overflow, non vogliono che i browser richiedano una nuova versione ogni volta. Invece, stanno servendo quei file una volta, impostano la data di scadenza su qualcosa di abbastanza lungo, e questo è tutto.

Ecco ad esempio uno screenshot di ciò che accade quando arrivo alla pagina iniziale di Overflow dello stack:

Ci sono 15 file da servire. Ma dove sono tutte quelle risposte 304 Not Modified ? Hai solo tre richieste di contenuto che sono cambiate. Per tutto il resto, il browser utilizza la versione memorizzata nella cache senza effettuare alcuna richiesta a nessun server .

Per concludere, devi davvero pensarci due volte prima di implementare il tuo meccanismo di cache e, soprattutto, trovare un buon scenario in cui ciò può essere utile . Come ho detto all'inizio della mia risposta, ne trovo solo una: dove stai servendo blocchi di JavaScript per utilizzarli, OMG, eval() . Ma in questo caso, sono abbastanza sicuro che ci sono approcci migliori che sono:

• Più efficace utilizzando le tecniche di cache standard o
• Più facile da mantenere.

La memorizzazione nella cache locale sul lato client dovrebbe essere molto più ottimizzata rispetto all'utilizzo della memoria locale HTML5. Assicurati che il tuo javascript e CSS siano in file esterni e la tua pagina dovrebbe caricarsi molto più velocemente tramite la cache del browser piuttosto che cercare di estrarli dalla memoria locale ed eseguirli tu stesso.

Inoltre, il browser può iniziare a caricare risorse esterne all'avvio della pagina, prima di poter avviare effettivamente l'esecuzione di javascript in quella pagina per ottenere le risorse dall'archivio locale HTML5.

Inoltre, è necessario il codice nella pagina per caricare dalla memoria locale HTML5, quindi inserisci tutto il tuo JS in un file JS esterno e intercambiabile.

Invece di reinventare la ruota basta usare la funzionalità offline HTML5: link

Otterrai prestazioni decisamente migliori utilizzando una rete di distribuzione dei contenuti (CDN) come libreria codici di Google . Pianificato attentamente, la maggior parte del tuo JS e CSS dovrebbe essere nella cache di ogni visitatore prima che colpiscano il tuo sito per la prima volta. Riduci il resto.

Puoi sempre confrontare il caching del browser con la tua soluzione HTML5 arrotolata a mano. Ma la mia scommessa è che il caching nativo sta per sbarazzarsene.

Usare localStorage è veloce (er)! Il mio test ha mostrato

• Caricamento di jQuery da CDN: Chrome 268 ms , FireFox: 200 ms
• Caricamento di jQuery da localStorage: Chrome 47 ms , FireFox 14 ms

Immagino che il salvataggio della richiesta HTTP porti già un grande vantaggio in termini di velocità. Sembra che tutti qui siano convinti del contrario, quindi per favore dimostri che ho torto.

Se vuoi testare i miei risultati ho creato una piccola libreria che memorizza nella cache gli script in localStorage. Dai un'occhiata a Github link o copialo semplicemente dall'esempio qui sotto.

La libreria completa:

function _cacheScript(c,d,e){var a=new XMLHttpRequest;a.onreadystatechange=function(){4==a.readyState&&(200==a.status?localStorage.setItem(c,JSON.stringify({content:a.responseText,version:d})):console.warn("error loading "+e))};a.open("GET",e,!0);a.send()}function _loadScript(c,d,e,a){var b=document.createElement("script");b.readyState?b.onreadystatechange=function(){if("loaded"==b.readyState||"complete"==b.readyState)b.onreadystatechange=null,_cacheScript(d,e,c),a&&a()}:b.onload=function(){_cacheScript(d,e,c);a&&a()};b.setAttribute("src",c);document.getElementsByTagName("head")[0].appendChild(b)}function _injectScript(c,d,e,a){var b=document.createElement("script");b.type="text/javascript";c=JSON.parse(c);var f=document.createTextNode(c.content);b.appendChild(f);document.getElementsByTagName("head")[0].appendChild(b);c.version!=e&&localStorage.removeItem(d);a&&a()}function requireScript(c,d,e,a){var b=localStorage.getItem(c);null==b?_loadScript(e,c,d,a):_injectScript(b,c,d,a)};

Chiamare la libreria

requireScript('jquery', '1.11.2', 'http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js', function(){
    requireScript('examplejs', '0.0.3', 'example.js');
});