Open Bug 1952108 Opened 7 months ago Updated 4 days ago

Fenix does a bunch of network requests during applink startup

Categories

(Firefox for Android :: Performance, defect)

Product:
Firefox for Android
Component:
Performance
Platform:
All
Android
Type:
defect

Tracking

()

People

(Reporter: jrmuizel, Unassigned, NeedInfo)

References

(Depends on 4 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: [fxdroid][group1])

Stuff like:
https://contile.services.mozilla.com/v1/tiles
https://firefox-android-home-recommendations.getpocket.com/
https://spocs.getpocket.com/spocs?site=1240699

If we need to do these on startup it would be good to delay them until after we've started loading the desired page first.

See https://share.firefox.dev/3QNNzXO

Blocks: applink-startup
Component: General → Performance
Whiteboard: [fxdroid][group1]
Depends on: 1954207
Blocks: perf-android

The severity field is not set for this bug.
:kaya, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(kkaya)
Depends on: 1956968

(In reply to Andrew Creskey [:acreskey] from comment #1)

wallpapers, https://assets.mozilla.net/mobile-wallpapers/metadata/v1/wallpapers.json

I've filed bug 1956968 about this one.

There's also telemetry being sent early at startup - for example in this profile https://share.firefox.dev/3Z8Er4C

Severity: -- → S3
Flags: needinfo?(kkaya)
Depends on: 1965899

(In reply to Valentin Gosu [:valentin] (he/him) from comment #4)

There's also telemetry being sent early at startup - for example in this profile https://share.firefox.dev/3Z8Er4C

I logged the telemetry requests here
https://bugzilla.mozilla.org/show_bug.cgi?id=1965899

Depends on: 1968585

In the location services request bug Markus pointed out that we make a different set of request in the Play Store builds vs Try.

Here's a profile from the Release Play Store Build (the target shopify url is load 12)
https://share.firefox.dev/4jno8Z5
We've since fixed the very early calls to http://detectportal.firefox.com/success.txt?ipv4 in bug 1956081

notes from synchronous discussion:

The requests like contiles request can be delayed if we are doing a "nav app link". The requests are happening in TopSitesRefresher and are done when the HomeActivity is resumed.

The wallpaper request no longer happens, as was resolved in bug 1961394.

The specifics of how we can properly defer the requests, is TBD. Just wanted to add these notes here.

EDIT (June 16, 2025): we also have some top sites operation in FenixApplication

Duplicate of this bug: 1954207

I've collected new applink startup profiles to see where we are on remaining network requests that precede or run in parallel with the app link url.
In the profiles below I launched Firefox and let it sit idle for a few minutes before running the test.

Fenix nightly build from Taskcluster, i.e. https://firefox-ci-tc.services.mozilla.com/tasks/index/gecko.v2.mozilla-central.latest.mobile/fenix-nightly

Profile:
https://share.firefox.dev/3FAiLrQ

Load 1: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-telemetry-v2/records
Load 3: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/events/1/ba16cff9-b325-4cef-8a7c-b8135319ff84

.. then Shopify, app link target ..
Load 5: https://theme-crave-demo.myshopify.com/

Load 7: https://content-signature-2.cdn.mozilla.net/g/chains/202402/remote-settings.content-signature.mozilla.org-2025-07-10-19-04-54.chain
Load 8: https://content-signature-2.cdn.mozilla.net/g/chains/202402/remote-settings.content-signature.mozilla.org-2025-07-10-19-04-54.chain
Load 10: http://detectportal.firefox.com/success.txt?ipv4
Load 11: http://detectportal.firefox.com/success.txt?ipv6
Load 12: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/baseline/1/b8045916-8716-4e15-973e-d38912461ecb
Load 15: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/nimbus/1/853ed5ed-38b7-4c5e-89b1-1c27d4ae4f44

.. then Shopify sub resources ..
Load 3: https://theme-crave-demo.myshopify.com/cdn/shop/t/44/assets/global.js?v=138967679220690932761727898657
(many)
...
Load 46: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/usage-reporting/1/63f90fb0-eb70-4c0e-a6a7-61842c0a4554
Load 47: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/baseline/1/7938925f-c252-4545-8f44-96080b003ff1
Load 48: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/pageload/1/a74468da-ccda-4952-b55e-18017afd8e05
... then more Shopify subresources ...
Load 61: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/use-counters/1/d6a2d5cc-605b-4ac7-85bd-a2047ed86983
... then wallpapers.json
Load 62: https://assets.mozilla.net/mobile-wallpapers/metadata/v1/wallpapers.json
... then more settings
Load 63: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/quicksuggest-other/changeset?_expected=0&_since=%221748540449709%22
... then more Shopify subresources...
... and finally one more settings ...
Load 86: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/quicksuggest-amp/changeset?_expected=0&_since=%221749579643875%22

And here's Fenix nightly from Google Play Store
https://share.firefox.dev/3FMbCoo
To me, this looks similar to the Taskcluster nightly in terms of early network requests.

So in terms of resources competing with the applink Shopify content, I am seeing these requests

Load 1: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-telemetry-v2/records
Load 3: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/events/1/ba16cff9-b325-4cef-8a7c-b8135319ff84
Load 7: https://content-signature-2.cdn.mozilla.net/g/chains/202402/remote-settings.content-signature.mozilla.org-2025-07-10-19-04-54.chain
Load 8: https://content-signature-2.cdn.mozilla.net/g/chains/202402/remote-settings.content-signature.mozilla.org-2025-07-10-19-04-54.chain
Load 10: http://detectportal.firefox.com/success.txt?ipv4
Load 11: http://detectportal.firefox.com/success.txt?ipv6
Load 12: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/baseline/1/b8045916-8716-4e15-973e-d38912461ecb
Load 15: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/nimbus/1/853ed5ed-38b7-4c5e-89b1-1c27d4ae4f44
Load 46: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/usage-reporting/1/63f90fb0-eb70-4c0e-a6a7-61842c0a4554
Load 47: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/baseline/1/7938925f-c252-4545-8f44-96080b003ff1
Load 48: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/pageload/1/a74468da-ccda-4952-b55e-18017afd8e05
Load 61: https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/use-counters/1/d6a2d5cc-605b-4ac7-85bd-a2047ed86983
Load 62: https://assets.mozilla.net/mobile-wallpapers/metadata/v1/wallpapers.json
Load 63: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/quicksuggest-other/changeset?_expected=0&_since=%221748540449709%22
Load 86: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/quicksuggest-amp/changeset?_expected=0&_since=%221749579643875%22

Seeing resources like the wallpaper.json move from Load 1 to Load 62 is likely beneficial, although note that it's still arriving before some important content images such as this one:
https://theme-crave-demo.myshopify.com/cdn/shop/files/CRAVE_95cb960d-0933-4ba8-b51a-3c4853b96029.png?v=1642089232

See Also: → 1966977

I'm wondering if instead of browser-idle-startup-tasks-finished we'd need something like a idle-after-first-pageload notification. I'm imagining this would be triggered immediately if you just open a fresh browser, but for applink startups the notification would trigger after the first pageload is done. Some requests might still be done during the load, but at least telemetry and remote settings can probably wait until the first pageload is done.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #11)

I'm wondering if instead of browser-idle-startup-tasks-finished we'd need something like a idle-after-first-pageload notification. I'm imagining this would be triggered immediately if you just open a fresh browser, but for applink startups the notification would trigger after the first pageload is done. Some requests might still be done during the load, but at least telemetry and remote settings can probably wait until the first pageload is done.

idle-after-first-pageload seems like it would work well for this use case.

But I'm a little surprised that we are deciding that the main thread is 'idle' during the busy startup, applink load phase.

No longer duplicate of this bug: 1954207

New profile from Firefox Nightly from the Play Store: https://share.firefox.dev/462OsDc

Three URLs get requested before the app link load gets initiated:

https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-telemetry-v2/records
https://ads.mozilla.org/v1/ads
https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/events/1/00490476-9639-4c12-9953-f0965b777bee

Then comes the app link URL:

https://shell--mozilla-speedometer-preview.netlify.app/resources/newssite/news-nuxt/dist/index.html

While that's loading, these other URLs get requested:

https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/baseline/1/3f4cd3ef-cb04-4e4b-91f5-dfc64ce22ddd
https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/nimbus/1/cd25102d-a9f1-4af1-bf7f-262eebb949a3
https://content-signature-2.cdn.mozilla.net/g/chains/202402/remote-settings.content-signature.mozilla.org-2025-10-19-08-10-44.chain
https://content-signature-2.cdn.mozilla.net/g/chains/202402/remote-settings.content-signature.mozilla.org-2025-10-19-08-10-44.chain
https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/usage-reporting/1/8aea2468-9d50-4030-a89b-726fb2d59a7c
http://detectportal.firefox.com/success.txt?ipv4
http://detectportal.firefox.com/success.txt?ipv6
https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/baseline/1/4b543bbc-2c79-48d2-a370-9e9b26cb5694
https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/pageload/1/ce0539d4-066d-4b59-8544-4719d21df6e4
https://incoming.telemetry.mozilla.org/submit/org-mozilla-fenix/use-counters/1/ae016cee-8121-44ce-afc4-950dad1c442b

Then the "root" app link URL load completes, and we request JS+CSS+images:

https://shell--mozilla-speedometer-preview.netlify.app/resources/newssite/news-nuxt/dist/_nuxt/entry.185106a5.js
https://shell--mozilla-speedometer-preview.netlify.app/resources/newssite/news-nuxt/dist/_nuxt/entry.037ba6ce.css
https://shell--mozilla-speedometer-preview.netlify.app/resources/newssite/news-nuxt/dist/_nuxt/error-component.d06e5f47.js
https://shell--mozilla-speedometer-preview.netlify.app/resources/newssite/news-nuxt/dist/placeholder_light.jpg

Just before the image load completes, we also request these URLs:

https://assets.mozilla.net/mobile-wallpapers/metadata/v1/wallpapers.json
https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/nimbus-mobile-experiments/records

So the wallpapers.json load is still there, but it now happens late enough that it's probably fine.

(I extracted the URLs from the profile by executing the following code in the web console on the profiler page while showing the marker chart on the parent process gecko main thread: filteredMarkers.filter(m => m.data?.type === 'Network').sort((m1, m2) => m1.start - m2.start).map(m => m.data.URI).join("\n"))

I had a look into the telemetry events being logged before the app link, and I think it's what happens when we initialize Glean.

It seems like we usually flush things immediately Glean is initialized -> https://github.com/mozilla/glean/blob/d7d9d719f2f4264fd9bc1a6c14e8ec21e48c8701/glean-core/android/src/main/java/mozilla/telemetry/glean/Glean.kt#L253

This puts the metrics from the Kotlin side into Rust queue as the comment suggests, and what happens after that is that, an immediate work is scheduled.

Here’s where I believe it comes from on the Glean side -> https://github.com/mozilla/glean/blob/d7d9d719f2f4264fd9bc1a6c14e8ec21e48c8701/glean-core/src/lib.rs#L498

So when we initialize Glean automatically, it automatically starts sending many of the pings that were “queued”.

I would like to suggest that we have a separate hook into Glean to actively trigger a flush of events, or to allow initialization of glean without flushing events, so that we can delay the flushing until when “visual completeness” is achieved.

Is there a contact from the Glean team that we can ask for info about this? To verify that my understanding is correct, and that it is feasible to introduce this behavior.

As for the request to https://ads.mozilla.org/v1/ads

It is happening because we refresh top sites every time we resume the home screen, if the cache has expired. That is done here It's very possible that this block of code gets executed before the app link navigation starts.

We can add extra conditions to add the following behavior, but I would like :brclark or someone from product to confirm that it's ok to do this, esp because of the sensitivity of ads:

  1. If the home activity is started for an app link, we only refresh the top sites after visual completeness is achieved
  2. If the home activity is started for a "home destination", i.e we do not want to prioritize a link opening, we refresh the top sites as we currently do.

That does not sound like something that needs product approval. The fact that the home activity is started at all for app link startups seems like an implementation detail - with your proposed plan, once the user actually intends to show the home screen, the ads request will still happen as usual.

Depends on: 1987602

Thank you for your input :mstange.

I filed bug 1987602: "Fenix is making "Top Sites" request before page load during app link startup"

I still need input on comment 14, on how Glean behaves on initialization.

Is there someone from Glean team we could NI to help validate the theory here and advise on how best to solve it?

(In reply to Segun Famisa [:segun] from comment #17)

I still need input on comment 14, on how Glean behaves on initialization.

Ted, I think you were looking into this too - is this something where we should ask for assistance from the Glean side?

Flags: needinfo?(tcampbell)
You need to log in before you can comment on or make changes to this bug.