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

[Mark_Noc]

Hello! While testing the docs I'm writing using the Frameless HTML ouput (using the "Orange" theme, but heavily edited and customised), I've noticed that the top breadcrumbs and left-hand Toc take AGES to load (opening the build project locally). Checking the network waterfall using Chrome dev tools, I found that the file "search_auto_map_0.js" is taking a massive 12 seconds on average to download! It's fairly large - at about 900kb in size - but I have images that are larger than that (often multiple PNGs or GIFs on the same page), and they download almost instantly... so I'm not sure why this file is taking so long?

Anyone else encountered this issue? Or have suggestions on how I can speed things up? 

[Jeff_Coatsworth]

I think you're running RH2020, right? Are you all patched up? Check Help > Updates to check.

Have you tried any of the other frameless ones to compare against? Is the sample project acting the same if you use your customized Orange one?

[Mark_Noc]

Hello! Thanks for the reply! Yes, I'm on the latest version (2020.3), and I have tried with un-edted versions of the Orange skin as well as a couple of the other base skins supplied. All of them show the same issue. It's NOT present on any of the samples, but I suspect this is simply because the file itself if a hell of a lot smaller... It appears that the file contains a reference to every single letter, number and symbol in the document, so obviously, with a 350+ page output, there's a lot more info in there than in a 3 page output! However, like I say, the size of the file shouldn't be an issue, as I have GIFs and PNGs bigger than it, and they load super fast. I wonder if this file is generated "on-the-fly" each time the page loads? Certainly, I feel that something weird is going on...

[Mark_Noc]

Going to update this... It turns out that the search_auto_map_0.js file is NOT the issue... it's simply a symptom of the issue. It appears that something in the INDEX is causing the slow page-load times. When I disable the index in the Frameless output "Content" section, pages load in a few milliseconds after building.

Anyone have any idea what could be causing the index to make pages load so slowly? Could it be the size? There are about 250 entries in the index, which - for a document this size - doesn't seem too many (essentially one entry per main page)... 

[Peter Grainge · Accepted solution]

The additional information points to this being the same as reported in another thread.

Re: Chrisi Skin in RH2020 - Adobe Support Community - 11672148

As you will see, the cause has been identified and will be fixed in the next update. I have found there is still some lag (about three second on the test project with a very large index) if the frameless help is local rather than on a webserver and that is being looked into. On a webserver, the response with the fix is pretty much instant.

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

[Mark_Noc]

Thank you very much for the link Peter. As always, incredibly helpful! 🙂 This does indeed sound like the same bug, and I'm really pleased to hear it'll be fixed in a coming update (although it doesn't help me now as I'm scheduled to publish this version of the docs in the next week)... I'll just remove the index for now I think and then re-add it once the bug is fixed. Would prefer millisecond page loads and no index over 12 second page loads and the index! 

Thanks again!

[Peter Grainge]

Is your help installed locally for users or do they access it from a webserver? With the fix the response times with an index are fine.

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

[Mark_Noc]

"Is your help installed locally for users or do they access it from a webserver? With the fix the response times with an index are fine."

Users will be accessing the files locally. Longterm, it'll be hosted on a server, but for at least the near-future, it'll be local only.

[Peter Grainge]

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

[Mark_Noc]

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

[Mike.Walsh.0]

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.

[Peter Grainge]

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_Noc]

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. 🙂

[Mike.Walsh.0]

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.

[Mark_Noc]

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... 🙂

[Peter Grainge]

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

[Peter Grainge]

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

[Mark_Noc · Accepted solution]

Just to confirm, Update 4 has resolved this issue for me and page load times on the Frameless HTML ouput have been massively reduced... 🙂