3 Replies Latest reply on Apr 10, 2016 5:05 AM by Ioana_St

    RH2015 - Loading and search optimization

    Ioana_St Level 1



      Environment: RH 2015, generating merged WebHelp - almost 40 RH projects in total and 7000 topics.


      Issue: loading the TOC and searching are very slow, and I need to figure out how to optimize them. However, I don't quite understand how they work, so I am hoping that someone on the forums could give me some pointers.


      Current situation:

      I've been testing this for a few weeks - some results below.


      First TOC load:

      • Local machine:
        • IE 11 - 25 seconds
        • Chrome - 2 seconds
      • Client-facing site:
        • IE - 20 seconds
        • Chrome - 10 seconds


      First search:

      • Local machine:
        • Both IE and Chrome - 2 seconds.
      • Client-facing site:
        • Both IE and Chrome - 25 seconds.


      In the search settings, I have enabled highlighting, showing context, hiding the rank column and showing the total number of search results. (No substring search.) Enabling the AND option by default didn't seem to change the speed. Because we include a PDF version of each online help module, I also tried to exclude the PDFs from search, but that didn't make a difference either.

      (I also tried to generate the same content in HTML5 format, and the TOC did load faster, but the search takes 2x as long...)


      Unfortunately our client-facing site is password-protected, so I can't provide the link.



      1. As far as I can tell, a bunch of JS files in the wh* folders are loaded for the TOC and the search - am I on the right track? Does anyone know exactly how these files are generated? I opened the Developer Console in Chrome while searching for a term and it looks like loading one JS takes a couple of milliseconds, but there are so many files that it adds up to almost half a minute.
      2. If I were to decrease the number of RH modules (say, 20 instead of 40), would that make a difference, or would I basically have the same number of JS files in total, just placed in different folders?
      3. If I were to decrease the number of topics, would that help?
      4. Is there something I can do to make the content load faster on IE? There is a big difference compared to Chrome, and most of our clients use IE...


      Thanks a lot in advance!

        • 1. Re: RH2015 - Loading and search optimization
          Willam van Weelden Level 5

          There are multiple issues at play here that impact the performance: the amount of topics, merged help and server performance.


          In the WebHelp output, you can select speed optimization options. Try setting that option to 'Local network', even though you are publishing on the web. This option controls whether you have more and smaller wh* files or larger but fewer wh* files. Network speeds have increased in such a way that you can use the Local Network option. And there is an additional benefit: every file that has to be loaded requires a download from the server. And having a lot of downloads for many smaller files is much slower than fewer calls for larger files. That is because for every file on the server, the server must read the file and send it back to the client. If the server can do this with larger files, you can benefit from the improved internet connections of the last 10 years. Having a fast internet connection doesn't fix the issue where you have to retrieve lots of small files.


          Secondly, merged help adds a huge overhead on download times. Basically, RoboHelp loads the master project. And then it will do all the load steps for every merged project as well. This slows down the process immensely. This is due to the scripts in merged help, but also because of the issue I outlined before. Cutting down on the number of merged projects by moving it into fewer, larger projects, will also help.


          Thirdly, you can cut down on content to speed up searches. For search, the number of topics is irrelevant. What is relevant is the amount of content. When you have fewer topics with more content, the search database will have the same size as more topics with less content. Of course, having fewer topics also reduces TOC entries and that will speed TOC loading. Searching is further impacted by the number of merged projects. Just remember: merged projects means lots of overhead.


          For the client facing site, your computer needs to download the files from the remote server. For local help, the browser can access all content immediately from disk. If your server isn't caching, you get a lot of overhead on the server side, slowing things down. And if the server has a slow upload connection (server upload max is your download max), that will further slow the process down. Especially if you have multiple people trying to access the content at the same time, the server has to process a lot of requests. Though for any moderately modern server, the requests shouldn't be an issue.

          • 2. Re: RH2015 - Loading and search optimization
            Ioana_St Level 1

            Thank you so much, Willam! You even answered some question I hadn't thought of! I will try the LAN option next week, and we will start prioritizing the TOC reorganization (we do have a ton of small topics that could be merged into larger ones).

            • 3. Re: RH2015 - Loading and search optimization
              Ioana_St Level 1

              Some results, in case anyone else is struggling with the same thing...


              After regenerating the help with the LAN option, I did get about 6 times fewer package*.js files, but unfortunately it hasn't made a big difference in loading and search times. I think our main problem is the large number of merged projects - I used the Developer Tools in Chrome to see what's happening when the TOC is loading or when you do a search, and it looks like there are some "default" files that are loaded every time, regardless of the number of packages (when searching, 4-5 JS files are always called per merged project; I haven't done the math for loading the TOC).


              In the end, we have decided to go with an external search (Zoom), while also trying to cut down the number of merged projects to speed up the TOC loading.