localStorage, perhaps not so harmful

Recently, Christian Heilmann and Taras Glek, both at Mozilla, posted articles critical of localStorage. The arguments in each of these really didn’t gel with my experience, and both felt unduly alarmist (“considered harmful” as argued elsewhere really should be retired as a post heading). So, I wanted to run the ruler over the arguments, and see whether they had validity.

Christian’s and Tara’s positions are very similar, so I’ll address them via Christian’s post. The essence of Christian’s criticism is

we have to stop advocating localStorage as a great opportunity for storing data as it performs badly

Strong words indeed. Is there evidence to back this up?

Christian then outlines these concerns in more detail

localStorage is synchronous in nature, meaning when it loads it can block the main document from rendering

Now, this is certainly true, and in theory, we could block the main UI in most browsers (Opera threads the main browser UI separately from scripts), as well as blocking the remainder of a script which uses localStorage while it waits on a read or write. But, in practice, is this a big deal? I’m a bit of a fan of evidence and testing, rather than theory alone, so I set out to test this. You can follow along at home if you like

Reading, writing and arithmetic

Here’s what I did. The test page allows you to specify what you want to save (as everything is saved to localStorage as a string, you just input a string value), and how many times you want to save it. Then, I just save the string that number of times to localStorage in a tight loop, measuring how long it takes, and report that back. Keep in mind this is very quick and dirty, and can fall over without any warning if you over fill your localStorage.

The test is really simple, but we should get a sense of how big a performance hit localStorage is. Here are results for writing 18bytes 10,000 times inside a tight loop (results are meant to be indicative), then reading them back out again

Browser Write 10K Read 10K
IE10 1250ms 24ms
Chrome (19) 2097ms 1578ms
Safari 5 58ms 3ms
Firefox 8 232ms 130ms
Opera 11.6 764ms 597ms
iPhone 4G iOS 5.0 115ms 82ms
iPad 1 iOS 5.0 102ms 69ms

At worst, we have a 2s wait (in, of all browsers Chrome 19, a developer preview). In many browsers the wait is less than a tenth of a second. Remember this is for reading or writing 10,000 times to localStorage.

What about for larger amounts of data? Here’s the results for reading and writing 128 bytes

Browser Write 10K Read 10K
Chrome (19) 2081ms 1514ms
Safari 5 57ms 3ms
Firefox 8 250ms 136ms
Opera 11.6 664ms 614ms
iPhone 4G iOS 5.0 221ms 112ms
iPad 1 iOS 5.0 161ms 69ms

So, in essence, we’re really not seeing the performance impacted even when we increase the amount of data stored by a factor of 6 or so.

Given that writing 10,000 times to localStorage in a tight loop is I’d argue an edge case (and probably not advisable), on the face of it, the assertion that localStorage, being synchronous, and for that very reason has performance issues is largely misplaced in fact.

Christian continues

localStorage does file I/O meaning it writes to your hard drive, which can take long depending on what your system does (indexing, virus scanning…)

On a developer machine these issues can look deceptively minor as the operating system cached these requests – for an end user on the web they could mean a few seconds of waiting during which the web site stalls depending on what your system does (indexing, virus scanning…)

emphasis mine

Again in theory this looks worrisome, but I think in practice browser developers will use some sort of in memory caching and then asynchronously write to disk (actually based on my tests below I suspect that’s what they are doing)

In order to appear snappy, web browsers load the data into memory on the first request – which could mean a lot of memory use if lots of tabs do it

They may do, but this is an implementation detail for browser developers, and regardless of whatever mechanism they implement for persistent client side data (IndexedDB, webSQL…) in order to appear snappy, some sort of memory caching will be required.

localStorage is persistent. If you don’t use a service or never visit a web site again, the data is still loaded when you start the browser

Again this is an implementation detail for browser developers, and I doubt browsers have to load the localStorage DBs for all pages ever stored when they launch. I can imagine all kinds of caching strategies to balance responsiveness with memory use, application developers (speaking as one for many years) do this sort of thing all the time.

But above all, in practice, are we actually seeing any of this taking place in the wild? Can Christian point to sites that are suffering because of these theoretical limitations in localStorage?

Christian then makes something of a curious leap when he argues

In essence this means that a lot of articles saying you can use localStorage for better performance are just wrong

So, when the likes of Steve Souders, and teams of very smart people at places like Google and Bing research and develop techniques using localStorage for client side resource caching, they are “just wrong” because in theory localStorage has performance issues. To be direct, I find this position baffling. Especially when not a single datapoint is quoted (the tests cases I developed here took in the order of an hour, so it’s not overly taxing to do).

