1531373 - Panomoments is slow too load

Status: RESOLVED INVALID

(Core :: DOM: Networking, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

+++ This bug was initially created as a clone of Bug #1529812 +++

Panomoment pages such as: https://my.panomoments.com/u/dustinkerstein/m/split-croatia-harbor?hideInfo=1 is slow to load

See https://bugzilla.mozilla.org/show_bug.cgi?id=1529812#c2

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Profile from https://bugzilla.mozilla.org/show_bug.cgi?id=1529812#c2 http://bit.ly/2T3I780

Comment 2

[Denis Palmeiro [:denispal]]

comment meant for another bug

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

http://bit.ly/2EoaMdt on linux. Page load looks rather fast here, but then the spinner takes some time still.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

It seems like the page is using fetch (+ streams ?) on Chrome, but xhr on Firefox.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Aha, we do have streams enabled, and response.body should work.
There is something else here still. Why we're getting xhr and Chrome fetch and loading it using several pieces.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Could someone from webcompat take a look at this.

Based on network panels in browsers, Chrome loads some large mp4 using fetch, and Nightly using xhr.

Comment 7

[Mike Taylor [:miketaylr]]

Tom, xhr is your jam. Can you take a look?

Comment 8

[Thomas Wisniewski [:twisniewski]]

Sure, it's now in my diagnosis queue.

Comment 9

[Chris Peterson [:cpeterson]]

(In reply to Olli Pettay [:smaug] from comment #3)

http://bit.ly/2EoaMdt on linux. Page load looks rather fast here, but then the spinner takes some time still.

Yes, by "slow to load", I did mean the loading spinner's duration when clicking between HD and UHD buttons, not the page's initial load.

Switching between HD and UHD on my Windows laptop and MacBook Pro, Chrome loads the HD scene in 1 second and UHD in 2 seconds. Firefox 67 Nightly loads the HD scene in 6 seconds and UDH in 9 seconds.

Comment 10

[Thomas Wisniewski [:twisniewski]]

The stack trace for the XHR leads me to this code in this script:

case 14:
        c = f.sent,
        l = new Uint8Array(c),
        (d = new Int8Array(t.length + l.length)).set(t),
        d.set(l, t.length),
        n.startFrameInitialized = !0,
        r.MSE ? ((0, x["default"])(c, r.newIndex, r), (0, E["default"])(d, n, r), r.downloadRanges = (0, w["default"])(r.segments, r.initialFrameset, r.initialFramesetIndices, !1), n.delayedLoad || (0, b["default"])(r.file, n, r, 1))
              : (n.video.src = window.URL.createObjectURL(new Blob([d], {type: "video/mp4"})), n.video.pause(), r.forceTextureUpdates = !0, n.delayedLoad || n.nonStreamingXHR.send()),
        n.delayedLoad && (0, m["default"])(".initial-cover-title").removeClass("hidden"),
        s = !0,
        f.next = 29;
        break;

The value of r.MSE is false in Firefox, so that's why it takes the XHr path.

This is where the value is computed:

    {
        key: "configureMSE",
        value: function() {
            navigator.userAgent.match(/Android/i) ? I.android = !0 : navigator.userAgent.match(/iPhone|iPad|iPod/i) && (I.iOS = !0);
            var e = !1;
            D.getDevice().model && (e = D.getDevice().model.indexOf("SM-G96") > -1), "Chrome WebView" != D.getBrowser().name && "Chrome" != D.getBrowser().name && "Chromium" != D.getBrowser().name || !(I.android || parseInt(D.getBrowser().version, 10) >= 64 || parseInt(D.getBrowser().version, 10) < 62) || I.iOS || e || (I.MSE = !0)
        }
    }

So the decision is based on user-agent sniffing.

However, even if I have that check set I.MSE = true for Firefox, I'm not getting any better results from the page. The fetches are taking place, but the loading spinner on the page still takes longer to go away than it does in Chrome, plus Firefox only ends up displaying a black background, never showing the video. Outright spoofing as Chrome also doesn't improve the result, nor do I see anything interesting logged in the console.

I'm not sure if that's a sign that we ought to do some outreach, or if we should take a stab at diagnosing this further. Thoughts, Mike?

Comment 11

[Mike Taylor [:miketaylr]]

Olli, given Comment #10 (the fact that fetch appears to do not improve things over xhr), should we punt this to someone to profile... something else?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Well, this is a qf bug already, so it should get handled.

Comment 13

[Nils Ohlmeier [:drno]]

(In reply to Chris Peterson [:cpeterson] from comment #9)

(In reply to Olli Pettay [:smaug] from comment #3)

http://bit.ly/2EoaMdt on linux. Page load looks rather fast here, but then the spinner takes some time still.

Yes, by "slow to load", I did mean the loading spinner's duration when clicking between HD and UHD buttons, not the page's initial load.

Switching between HD and UHD on my Windows laptop and MacBook Pro, Chrome loads the HD scene in 1 second and UHD in 2 seconds. Firefox 67 Nightly loads the HD scene in 6 seconds and UDH in 9 seconds.

Same problem as with the initial page load: in Firefox it uses xhr to load 157MB, which obviously takes a lot of time. In Chrome it uses fetch to load lots of smaller chunks of data. And the spinner dis-appears in Chrome while it continues to load more data in the background.

Comment 14

[dustin.kerstein]

This is Dustin from PanoMoments - I just added some info to the other bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1529812

Comment 15

[Dragana Damjanovic [:dragana]]

I will close this bug because of the comment 13. I also tested it myself and it just take loong to load resource.