Ensure that ID creation screen is fast across devices

[markmhendrickson]

Upon reviewing TryMyUI videos for App Mining participants in March 2019, we noticed that several users (especially on mobile devices) spent inordinate amount of times (over 10 seconds) waiting for the progress screen to finish during onboarding in which their ID is created.

This issue entails improving the speed of that screen so the user doesn't have to wait more than a few seconds.

[AcidLeroy]

Not sure if this helps, but we noticed that we are failing on the last hub_info call and then we never get redirected to the app that requires the block stack id. I have a screenshot of the issue we encountered when running on an older iPhone (6) and attempt to sign up with blockstack after the user was directed away from our site to do so. They never end up getting redirected properly after they setup their account.

I've also included the screen that we seem to get stuck on forever after the hub_info call fails.

[markmhendrickson]

Upon discussion, we want to see first if hirosystems/stacks.js#659 resolves this issue then proceed to consider other possible solutions if it doesn't.

[zone117x]

Just left a comment about this in the referenced issue -- see hirosystems/stacks.js#659 (comment)

Cross posting some of the information to here..

---

I renamed the referenced issue to [Experimental] ... which more accurately reflects what this PR is. It's not currently being worked on. However, some previous work related to this issue has recently made progress:

• bitcoinjs-lib tweaked their secp256k1 dependency structure in response to our proposal which makes some of the additional required work easier -- see [1], [2].
• PR merged updating blockstack.js to use bitcoinjs-v5 (lets us use the new capabilities referenced above).

This PR would take significant more work to fully complete due to the elliptic and nodeJS crypto-browser-shim dependencies being so deeply integrated throughout this lib, bitcoin-js, Blockstack Browser, etc..

However, we could target something specific, like improving the performance of the Browser onboarding screen -- which is more reasonable to get done.

I wrote up a detailed issue -- initially for e2e test flakiness -- but it almost exactly outlines these Browser problems. Just renamed it: #1906

This is still a good next step towards tackling this:

Profiling & testing needs done so we can identify and prioritize potential work...

[zone117x]

To clarify what I think needs to be done:

The first step would be profiling & testing to determine what the actual bottlenecks are in the onboarding process. This seems like QA/testing work. For example:

• Network IO - is this a major contributing factor? Is it asset size constraints or some API endpoint response latency? Which assets or API endpoints?
• CPU & memory - at what level of hardware do either of these become a bottleneck? What pages & functions are culprits?

These can almost all be tested, simulated, profiled, etc using Chrome developer tools, VMs, other web profiling tools & services.

Once the bottlenecks are identified I can definitely help out with optimizing them, especially if it does turn out to be crypto-operation related.

@hstove @timstackblock @markmhx thoughts?

[markmhendrickson]

Thanks @zone117x; profiling the bottlenecks thoroughly sounds like a good idea to me. @timstackblock do you want to take this on?

[timstackblock]

Sure I can take a look @markmhx.

Just to clarify the task at hand, we want to get an idea of how the current on-boarding experience is across several mobile devices. Then work on fixing this problem after we find the bottlenecks in our mobile on-boarding flow. Is this correct?

Should I begin verifying the current mobile on-boarding flow and start logging bugs?

[markmhendrickson]

Yep that's correct, but note that this issue and investigation specifically concerns just performance bottlenecks (aka where in the onboarding flow things get really slow, say 3+ seconds, between transitions).

So yep, please do verify the current mobile flow (and desktop too, if you'd like – though mobile seems to be the reported culprit) and log bugs related to slowness where you see them.

Much thanks! 🙏

[timstackblock]

1. Android mobile test run everything looks good with Chrome.

2. Android mobile test run everything looks good with Samsung Native browser

3. Android mobile test run everything looks good with UC browser

4. Android mobile test run has long timeouts in Firefox.

VIDEO OF THE ISSUE
https://screencast-o-matic.com/watch/cq1bIgTEkT

There is about a 60 second or more loading time for firefox between screens during onboarding. This is happening on multiple android devices you can use Galaxy 9 or Pixel 3 and the lag is consistent.

STEPS TO REPRODUCE:
Create a new ID for blockstack browser using firefox on an android device. This happens when creating a new blockstack ID after the user enters their password twice. The loading circle will continue to hang.

SCREENSHOT OF THE BUG

---

UPDATE I DID THIS ON MY PHONE AND IT LOADED IN 17 SECONDS