Ways to speed up our html viewer
New here? Learn about Bountify and follow @bountify to get notified of new bounties! x

We convert pdfs to html and use this viewer called IDR. We are noticing some performance issues with it. I have loaded an example here

https://dt01nxr452nmg.cloudfront.net/bench-srg-CDN/SRG_Oct2019_6June2019/index.html?page=1

from the waterfall you can notice that while the document preloads 10 pages to help with quick user scrolling it seems and feels like its taking more time than needed to load this. I am thinking there is something in the page js that is blocking it but I cant narrow down the issue or fix for it.

I see 45 requests on page load, just 312kb transfered yet we got about 4 seconds for it to finish. I made sure we are using http/2 to fix the pipeline issue but I still see this stairstep which was my hint that maybe something else is working against me

https://www.dropbox.com/s/up8zql34lsevi0x/2019-06-18_16-58-14.png?dl=0

and here is the zip of the files if you want to try them locally

https://crts-versions.s3.amazonaws.com/SRG_Oct2019_6June2019.zip

This bounty is for a patch to the js or otherwise pointer that can help us make this thing load a bit more quickly. We can accept 2 winners here

1- $100

2- $50

Quick hack: in the idrviewer.js file search for the following code: var a,b,c,d={},e=500,f=50,... and change the e variable from 500 to 0: var a,b,c,d={},e=0,f=50,... This will save you a couple of seconds
kostasx 1 month ago
Kostasx- post it as an answer. I’ll test it tomorrow . Thx as always!
Qdev 1 month ago
awarded to Wuddrum

Crowdsource coding tasks.

3 Solutions


My solution was going down the wrong path. @kostaxe posted a good solution in the comments above, which I just verified as cutting 2s off of the time. I didn't see any config variable that would affect this timeout delay, so a hack of the vendor file appears to be needed. You might want to contact the vendor first to see what the purpose of the 500ms delay is and whether they might provide a configuration to override it. Kostaxe should post this as an answer since it's deserving of the bounty.


You can find the following code in the idrviewer.js file and update it as follows:

var a,b,c,d={},e=500,f=50,...

and change the e variable from 500 to 0:

var a,b,c,d={},e=0,f=50,...

This will cut down the loading time by a couple of seconds.

hey Kostasx here is the updated version
https://dt01nxr452nmg.cloudfront.net/bench-srg-gzip-optimized/SRG_Oct2019_6June2019/index.html?page=1 I resolved the annotation file and favico 404's and with your change things seem to be faster. I was wondering if you had any thoughts on some of these gaps now? https://www.dropbox.com/s/elnuzsxpc05ww9x/2019-06-19_08-52-57.png?dl=0
Qdev 1 month ago
It's pretty hard to say at the moment, as these gaps indicate "...a time when no requests happen. This can be e.g. due to a javascript execution on the page, which blocks page download or page rendering, CSS resolving, etc." (Source: https://stackoverflow.com/questions/4991167/gaps-in-firebug-waterfall-chart) A closer look at the internals of the IDR viewer and the contents of the html files being fetched might shed some light on these gaps.
kostasx 1 month ago
Winning solution

While kostasx has found the root problem of the delays, setting e=0 might not be the best solution.

The function that's called with setTimeout is recalling itself at its last line, using setTimeout and sourcing e as the interval. This ends up re-executing the function non-stop, without any delays, even when the browser is idle.

A better solution might be to change setPage and stopLoading (not required) functions' setTimeout interval manually to 0, instead of sourcing it from variable e. When navigating to a page, this will instantaneously load the page and its preceding and following pages, instead of waiting on a 500ms+ throttle.

idrviewer.js with above changes: Pastebin

The 500ms throttle will still remain, keeping the function from executing non-stop. This however also means that any page that's not directly preceding or following the current page will also still load with a 500ms delay inbetween them. From the testing that I've done, it still performs well on decent connection speeds.

If the viewer is expected to be loaded on bad connection speeds then it might help to set the variable e to some sane value, like 100. This will help the pages to load a bit faster and still keep the function from executing non-stop without any delay.

All of the above changes: Pastebin

Another thing to consider: The delay is set to also function somewhat as a debounce, to defer requests to pages that the user is quickly scrolling by and might not actually need them loaded. While using 0 or low values for timeouts is working fine on decent connection speeds, a problem might arise with very slow connections. Where scrolling the document might end up making a queue of not-needed network requests that need to finish before finally loading the page that the user has decided to stop on.

View Timeline