Startup performance of GeckoView is important; this tracks any issues related to that. This is not the metabug for all of Fenix startup performance; just the GV portion.

This does cover both applink and to-the-UI startup types, though they will have different issues, and in some cases contradictory requirements/solutions.

See https://raw.githack.com/ncalexan/browsertime-reports/master/fenix-beta-browsertime-report-applink-live/fenix-beta-browsertime-report-applink.html for some applink startup issues. On a Pixel2, we take ~1.8 seconds to start, vs ~450ms for Chrome

The auto-downloaded resources mentioned in Bug 1529333 can impact startup performance.
In a simpleperf capture we did see the safebrowsing Classifier Update thread, although it looks like only 0.42% of samples in the 5 second period.

Here's a recent profile of GeckoView-example startup on a Moto G5: https://perfht.ml/38ntUX4
This profile was taken with a 5ms interval so that profiler overhead wouldn't distort timings too much. Here's another profile with 1ms interval, so more detail but also less representative timings: https://perfht.ml/2SojqRD

And here are profiles from GeckoView startup in Fenix, on a Moto G5, with remote debugging disabled:
https://perfht.ml/39LA0AJ (1ms sampling) https://perfht.ml/2uUTLa8 (2ms) https://perfht.ml/3bKTFCG (5ms) https://perfht.ml/37E9fNd (10ms)

Fenix App Link startup profile: https://perfht.ml/2I2GJug
This one includes a bit of information about what happens in mozglue before libxul takes over, with the help of the BaseProfiler (bug 1557570). I see 20-40ms in CustomElf::Relocate and 16-20ms reading /proc/self/maps in EnsureWritable::getProt. Overall, there's nothing concerning standing out to me in the pre-libxul part.

Fenix App Link startup, captured by simpleperf
https://perfht.ml/3ajtuBw
The build is a taskcluster performanceTest.
App link intent sent from adb.

Fennec68release applink startup simpleperf profile via the same method, for comparison
https://perfht.ml/32JptDO

Recent Fenix Nightly App link startup profile: https://perfht.ml/2xNSt1O

Recent Fenix Nightly App link startup profile: https://bit.ly/2QKnEln

Recent Fenix Nightly App link startup profile: https://perfht.ml/2Xc7WmW

Bug 1621340, bug 1618391 and bug 1623518 remain the lowest hanging fruit I can see. After that, possibly bug 1231711 to help with bug 1623521.

Recent Fenix Nightly App link startup profile: https://bit.ly/2VQuZmf

This includes the fix for bug 1602318. You can see that the first "https://www.mozilla.org/en-US/" load is started in the parent process before it is started in the content process, and overall slightly earlier (20-100ms). However, it doesn't have a huge effect in this particular run because the network responses come from the cache and because add-ons code is keeping the parent process main thread busy.
There still seems to be quite a lot of potential to move the first network load earlier. The first call to loadURI (in GeckoViewNavigation.jsm) runs about 570ms before the first network request to mozilla.org is started: https://bit.ly/3aQqzjM

Recent Fenix Nightly App link startup profile: https://share.firefox.dev/2ZF3dM0

Recent Fenix Nightly App link startup profile: https://share.firefox.dev/3fvxX6q

This includes the fix for bug 1621340 and saves 130ms that were spent re-initializing SafeBrowsing in response to preference changes.

Recent Firefox Nightly App link startup profile: https://share.firefox.dev/3vEv9Ny