When I do cargo doc --open or open docs after generating them, the browser (firefox) takes about 10 seconds load the page. Any subsequent page takes about 10 seconds as well, making the docs unusable. I tried in chromium and I get the same problem, but only about 1 second. I've done a perf test, and the time is taken up building the search index.
Is this a known problem? Any way round it?
I have this problem too with the online docs. Large pages like Iterator will actually crash my phone's browser (assuming it runs out of memory). Firefox for Android has the most problems with it. Mozilla's new GeckoView does better though.
Looks like this issue, which has had some work on it but it sounds like there's more to investigate and fix.
Also possibly related. Have the docs always been slow for you, or did this change recently, do you remember?
For me, it has started recently. It isn't #55900, because it happens on e.g. this page which is only 50kiB of HTML. I haven't been able to catch the offender in the JS debugger, but it sure looks like a script going nuts. Hangs my pages for many seconds at a time. (I'm using Chromium.)
So #57754 seems more likely.
My current workaround is to ^W the tab and then ^Shift-T to reopen it; if I do this a couple times it quits hanging. Ewww. 
I suspect it is #57754. I'm not sure if there's an easy solution - because all the obvious ways to fix the problem involve running a webserver, which would mean you can't just browse the docs on file:// any more.
So, to be clear, this happens to me on docs.rs too -- it isn't simply an issue with cargo doc --open.
For example, I can't load this page right now, it hangs Chrome.
Seeing this on the html5ever docs right now too. It's actually crashing Chrome and showing the "Aw Snap!" page. Sometimes I can load it after waiting for a second but it inevitably crashes if I go to a few other pages or try to search something.
I think the solution to this problem is actually an opportunity to use wasm in the docs! The search index can be essentially a block of binary data, so the javascript engine doesn't have to compile it. We can then compile it in wasm. (or if not, then in a worker thread in js)