Looking at an analysis of reading a full wikipedia page using search+s, the slowest part is requestSpeakSelectedText_->readNodesInSelection_->AutomationUtil.findNextNode, which accounts for 65% of the time spent. 

19.5% of time is spent in AutomationUtil.getDirection.

One option is to optimize the AutomationUtil functions as much as possible.
Another option could be to begin reading text immediately even while calculations to determine what the rest of the text should be proceed through the tree.

Note that reading this wikipedia page (en.wikipedia.org/wiki/English_alphabet) took 2.09s total.

Reading the same page with search + mouse, most time is spent in node_utils findAllMatching, which as a bunch of getters that take time.

In this case, the time spent seems much smaller, in part because it is not possible to select the entire document, even when zoomed out, whereas search+s can always select the entire document.

Therefore optimizing for search+s may make more sense -- expect that the original user had trouble with search+mouse. It would be helpful to know what documents the user is using, and what Chrome OS version they are on.

From the discussion, it sounded to me that the original user was on a pre-M67 build (before we rolled out Search+S for select-to-speak), so that search+mouse was their only option.

We can reach out directly to the user if you'd like.

@trumbull, it'd be great if you don't mind getting from the user:
1. Their chrome version
2. What document they were trying to read, if it is publicly accessible

Thanks!