CODEWITHSUNDEEP
javascriptweb-applicationsarchitectureassets
onlineracoon
onlineracoon

Reputation: 2970

HTML5 LocalStorage as cache and single asset request

I would like to know what the limits, cons are of the following concept:

Requirements:

  1. Browser with LocalStorage support.
  2. Serverside asyncronous non-blocking i/o technology.

Lets imagine the following request flow:

  1. client GET / request -> server. We call this stage "greeting", which is an interesting stage because the client now sends (also trough headers ofcourse) :

    • ip
    • browser
    • browser version
    • language
    • charset

  2. server -> client (200 OK)

  3. client -> IF OK -> establish a websocket with the server

once the websocket has been established we enter the "asset stream" stage.

  1. server -> looks for matching assets (stylesheets, images, javascript files, fonts etc.) that are specific for: language, browser, resolution specific assets) and STREAMS them through the websocket.

  2. server -> request (websocket, async stream of assets)

BENEFIT 1. No multiple requests through the wire avoiding DNS lookups etc.

BENEFIT 2. Cache the hell out of these assets in localStorage, which is the following stage.

  1. request -> put in LocalStorage cache.
  2. request -> render website.

I would like to know get some opinions, what might be a good idea, what might not etc.

My first thoughts where:

I hope my question was clear.

Upvotes: 3

Views: 332

Answers (1)

Yuriy Zubarev
Yuriy Zubarev

Reputation: 2871

Interesting approach, it's definitely worth thinking about. Let me be your devil's advocate:

BENEFIT 1. No multiple requests through the wire avoiding DNS lookups etc.

This is true, although it's only an issue when you're accessing a page/site for the first time. It's also somewhat mitigated by prefetching that modern browsers implement. It's important to remember that browsers will download multiple resources in parallel, which could be faster, and definitely more progressively responsive, than downloading the whole payload in bulk.

With today's technologies you can already serve a full fledged pages and applications with only a handful of resources as far as a web client is concerned (all of them could be gziped!):

  1. HTML
  2. combined and minified CSS files as one resource
  3. same for JS
  4. image sprite

BENEFIT 2. Cache the hell out of these assets in localStorage...

Browsers already cache the hell out of such assets! In addition, there are proven and intelligent techniques to invalidate those caches (which is the second biggest challenge in software development).

Other things to consider:

  1. Don't underestimate CDN. They are life savers when it comes to latency. Your approach is not latency friendly during the first request.
  2. AJAX and progressive enhancement approaches can optimize web app experience to make it feel like a desktop app already.
  3. You will need to re-invent or modify tools like FireBug to work with one stream containing all resources. No web development can be imagined nowadays without those tools.
  4. If browsers don't support this approach natively, then you will still have a hell of a time programming and letting browser know what your stream contains and how to handle it. By the time you process the stream and fire all necessary events (in the optimal sequence!) you might not gain as much benefits as you hoped for.

Good luck!

Upvotes: 3

Related Questions