1265504 - Noticeable (couple of seconds) delay on start of the browser

Status: NEW

(Core :: DOM: Service Workers, defect, P3)

Description

[Matěj Cepl]

Why are ServiceWorkers so slow? It seems like FF on Android first tries network connection and uses SW only as a backup. I way prefer the Chrome-way, SW first. Is there a bug for this?

When opening https://hesla.ceplovi.cz in Firefox for Android (Beta, version 46 ATM) I get couple of seconds waiting and then finally page opens (with or without network connection), with Chromium (51.0.2684.0) on the same phone (Nexus 5 with CyanogenMod 13.0), it opens immediately. I thought that the loading strategy is to blame, but perhaps I am wrong.

See the attached screencast for the example.

Comment 1

[Matěj Cepl]

Screencast of the comparison between Firefox and CHromium is on https://mcepl.fedorapeople.org/tmp/bmo1265504-screencast.mp4

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

I do see a lag on initial page load.  Also, there is a weird page refresh in the middle of the first load.  It seems that related to some language selection feature?

The service worker only kicks in, though, on the second page load.  I don't see any delays there.  I can also take my nexus 5x offline and load the page just fine in airplane mode.

Can you clarify if you are having delays on subsequent loads or just the initial first load on the device?

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Maybe its the initial parse of the require.js <script> element?  Does it help if you make that <script defer>?

Comment 4

[Matěj Cepl]

(In reply to Ben Kelly [:bkelly] from comment #2)
> Can you clarify if you are having delays on subsequent loads or just the
> initial first load on the device?

None of these loads are initial in terms of "I have never seen this page before". Hesla are the Biblical Watchwords in Czech (https://en.wikipedia.org/wiki/Daily_Watchwords) so I am looking at this page every day. Firefox should have these pages in its ServiceWorker "caches" for a long time already.

I can try the language switching, but why in the world it affects Firefox and not Chromium?

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Is the disk full or close to full on this device?  We could be purging the origin for space.

Before loading the page tomorrow can you check about:serviceworkers first?  Just verify that its still installed as expected before opening the page.

Also, do you have any developer tools or addons enabled to bypass http cache or anything?  We've had some bad interactions with those in the past.

So far I have not been able to reproduce the delay on loading after initially opening the page.

Thanks.

Comment 6

[Matěj Cepl]

When I've made this change in my template https://gitlab.com/mcepl/hesla/commit/af12ad7098fc53d1385508ee340ac82f62d92488 I can see exactly same.

I have loaded and reloaded the page couple of times (to be sure, that I have flushed old SW caches), and then I killed Firefox (swipe out in the task list of Android). On restart of Firefox I see the same delay. When I press reload button in the Firefox chrome, I get the result immediately, but I guess is the case of regular browser cache not ServiceWorkers, right?

Comment 7

[Matěj Cepl]

I don't think there is anything strange with the storage:

matej@mitmanek: hesla (master)$ adb shell df -h
Filesystem                                    Size  Used Avail Use% Mounted on
tmpfs                                         927M   92K  927M   1% /dev
none                                          927M   20K  927M   1% /sys/fs/cgroup
tmpfs                                         927M     0  927M   0% /mnt
/dev/block/platform/msm_sdcc.1/by-name/system 0.9G  519M  491M  52% /system
/dev/block/mmcblk0p27                         690M   13M  677M   2% /cache
/dev/block/mmcblk0p1                           64M   44M   20M  70% /firmware
tmpfs                                         927M     0  927M   0% /storage
/dev/block/dm-0                                13G  8.3G  4.2G  67% /data
/dev/fuse                                      13G  8.3G  4.2G  67% /storage/emulated
matej@mitmanek: hesla (master)$

Comment 8

[Matěj Cepl]

Attachment: about:serviceworkers

Comment 9

[Matěj Cepl]

Attachment: about:addons

Comment 10

[Matěj Cepl]

Attachment: about:support from the phone

Comment 11

[Matěj Cepl]

Even with this change https://gitlab.com/mcepl/hesla/commit/6ebfe7801ac807ba42189afde745f707333b82dd (and again multiple reloads) I get the same behavior.

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

I'm still trying to reliably reproduce this.  This is what I see:

1) Install Firefox Beta from Google Play
2) Navigate to https://hesla.ceplovi.cz/
3) Experience slow load times
4) Immediate navigation to https://hesla.ceplovi.cz/index.html due to window.location being modified
5) Reload page without any delay.
6) Open page in new tab without delay
7) Kill Firefox Beta, restart it, and open page without delay
8) Enter airplane mode and can still open page without delay.

