Frameless HTML - search_auto_map_0.js taking 12 seconds to load (RoboHelp 2020)

In this or the other thread I posted a few days ago that Adobe have already acknowledged this is a bug that will be fixed in the next update. 

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

There is only one index. The only option is to trash all entries. 

Maybe if you move it to another location as a backup and then restart RoboHelp it will create a new empty file. 

Proceed with caution here. 

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

Mike, sorry I misunderstood... I haven't tried creating a new index from scratch but I will now you've mentioned it (although if Adobe confirms its a bug I suspect it'll be the same... but no harm in testing!). I'll let yo know how it goes. I have also thought about using the responsive skins, but the Frameless one I'm using is highly customised for the brand I'm working for, and as such it would require a fair bit of time to get a new skin to the same standard and then get it approved, and time is sadly something I don't have. As for CHM, the client-base for the product actually expect HMTL, CHM and PDF, and I'll be outputting all 3! Basically, some people like to print the manual (pdf), some like the old-school-feel manual (chm), and some people like to copy the files to mobile devices for browsing or just prefer using a browser (HTML). You can't please all the people all the time, but we're apparently going to try... 🙂

Mark, your results from shrinking the index are interesting. Hopefully, the 4th update resolves this. But note that I wasn't suggesting that you shrink the index. I was suggesting creating a new index from scratch to see if the results improved. This is based on the suspicion that the index was somehow corrupted, perhaps during the conversion from classic to the new UI (or even before that).

Note that this index bug is not an issue with Responsive HTML5, so perhaps that's an option for you in the meantime.

It's interesting that your users run help locally. Have you considered MS HtmlHelp as the output? It's an old format, but it is efficient and was designed to be run locally and is still supported in the new RH UI and by MS in Win 10.

Mike: Thanks for the reply! Shrinking the index does indeed improve performance... I tested by simply trimming out some items that weren't really essential and got the page load times down to about 9 seconds. So, yes, the size of the index definitely makes a difference! However, further testing has shown me that to get any acceptable performance (less than 5 seconds I would consider acceptable, although still not ideal) would mean sacrificing a LOT of the index entries that are important, which isn't really something I want to do. In the end, we've decided that for this first iteration of the documentation we'd rather ship without the index altogther and have a better UX than ship with it and risk a poor user UX or provide only half the functionality required. Once Adobe release the next update I'll review the situation and see how it goes. 🙂

A smaller index will make a difference but if the plan is to recreate the same index, I don't think that will help. Adobe are working on this and the difference is already significant. Personally on this one I would be waiting to see if further improvement can be made. 

The only reason I would shrink my index would be if I had to get frameless out the door before any more news is forthcoming. Then I would copy the project as the last step and shrink the index as the last job. Then you can revert to the copy with the full index rather than manually recreating it. Alternatively edit a copy of the idx file in a text editor. 

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

Mark: I've had the same problem, but I'm wondering what the performance would be like with a brand new index. I haven't tried this, but perhaps you could create new index with 50 terms and check the performance. If that's ok, try adding another 50 terms. I realize that's a hassle, but that might solve the problem.

Okay! 3 seconds is LOT better than the 12-15 seconds right now... 🙂

I think you will find it passable with the fix, albeit not as quick as you might want. The topic loads quickly, it's the TOC refresh that has this slight lag at the moment. Hopefully that too can be fixed.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information