None of this is to say localStorage is perfect. Its limitations as to storage size, the fact that everything stored is simply a string, and that JavaScript strings are UTF-16, thereby halving the effective storage space are all real issues. Is the synchronous nature of localStorage an issue? Synchronous APIs are easier for developers to use (no need for callback functions), and so the idea of a simple client side storage mechanism, webStorage, coupled with a more sophisticated, high performance database standard (currently mired in standardization issues, far from localStorage’s fault) makes excellent architectural sense IMO.

But frankly, Christian and Tara do developers no benefit asserting localStorage is “harmful”, or that “there is no simple solution for local storage”. localStorage is very widely supported (IE8 up), very straightforward to use, has excellent performance for most use cases, and has been implemented in a large number of real world projects, including by Bing and Google. Sure, if you’re writing an app that does 10K simultaneous writes to a database, you’ll have the chops to get around a 2s write time in the worst case, but you will doubtless have all kinds of other performance and memory use challenges. So by all means help developers understand the potential shortcomings of a given technology, outline the gotchas, and workarounds, and propose improvements. But do so based on evidence, and also with the acknowledgement that localStorage is here to stay, and that any alternative also faces many similar, as well as their own additional challenges, and in the case of client side storage is perhaps years away from the same level of support as webStorage. The perfect, as is often stated, is the enemy of the good, or adequate. Let’s by all means make the adequate good, and the good excellent, but let’s not wait around forever for the perfect. We’ll be waiting a while.

Edited to correct Taras’ name

