Jetpack: Search: Display indexing time to admin when indexing in progress

[gibrown]

I spun up a jurassic.ninja site that was pre-populated with content and as a part of the set up I immediately purchased a search plan. This is just about the worst case for not allowing Jetpack to sync any data before a user has purchased search and is starting to run searches.

After the purchase I went to the customizer. The search customization works fine, but:

• there are no filters displayed because there are no results
• there are no results no matter what I search for

Looking on the backend I can see that the ES index was not populated for about 5 minutes (we have a 5 minute deduping queue for bulk jobs). Once it was populated the searches I ran before still were not showing any results because they had been cached in the browser. After reloading the browser they still were not shown because we have a five minute timeout on the search query caching if the hash of the search is identical to a previous one.

End result, the user can currently have to wait 10 minutes from after they purchase to when they can first see search results.

Ideas for changes:

• Change our messaging at the end of the purchase flow
• Add a message to the search UI for admins to see how long indexing is expected to take. Let them know that they only have partial results. The API should be able to provide this info.
• Reduce the dedupe queue time? I took a look at doing this, but it is risky and not easy. It also won't solve the whole problem.
• Reduce the query caching from 5 min to 2 minutes
• Start the indexing as soon as we know the user may be interested in the product

cc @keoshi

[keoshi]

The initial idea was to expose the sync progress in the settings section, which could then be replicated as a global notice in any Jetpack context, like so:

I wonder if the work that went into the health monitor for site health on https://github.com/Automattic/jetpack/pull/15200 could be repurposed to expose this progress bar.

[keoshi]

I should have mentioned that as an MVP we could:

• Revisit having an onboarding notice in wp-admin (see below).
• Use this element or a link in settings to redirect customers to the Site Health section to check on progress; though that page could be slightly confusing as there's a lot happening there, hence my suggestion to bring the progress bar to the forefront.

[gibrown]

Let's add some messaging directly to the search results. We are linking directly into the customizer now which is a nice flow, but it feels broken when there are no results or a particular post is not yet there.

As a v1 we may be able to have the search api just return a result that says the results are not yet all available (I think this is all we can do before the next release). In the next release maybe we can add a notice that only admins can see? Include a time estimate as well.

Also, I think I have a way to trigger the indexing to start before the purchase is made which should save us some time as well.

[keoshi]

As a v1 we may be able to have the search api just return a result that says the results are not yet all available

I like that but would only recommend it if we can restrict it to admins, so they know when to activate it for real.

Here's a crazy idea: can Jetpack Search:

• Default as inactive if the site hasn't been synced/indexed.
• And activate itself once that's done?

We'd need to indicate it is “setting itself up” in some way, but that would be ideal for the visitors or our customers as to avoid any broken search page/view.

[gibrown]

Ya, I think all of those options require some changes in the plugin and once we can make changes in the plugin then we can add a notice for the admin that indexing/sync is still happening.

I'm going to try and deploy some changes to reduce the caching and indexing start times. That should help. Let's try to get some messaging into the search results for logged in admins for the next release. I think we can send a flag to the api for admins and then return the estimated time to complete indexing from the API.

[gibrown]

I've reduced the query cache from 5 minutes to 30 seconds. Also triggered indexing as soon as the end user gets an estimate of the number of records on the site. Unfortunately the dedupe queue is annoyingly hard to bypass for this one case without bypassing it in many other cases which could cause performance problems.

We need a UI solution to this anyways as nothing I do will help to speed up sync nor give the user any info about how long it will take. Updated the issue a bit

[jsnmoon]

[...] as an MVP we could:

• Revisit having an onboarding notice in wp-admin (see below).
• Use this element or a link in settings to redirect customers to the Site Health section to check on progress; though that page could be slightly confusing as there's a lot happening there, hence my suggestion to bring the progress bar to the forefront.

@keoshi

I'll work on adding a progress bar in the search card within performance settings as per the mockup above.

[jsnmoon]

It looks like this task has been punted pending further discussion and coordination; see here: p1HpG7-94Z-p2.

[gibrown]

"Reduce the dedupe queue time? I took a look at doing this, but it is risky and not easy. It also won't solve the whole problem." done.

Indexing should now be starting within a few seconds of getting an estimate of the number of records. Most of the time this will happen during the purchase flow, and soon it should even happen on the landing page on jetpack.com. Assuming it takes the user at least 30 seconds to complete purchase, then there should be at least 5k documents in the index.

[jsnmoon]

Where are we with this issue in terms of priority?

Indexing should now be starting within a few seconds of getting an estimate of the number of records. Most of the time this will happen during the purchase flow, and soon it should even happen on the landing page on jetpack.com. Assuming it takes the user at least 30 seconds to complete purchase, then there should be at least 5k documents in the index. (@gibrown)

I'm assuming we can drop the priority of this issue?

[gibrown]

Ya, I just removed the high priority. It doesn't come up as much now that we have preindexing. I do feel like we may want to support this in the future somehow. I was thinking a bit about how we could handle free sites and indexing on demand which would probably require some messaging.

[jsnmoon]

We'll need to coordinate a bit given that this has a lot of overlap with sync; this overlap is why #15488 was shuttered in April.