@Deskana (WMF), @Matma Rex, there is a severe data error in the report. Specifically, the graph Time_to_interactive does not accurately reflect time-to-interactive for the 2017Editor.
Using the 2017Editor in Chrome on Win7, I captured the beacon reports (action.init.timing, action.ready.timing, action.loaded.timing) while testing the page en:List_of_members_of_the_Lok_Sabha_(1952–present). Reported init.timing was about a half second, reported ready.timing was under 4 seconds, reported loaded.timing was over 100 seconds, actual user-experienced time to an interactive state was over 100 seconds. For the 2017Editor, the ready.timing value does not remotely reflect Time_to_interactive. 2017Editor time_to_interactive time appears to equal loaded.timing, or maybe slightly longer.
This may help explain the disconnect between the WMF's perception of 2017Editor performance and user reported performance. Also do not overlook the #Caveats sample bias. Anyone who edits larger pages, or has otherwise experienced poor performance, has probably shut off the Beta-option. (Performance appears to be significantly worse in Firefox.) So the values collected on the 2017Editor is going to skew low, independent of the error in measuring time_to_interactive.