22 responses to “localStorage, perhaps not so harmful”:

  1. Nice bit of research, John – glad to see some evidence to put things in perspective.

    Yes, localStorage is not perfect but ultimately we should use the right too for the right job, and with its simplicity and good browser support, localStorage often fits the bill for basic string or even object storage and caching.

    • By: Alec
    • March 8th, 2012

    Great post John, I too was not sure why there was so much negativity towards local storage in that article. One thing to keep in mind with local storage/client side caching perf issues is that it is almost always worth it if it saves a network request.

  2. Hi John,

    first of all, the name is Taras, and most of the points I listed are from an internal list by him and a few other people of the platform team. You paint me here as someone who demonises localstorage and doesn’t back it up with data. This hurts. Notice the title of my post is “There is no simple solution for local storage” and not “localstorage is slow and bad and people at google and bing are idiots for using it”.

    The main goal of the post was to point out that there are issues with localstorage and that the fallback solutions are not as stable as we would like them to.

    Your test of 10K is not what the issue is. The main argument started with Robert’s post showing how to store _files_ in localstorage, which is something people do – I know a few people who serve jQuery from localstorage.

    My main goal was to spark a conversation and make people consider _how_ they use localstorage as far too many tutorials praise it as the solution for everything out there – it is not.

    I personally _prefer_ localstorage to indexedDB or WebSQL as I am not a big fan of storing things into the unknown. I think it needs fixing and we can only do that if we question and add it. You fail to mention the 5mb limit that is _arbitrary_ and the lack of error reporting or a method to know how much space I have left. We have a chance to make localstorage a great solution. We can’t if we already say it is great for everything.

  3. Recently I’ve built an open source word puzzle game ( http://hexaga.me ) and the entire dictionary (~400kb) resides in localStorage. It is true that writes are inconsistent and sometimes it takes longer to fill the database, but I’d say that overall localStorage can be used even on memory/speed critic applications such as games.

    • By: John
    • March 9th, 2012


    I’m very sorry that you read my post as being as you express it here. That certainly wasn’t my intention, and I’m sorry if that has upset you.

    I understand that perhaps folks might read the “considered harmful” as being attributed to you, when it is the title of Taras post.

    However, here is how you start your post

    “we have to stop advocating localStorage as a great opportunity for storing data as it performs badly”

    That’s about as direct as you can get. I read this as “localStorage is unusably broken”.

    And you state categorically “a lot of articles saying you can use localStorage for better performance are just wrong” (my emphasis).

    I don’t agree with the general statement, or the specific criticism regarding performance,aAnd I then went about addressing in detail all of your specific points.

    I stand by my position that the data don’t warrant the concern you, Taras, and others have expressed.

    Regarding the file storage, I thought my data addressed this reasonably well – showing that performance doesn’t seem to degrade as the size of data stored increases significantly. I’ve run some more tests, this time storing and reading 4KB (a realistic file size?) 500 times. Read and write times for all 500 in a tight loop, took from 1ms or less (Safari) to ~100ms (Chrome). So n an extreme simulation of the use case you suggest, performance is even less of a concern.

    BTW, you can easily do these kinds of tests yourtself using the test page I created.

    I agree with you localStorage isn’t perfect. And I agree that for more sophisticated uses we need something more sophisticated. Unfrotunately in the pile on against localStorage we’ve seen the last couple of weeks, from Paul Kinlan, Taras and others, yours was the post I chose to use to address these issues specifically and then generally, when others I think have been more specifically anti localStorage.

    • By: Andrew Betts
    • March 9th, 2012

    I suspect I’m one of the people Chris has in mind when he says he knows of People that serve files from local storage. For the FT web app we make extensive use of LS for caching script resources client side, and we find it the most reliable, performant and least ridiculously implemented clien side storage technology – compared to webSQL and the HTML5 app cache anyway.

    Yes it’s syncronous, but it’s fast and syncronous. Many of chris’s other concerns apply equally to any form of client side data store and should be aimed at browser vendors, not developers. We use what works, not what’s theoretically best practice, and for us right now that means local storage is a big winner.

    If we all continue to try and make our sites work in all browsers, even those with shoddy implementations of new technologies, then we’re held back, and users have less incentive to upgrade. Many of our users are corporate, and sadly we still see some very elderly blackberries in our logs more than we’d like. Does this stop us using local storage? No. We just build them a simple alternative and subtly advise them to buy a phone with a better browser, one that had good, fast, reliable and sane implementations of the technologies that we want to use to deliver a great user experience..

    • By: Gijs
    • March 9th, 2012

    If localStorage IO is supposed to be slow and using it locks up apps because of it being IO-bound, I find it odd that you do this ‘test’ without mentioning on what hardware you’re running it. I’m sure it’s fast on an SSD or flash storage (this probably explains the low iPad/iPhone numbers, although Safari’s caching might, too). But try it on your grandmother’s laptop from a couple of years back, with a fragmented 5400rpm hdd, etc… and you’re sure to get different results. It would benefit the article if you showed the range of results you’d get on different IO solutions.

  4. We use localStorage for some (pre)caching of requests that are slow across the network (for a variety of reasons).

    As Andrew points out, it’s the least awful of the client-side storage techniques to implement on an existing site. We looked at app-cache, but it’s harder to make it play nicely with our existing restful uri scheme. There were also oddites with Chrome’s handling of expired caches that made us wary.

    You have to ask yourself is localStorage faster than the alternative? Faster than the same file in normal browser cache (also on disk), which might not be there? Faster than the equivalent network request? If yes, then it can be good choice. But as with all new shiny tech, use with care.

  5. Test (had problems submitting before)

    • By: Graham B
    • March 10th, 2012

    I too initially interpreted Chris’ article as “localStorage is bad and you shouldn’t be using it” however I didn’t really think this is really what he meant. I always considered localStorage as a mechanism for keeping small snippets of temporary cached data rather than a file store; I was actually surprised that developers would use if for storing images or even entire libraries.

  6. Localstorage is simply a relatively young “technology” that offers a nice and widely supported way to store persistent data inside the browser. We all agree that it could be better… but everything could be better. Localstorage is only one of the fundamental steps to make a better and distributed web.

  7. […] John Allsopp does some performance testing in localStorage, perhaps not so harmful […]

  8. […] localStorage, perhaps not so harmful by John Allsopp. […]

  9. […] argue that this is not likely to be a significant problem for most cases.I recently conducted some testing across a number of devices and browsers which demonstrates that even for poorly implemented code […]

  10. […] localStorage, perhaps not so harmful by John Allsopp […]

  11. […] localStorage, perhaps not so harmful by John Allsopp […]

  12. […] Most recently, I critiqued a spate of articles arguing that localStorage suffers from performance issues (well, might in theory, though evidence suggests otherwise). […]

  13. […] localStorage perhaps not so harmful by John Allsopp […]

  14. […] a large number of follow-up articles taking up the task of providing numbers. John Allsopp wrote localStorage perhaps not so harmful, in which he measured the amount of time it took to read and write 10KB using localStorage. I also […]

  15. […] a large number of follow-up articles taking up the task of providing numbers. John Allsopp wrote localStorage perhaps not so harmful, in which he measured the amount of time it took to read and write 10KB using localStorage. I also […]

  16. […] local storage》发表以后,实际上在国外引起了相当的讨论——John Allsopp 的《localStorage perhaps not so harmful》以及 Nicholas C.Zakas 的《In defense of […]

  17. I first read about it in a newspaper article a few months ago, and have since
    come across more references and testimonials.
    My Little One has extremely sensitive skin, annoyingly sensitive, so cloth diapering
    has been a challenge from the start. Olive oil is
    also good, but not after it has been heated.