In ServiceWorker mode, render the page before extracting all resources

[mossroy]

In ServiceWorker mode, the browser prioritize the requests by itself, just like #412 tries to do in jQuery mode : HTML, then CSS, then visible images, then other images.
But, for some reason, the page does not render before all images are read.
On big pages, it would be a much better user feeling to be able to read the beginning of it, while the rest is read from the ZIM file. Just like browsers do on any online page.

[Jaifroid]

Yes, I noticed this render issue, easily reproducible with "Trigonometric Functions" in the latest Wikipedia mathematics ZIM. Or with "Paris" in full Wikipedia. I thought it was a case of waiting for the stylesheets, but since the same happens when revisiting the same page (with the stylesheets now cached), it must be a rendering delay. Did we introduce this issue with #385 ? Or has it always been that way?

[Jaifroid]

Ah, I've found an interesting difference! In Edge, in Service Worker mode, if you load a page by searching for it, we get the behaviour you describe. But if you load a page by clicking on a link in an article, I see the whole process of page composition, starting with the text and no stylesheet, then some images, then the stylesheets, etc. However, this isn't the case in Firefox Quantum. I haven't checked Chromium. It seems that Edge doesn't pause the rendering when clicking on a link, whereas Firefox does. When we load a page from the search field, then the article DOM is hidden, explaining why I don't see the composition process in Edge either in that case. But what causes it to render in Service Worker mode? Could we bring that moment forward in the process?

EDIT: I confirm that Chromium behaves like Firefox, and IE doesn't support Service Worker, so irrelevant.

[mossroy]

Interesting. You're right about the fact that there's a different behavior between a click on a search result and a click on a link inside a page.
It's because, in Service Worker mode, in readArticle function of app.js, we show the iframe content only after it has finished loading (through its onload event). Afterwards, the iframe remains visible all the time, and clicks on hyperlinks inside articles are not affected.
I think we could display the iframe immediately, without waiting for the onload event.
A quick test on Firefox and Chromium does not show any drawback on the askubuntu or stackoverflow main page.

Regarding the clicks on hyperlinks inside articles, it seems to me that Chromium does have the expected behavior : if you open a big wikipedia article (like the ones you were mentioning), and scroll to the bottom of the page as soon as it is displayed, you can see that the images appear afterwards. And the console logs seem to confirm that.
I've pushed a new branch https://github.com/kiwix/kiwix-js/tree/display-article-immediately-after-search-in-serviceworker-mode, where it is more obvious, as the spinner stays until the content is fully loaded.

On, Firefox, reading such big articles is much quicker, and they seem to have a different strategy.

[mossroy]

On wikipedia_fr_all_novid_2018-03.zim, if I try to open the article "Paris" :

• on Chromium, it takes 4s to have a first display of the article (with missing images), and 14 more seconds for all the resources to be loaded (which makes a total of 18s)
• on Firefox, it takes 7s to display everything

In any case, I suppose we won't have much influence on the rendering strategy of the browsers.
I'll create a PR from the branch to fix the behavior after a search.