Recently there have been a number of blog posts on optimizations possible via Local StorageAPI. When Microsoft, Google, Amazon and a number of others aggressively adopt a new feature, people notice.
The optimization is to use Local Storage to reduce network requests and/or payload size. This should result in a more responsive experience for the user… except when it doesn’t.
This strategy can backfire because:
- Local Storage is a synchronous API
- Local Storage does IO
Disk IO is particularly problematic because it’s non-deterministic for a multitude of reasons. A simple disk operation can take anywhere from zero milliseconds to a few seconds. Browsers cope with this by preloading the entire Local Storage key/value store into memory on first request. While testing a website the developer is likely to frequently reload the same page multiple times. This means that the relevant disk IO is very likely to be cached in the os file cache.
Now consider the case of a user turning on their computer, firing up the browser and going to an optimized site:
- The webpage starts to load
- Data is read in from Local Storage
- Webpage completely freezes for a few seconds while the browser populates Local Storage key/value store.
This freeze can last anywhere from a few milliseconds on an unburdened computer to dozens of seconds on a computer with stock Windows settings (AntiVirus, Windows Indexing Service, etc). Firefox, Chrome, Safari suffer this fate to various degrees.
Local Storage has the following costs:
- It can take a long unresponsive while to read in maximum allowable 5megs of data
- This data is then in memory for the lifetime of the webpage session wasting memory. Imagine if every one of your tabs decided to do this.
- LS is persistent. My profile has 0.5MB of meebo.com data that will haunt me forever even though meebo is long gone from my history.
What should webdevs do instead?
Cry, rely on browser cache. There are no viable alternative at the moment. IndexedDB is complex, requires user to approve it and isn’t widely implemented. WebSQL is all about bringing SQLite problems we’ve been studying and fixing within Firefox to every single webpage.
My best guess is that we’ll end up with webdevs using convenience libraries built on top of IndexedDB. We will likely add promptless operation to IndexedDB.
We have already made Local Storage hurt less, we have a plan to make it relatively painless, but it will always degrade user experience when compared to something like IndexedDB.
Are there any other convenient APIs with terrible complications?
Of course, see sync XHR.