About html loading (Issue-4626)

Questions
#1

Hi i have some questions about how html loading work.
1)First index.html load engine binaries(wasm or asm)(no progress bar showing ?)
2)Then it show progress bar, while loading content?
3)Progress bar is strange. It is load normal(image 1 - 2, then it set to small value when all content load, image 3 )
Looks like bug=)
112 2
3 3

1 Like
#2

Make a ditry hack to fix progress bar.
Can you please, make a normal fix in engine.
A use html build all day, and bug in progress bar is annoying :grinning:

  updateProgress: function(targetOld) {
        var total_downloaded = 0;
        var targets = this._targets;
       //here was targetOld. And when it load new target,total downloaded was for new target.
       // It does not add prev loaded targets bytes
       // but _totalDownloadBytes is bytes for all targets.
        for(var i=0; i<targets.length; ++i) {
            var target = targets[i];
            for (var p in target.progress) {
                total_downloaded += target.progress[p].downloaded;
            }
        }

        for(i = 0; i<this._onDownloadProgress.length; ++i) {
            this._onDownloadProgress[i](total_downloaded, this._totalDownloadBytes);
        }
    },
1 Like
#3

Created Issue-4626

1 Like
#4

I think there are 2 issues with the progress bar on html5 builds:

  1. Progress bar does not show loading progress of the engine itself. It only shows loading progress of the app archive bundle. For html5 builds, the engine takes up a significant portion of the entire download. So e.g. if you app size is 2MB, and the wasm engine is also 2MB, say it takes 60sec to load everything: for the initial 30sec (50% of the total time) there is no visual indicator what’s happening. For first time visitors, it would appear as if the page is stuck or not doing anything, unless you wait long enough.

Is there a fix for this? How do we include the engine in the progress bar loading status?

Now, gzip server-side can improve things somehow, but that leads to the next issue.

  1. When gzip is enabled (server-side), the progress bar status becomes inaccurate. Since the app archive is being split into 2MB smaller parts, it appears that the first part (arcd0) is not being included in the status updates of the progress bar, or the computation for each individual part is now completely off. It’s not conclusive, but I used Chrome’s developer console to simulate a slow 3G connection to better see the events, and the results are:
  • if app size is less than 2MB (fits inside arcd0): progress bar will not show any progress. So from 0%, wait, then the app is fully loaded (no 10% 20% etc)
  • if app size is e.g. 3MB (arcd0=2MB, arcd1=1MB): progress bar will show progress about mid-way while arcd1 gets downloaded, but as soon as it’s finished (it will finish first before arcd0), the progress bar stops being updated altogether, even if arcd0 is still downloading. So progress bar shows updates from 0% to approx 50% only, then after that no more update.
  • it shows similar results when the app size is bigger, it will show status while some parts (arcdN) files are still downloading, but never reaching 100%

If I disable gzip, then everything is back to normal. It will show progress bar status from 0% to 100% completely before the app is usable.

2 Likes
#5

Interesting findings! Could you please create a ticket on GitHub with this information?

1 Like
#6

Is it possible to universally detect gzip? Check content-encoding header?

I think precomputed gzip size estimates would need to be included and then detect if gzip is enabled? Otherwise estimates could be guessed based on an average compression amount.

#7

Update: Looks like my initial tests were only affecting arcd0 files because that’s the only one being compressed by my server. If I include all arcdX files to be gzipped, basically the progress bar will not show any loading progress. It only shows 0% with no further loading progress, until the app is fully loaded.

So combined with the engine not included in the progress bar, if you have the arcdX files gzipped server-side too, there is really no visual indicator anymore. Template html page with the logo is shown, then basically you have to wait “blankly” until both the engine and the arcdX files are fully loaded. The only visual change is the progress bar will appear at 0% after the engine has been downloaded, but that’s it.

File size savings of the arcdX files being gzipped are significant, so I’d really like to keep this on.

I’ll do more tests tomorrow and create a more accurate ticket.

4 Likes