9

On many static websites the total size of the actual text content of the most popular 20 pages would come in at under 100kb.

I would imagine that it would be possible to leverage HTML5 local storage to download content via AJAX from the server in a single file, save it to local storage and use it with a data driven JS framework such as angularJS. In fact you could be downloading even more content silently in the background. This could potentially make for a very fast and responsive user experience.

Despite this I have not seen any websites working in this way. Is there a reason that I am missing that would make this a bad idea?

Improve this question
8
  • 1
    Don't forget about making SEO work. And, do you really need to reinvent browser caching?
    – jfriend00
    Sep 21, 2015 at 9:11
  • You forget that a lot of this is done for you by the browser. A good reason not to do this would be: what if you needed to update one such resource?
    – Neil
    Sep 21, 2015 at 9:41
  • It is a bad idea because it is much much easier to supply the correct catching headers for your GET requests and let the browsers do the heavy lifting.
    – Esben Skov Pedersen
    Sep 21, 2015 at 18:09
  • @jfriend00, yes I was wondering about SEO also. I believe that Google's crawler can handle some basic javascript but this would probably be beyond the scope of their crawlers.
    – Matthew Dolman
    Sep 22, 2015 at 1:28
  • @Neil, I suppose that you could have expiry timeouts built in depending on the resource. As I mentioned in the post I was thinking more about static sites that would not be undergoing short-timespan updates
    – Matthew Dolman
    Sep 22, 2015 at 1:31

1 Answer 1

Reset to default
6

I think the short answer to your question is that the reason you’re not seeing much happening like what you describe is that HTML5 local storage is in no way up to the task, and we have until just the last two years or so lacked anything being specified that would provide a better solution.

About HTML5 local storage specifically: It has a race condition and some other problems that prevent it from being suitable for use in production for any application where you want to ensure there’s not data corruption and where you want to be able to store more than just strings.

Those problems in local storage could possibly be fixed but the reality is that none of the browser-engine vendors have any interest at this point in sinking further resources into their local storage implementations. They would all rather that Web developers use alternatives to local storage.

Anyway, for the use case you describe, thankfully there are actually more robust solutions in the works. The key piece going forward will be Service Worker—and, in the context of this question, the Service Worker Cache and CacheStorage interfaces specifically.

Also IndexedDB is the production-grade solution that the Web runtime now has for the general case of robust storage of data on the client, with efficient implementations, and with more feature-filled control over the type of data stored and how it’s stored.

Improve this answer
1
  • "local storage is in no way up to the task" - YES it IS up for the task. you can dump there any response coming from from the server, and for simple applications you will not scratch the 5MB limit. it wasn't meant for it, but still, it can very much successfully be used for caching server responses.
    – vsync
    Oct 14, 2018 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.