From what I understand you are still seeing the delay in steps 5, 6, and 7.

Can you open the page in airplane mode?

One thought I had was that it could be a very slow service worker installation for some reason, but your about:serviceworkers shows that its installed.  So that's not it.

By the way, I noticed that you are allowing http cache to cache your service worker script.  So you may not be getting it updated on the device.  You either need to explicitly unregister it in about:serviceworkers or wait for 24 hours for service worker manager to bypass the http cache.  In the future you might want to serve a max-age:0 header on the service worker script itself to make it easier to update.

One other thing I noticed that would help with the initial load time would be serving compressed resources.  Right now the large index.html and require.js scripts are served in plaintext.  They could benefit a lot from gzip encoding.  That won't affect loads from service workers, of course, though.

Are you able to attach to the device using your desktop firefox devtools?  I think it might be documented here:

  https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Debugging_Firefox_for_Android_with_WebIDE

Perhaps you could capture a performance timeline trace of the load?  I'm not sure if that will provide enough information or not, but could help.  Thanks!

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

I have to leave for dinner, but I need to investigate something tomorrow:

* In FF45 I can open the service worker script at https://hesla.ceplovi.cz/sworker.js
* In FF47 dev edition I cannot open the service worker script because I get the service worker "content corrupted" page

I think the FF47 behavior is correct because the service worker script does not return a response for that URL.

So what is FF45 doing?  Its like its bypassing the service worker for some reason...

Comment 14

[Matěj Cepl]

Actually, after some more testing, I think I see a possible error in my thinking: in order to reproduce my situation you have to kill Firefox completely (by swiping it out in the task list), not just closing the tab. With Firefox running and when just opening a new tab with https://hesla.ceplovi.cz I get pretty instantaneous activation as well. So perhaps whole that long delay in the beginning is not ServiceWorkers and my app, but something going on with the whole Firefox loading. And yes, of course, it doesn't help when one has an application’s shortcut on the desktop.

Comment 15

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Ben Kelly [:bkelly] from comment #13)
> * In FF45 I can open the service worker script at
> https://hesla.ceplovi.cz/sworker.js
> * In FF47 dev edition I cannot open the service worker script because I get
> the service worker "content corrupted" page
> 
> I think the FF47 behavior is correct because the service worker script does
> not return a response for that URL.
> 
> So what is FF45 doing?  Its like its bypassing the service worker for some
> reason...

It turns out I had some non-standard prefs set in my FF45 profile that disabled interception.  Once I turned those off things worked correctly.

In regards to overall firefox app startup, we can test that by bookmarking a very small page to the homescreen.  Can you:

1) Make a homescreen bookmark for something like https://example.com
2) Force kill firefox by swiping right in the task list
3) Launch the example.com bookmark and check for delays

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

For what its worth, using the steps in comment 15 I do see a couple second delay on my nexus 5x for an example.com homescreen bookmark.

I see a slightly slower load for hesla.ceplovi.cz.  My best guess is this is due to loading/parsing the large index.html.

Margaret, do we have any bugs open on firefox for android launch time?  My quick search did not find anything.

Comment 17

[Matěj Cepl]

(In reply to Ben Kelly [:bkelly] from comment #16)
> For what its worth, using the steps in comment 15 I do see a couple second
> delay on my nexus 5x for an example.com homescreen bookmark.

me too (WTH, there is now example.com website? I thought it is guaranteed not to exist?)

> I see a slightly slower load for hesla.ceplovi.cz.  My best guess is this is
> due to loading/parsing the large index.html.

Really, in time of multiprocessor CPUs, gigabytes of memory, there is a problem with parsing 285K of rather simple HTML?

Thinking about it, is there a penalty for having many (here, all inside of <body>) elements of HTML with "display:none"?

Comment 18

[:Margaret Leibovic]

(In reply to Ben Kelly [:bkelly] from comment #16)

> Margaret, do we have any bugs open on firefox for android launch time?  My
> quick search did not find anything.

We do know that Gecko can be slow to start up, but I don't know that we have any active bugs tracking that.

snorp's team was working on this as an initiative at some point, maybe he has more details to provide.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

(In reply to Ben Kelly [:bkelly] from comment #16)
> Margaret, do we have any bugs open on firefox for android launch time?  My
> quick search did not find anything.

Bug 959776 covers Fennec startup performance.