We are currently experimenting with deployment to HTML5 and are facing long loading times of the application on the users side (after the network transfer, mostly the compilation of the java script).
Even with a simple use case such as a 3D object viewer with limited interactivity (navigation, selection, highlighting) we were not able to reduce the size of the application below 28 MB zipped, which includes 50 MB unzipped java script. As far as we know we excluded all unnecessary plugins, modules, and assets. This results in loading times of 20 to 40 seconds in the browser (depending on the machine).
Are there ways to improve the loading performance we are possibly not aware of?
Are there any plans at EPIC to improve the loading performance of HTML5 applications in the near future?
Regarding your question, we received this information from our partners at Mozilla
For this case, it’s difficult to say
what causes the long loading time,
though Stephan’s original message
mentions that it was mostly time take
in the compilation of the JavaScript
(asm.js module?). This reminds we had
a performance bug in Firefox register
allocator which caused slow asm.js
compilation times on some pages. See 1246132 - asm.js compilation takes a very long time on AdVenture Capitalist Facebook asm.js game.
The fix went in to Firefox 47 release,
which is due in release channel on the
7th of June. If the offending page
shows an asm.js compilation message
that says that one of the functions
compiled very slowly, then it could
have been caused by that bug. It is
worth checking if Firefox Nightly
opens the page any faster, since that
has the above bug fix in. If there is
no difference, then it is something
else.
Is the page available somewhere to
test? (offline zip build perhaps they
could send over?)
In Firefox Nightly the page opens indeed a bit faster (ca. 17s on our fastest machine). This asm.js message is shown:
“Successfully compiled asm.js code (total compilation time 7803ms; stored in cache; 1 functions compiled slowly: tJp:39 (252ms))”
On subsequential reloads the asm.js is loaded from cache in like 700ms and the total reloading time is reduced by 7s.
Profiled the test page I got in email, thanks for that. The result I noticed is that most of the time of the startup, > 70%, is spent on shader Direct3D shader compilation (testing on a NVidia GTX 980 on Windows 10). On my system, which is a fairly beefy setup, on Firefox Nightly 64-bit, the page loads in less than two seconds.
I would recommend trying out the geckoprofiler add-on on Firefox to verify how it looks like on your systems, see Performance — Firefox Source Docs documentation. This gives a nice way to look at the samples. On my system, time spent in D3DCompiler_47.dll dominates the loading time. To improve that, I fear the only way would be to compile less shaders, but I’m not sure how well that is possible in UE4 user code, or if the shaders are automatically compiled and used under the hood?