IndexedDB is not limited to 5MB, its essentially unlimited in Chrome and Firefox. It can be tricky with mobile browsers but they often also have the option of using an unlimited web app wrapper (http://www.html5rocks.com/en/tutorials/offline/quota-researc...)
And as for WebSockets, HTTP is easier to debug and experiment with, in my experience the performance difference for the typical use cases is negligible and when needed it is trivial to wrap the communication in a socket.
WebSockets are for fast, low-overhead connections. If you end up making a new HTTP connection for every update, and there are a lot of updates happening, you should be using WebSockets instead.
Otherwise, HTTP works best. It has better tooling and will soon be even faster due to HTTP/2.
I'm surprised no one mentions xhr streaming, if your pipe is only one way i.e server notifies client, then xhr streaming is quite easy to use and as fast as websockets.
It really is a challenge. I don't think it'll be realistic to build mid-size, fully offline web apps (excluding tools like electron) until indexedDB has wider support. One solution is to garbage collect the oldest data from localStorage and sync with a server when you've got connection, but once you're offline you're kinda stuck with 5mb. However, caniuse.com/#feat=indexeddb is optimistic about the future.
The company I work for is trying to make offline/decentralized apps more realistic (gundb.io, github.com/amark/gun) and storage limitations can be aggravating at times.
Its realistic now, most people do not want to be using Indexeddb directly and pretty much all IndexedDB wrappers will fallback to webSQL. That gets support back to ie9 which is unsupported by most of the web.
And as for WebSockets, HTTP is easier to debug and experiment with, in my experience the performance difference for the typical use cases is negligible and when needed it is trivial to wrap the communication in a socket.