Experiment to speed up deeplink connection from WP.com

[katinthehatsite]

Related issues

Related to STU-1173

Proposed Changes

This PR explores the speeding up of the deeplink connection from WP.com e.g. connecting a WP.com site and opening a modal.

• immediately create a minimal site object with data from the deeplink (this would need to be done on WP.com side, but we can add WP.com site's URL and site name which would be enough for our UI)
• display the loading skeleton while we are connecting
• fetch the remote site right away
• and trigger the API refetch in parallel without blocking

Testing Instructions

• Pull the changes from this branch
• Start Studio
• Navigate to the Sync tab
• Make sure that you don't have any WP.com sites connected to your Studio site so that the Publish site button displays in the top right corner
• Click on the Publish site button
• Observe that you are brought to WP.com
• Complete the purchase
• Wait for the site to go Atomic
• Observe that you see a popup asking you to open Studio
• Confirm that you can see the loading skeleton on the Sync tab
• Confirm that the site you just created is connected in the Sync tab
• Confirm that the Push modal is open
• Confirm that there are no other regressions

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 93a0ee7 vs trunk

site-editor

Metric	trunk	93a0ee7	Diff	Change
load	1477.00 ms	1437.00 ms	-40.00 ms	⚪ 0.0%

site-startup

Metric	trunk	93a0ee7	Diff	Change
siteCreation	7094.00 ms	7080.00 ms	-14.00 ms	⚪ 0.0%
siteStartup	3933.00 ms	3931.00 ms	-2.00 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[katinthehatsite]

The code needs to be polished quite a bit so I am leaving this PR as a draft. What I am looking for is the feedback on the approach before adding any further polishing touches - does it make sense? is there a different way we could optimize the speed of connection that could be simpler?

One thing I dislike is creating a "fictional" site object that could potentially cause racing conditions and similar issues. Any opinions are welcome!

One option as an alternative that comes to mind could be adding a loading state to Sync tab if the user is connecting a site from deeplink and it is taking time. This way, they could have a visual indication of what is happening and this could be a simple and fast improvement in terms of the UX.

[sejas]

Thanks for exploring how to speed up the deeplink connection.
In general the approach makes sense to me. Loading an optimistic connection until we fetch more information.
My concern is if we display wrong data, like isStaging, or isPressable. With the current flow where the user purchase a new site, those will always be false, but in the future we could add more deeplinks in Calypso.
What if we show a loading skeleton until we fetch the information?
As mentioned below, we can optimize the fetch call to get only the information for that specific site.

[sejas]

Another optimization could be fetching only the information of the remoteSiteId. Currently fetching all the sites takes longer, specially for Automatticians.

[katinthehatsite]

I found an endpoint that allowed to fetch just one site instead of all sites so I went with that solution.

[sejas]

We need to translate the placeholder.

[katinthehatsite]

I think it was not needed at the end after I added the loading placeholder so I removed it.

[katinthehatsite]

Thank you for review @sejas - I will take a look at the next steps today 👀

[katinthehatsite]

@sejas I made some adjustments on this branch based on your recommendations. Would you be able to give it another look?

[sejas]

@katinthehatsite , great work. Thanks for addressing my suggestions.
I tested it and it works much better with the loading skeleton. Thanks for improving this flow.
I left a couple of comments. Let me know what you think. I also noticed that the loading skeleton is visible even after the single site request resolves, so it seems in the end it uses the whole sites request to decide if should be loading or not. Or at least that was my impression.
I also noticed we try to use the siteurl and site title, but that information is not passed from the deep link. I think it's ok to remove those because the skeleton gives enough context IMO.

Firs time connection:

first-time-connection.mp4

Second time connection:

I also tested it by disconnecting and repeating the deep link.

second-time.mp4

[katinthehatsite]

I also noticed that the loading skeleton is visible even after the single site request resolves, so it seems in the end it uses the whole sites request to decide if should be loading or not. Or at least that was my impression.

I saw this as well before but thought it was resolved. Taking a look now 👀

Update: I see it on the reconnection but not on the initial connection 🤔