Lesson 1: Introducing web storage CHAPTER 15 563
sessionStorage has a context that, by design, is extremely confined. It’s limited to a single
browser tab or window. Its data cannot be passed from one tab to the next. However, the
data can be shared among any <iframe> elements that exist on the page.Quick check
■■What object type are localStorage and sessionStorage?Quick check answer
■■They are Storage objects.Anticipating potential performance pitfalls
Web storage doesn’t come without a few drawbacks. This section covers some of the pitfalls
of using localStorage and sessionStorage.Synchronously reading and writing to the hard drive
One of the biggest issues with the Storage object that is used with localStorage and
sessionStorage is that it operates synchronously, which can block the page from rendering
while read/writes occur. The synchronous read/writes are even more costly because they are
committed directly to the client’s hard drive. By itself, that might not be a cause for concern,
but the following activities can make these interactions annoyingly slow for the user.
■■Indexing services on the client machine
■■Scanning for viruses
■■Writing larger amounts of data
Although the amount of time it usually takes to perform these actions is typically too small
to notice, they could lock the browser from rendering while it’s reading and writing values to
the hard disk. With that in mind, it’s a good idea to use web storage for very small amounts of
data and use alternative methods for larger items.NOTE WHY NOT USE WEB WORKERS TO READ/WRITE ASYNCHRONOUSLY?
Web storage is not available within web workers. If you need to write a value while in web
workers, you must use the postMessage() method to notify the parent thread and allow it
to perform the work instead.Anticipating slow search capabilities
Because web storage does not have indexing features, searching large data sets can be time
consuming. This usually involves iterating over each item in the list to find items that match
the search criteria.