Suggestion mode can require checking a lot of separate content-ranges when we enable it. For instance, the test article I've been using is New York City which, in the copy on my patchdemo, results in 573 distinct ranges which all need to be tone-checked. 573 separate tone API requests was (a) slow, and (b) rapidly got me blocked from the tone API which has a request limit of 1000 requests per hour.

I have a patch written which will help, which batches the tone requests together. The API only lets you ask about 100 at once, but 6 separate requests is much better than 573. This will occasionally be helpful even for non-suggestion cases, but because of how the checking works it'll only really make a difference when you're doing something like reloading the page and having a large autosaved edit restored, or if a find/replace suddenly means you've edited a lot of paragraphs.

This doesn't get us to an under-1-second state, though. I find that when I'm sending off a batch of 100 separate pieces of text, the tone API takes somewhere between 0.5 and 3 seconds to get everything back to me:

I also merged this patch which helped with some performance issues that tone was causing specifically on its synchronous building-the-request portion.

Both of these are ways to improve the current paradigm where we need to wait for all our checks to have finished loading before we can display any of them. Particularly as we look to a future where there's more async checks, or we decide to allow particularly slow ones, we probably need to refactor how we're loading checks so that individual async checks can slide in as-and-when they complete.

(There's room for some further optimization as well. A decent chunk of those tone check API requests are for things that could be filtered out before we make the request. E.g. we probably don't really need to be checking the text of headings...)

@DLynch, what you described in T404602#11207172 [i] and implemented in 1189892 [ii] makes great sense to me; thank you for investigating and documenting all of this!

Resulting questions
Would it be accurate for me to think that so long as we're comfortable with it taking up to ~3 seconds for Tone Suggestions to appear, we can consider it feasible to enable Tone Suggestions via Suggestion Mode? If so, what – if anything – is left to be done to make this happen?

i. Without modification, offering Tone Check in Suggestion Mode would quickly bump up against the API's rate limit
ii. Batch the [potentially] hundreds of ranges we'd like the Tone Check model to evaluate within an article into a manageable amount of batches while accepting the tradeoff that sending requests in large chunks will mean it will take longer for someone loading VE in Suggestion Mode to see Tone Suggestions appear

Would it be accurate for me to think that so long as we're comfortable with it taking up to ~3 seconds for Tone Suggestions to appear, we can consider it feasible to enable Tone Suggestions via Suggestion Mode? If so, what – if anything – is left to be done to make this happen?

The patches I mentioned have been merged, so as-is that's what the MVP will be doing.