Page MenuHomePhabricator

New Wikitext Editor: Major improvement to load time and preview time
Open, MediumPublic40 Estimated Story Points

Description

With current wikitext editor, I could begin editing the EnWiki article United States within 3 seconds of clicking edit.
With the New Wikitext Editor there was a 30 second delay before I can begin editing United States. That is bad.

Then I tried one of EnWiki's largest articles, List_of_named_minor_planets_(numerical). (Yes, that is a gross article.)
With the current wikitext editor I could begin editing within 5 seconds.
With the New Wikitext Editor my load time was ONE HUNDRED AND TWENTY SEVEN SECONDS. That load time is utterly obscene.

On English Wikipedia there is strong community consensus that this issue is serious enough to be a deployment blocker. The key text was:
Actionable Blocker: Load time. Load time is a priority concern for both new editors and experienced editors. Possible resolutions:

  • We could happily retain our current wikitext editor; or
  • if possible, drastically reduce New Editor load times, particularly on large pages.

The obvious ideal would be to match or improve current times, with additional time subtracting from the value of the New Editor as a whole. This priority aspect quickly turns the New Editor into a clear downgrade from the current editor.


Preview times also need to be fast, which is even more critical. The editor only loads once, but 30 seconds to preview easily becomes 2 minutes or even 5 minutes when preview needs to be used multiple times.

Event Timeline

P.S. I forgot to mention the Technical Collaboration Guideline. As an individual, I am proposing this as an Actionable Blocker. I would be more than happy to see the WMF close this as cantfix/wontfix, so long as it will be reopened as a blocker if/when the community formally resubmits it as a consensus blocker issue.

My (unverified) hunch is that this is due to the preloading of link existence that action=visualeditor does when returning the wikitext for the editor to use. That's needed for the VisualEditor to mark links as existing, but I'm not sure that the source editor requires it?

Maybe I am ignorant, but what motivation stands behind the (new) editor (NWE), which must be started/executed from VE mode? If the NWE should be the future replacement of the old wikitext editor, I would expect the same usability as for the old editor (i. e. it should be executable/editable independently of the VE). We can safely presume that a big chunk of the load time is caused by the need to load the page in the VE mode.

This comment was removed by Dvorapa.

The load time should be the first thing different between source and visual edit mode. I understand it is not a bug, but a feature in VE, but in NWE? If OWE source code was loaded immediately, I expect this behavior in NWE (other over-standard features could be loaded with a delay, but source code itself can be ready immediatelly)

Maybe I am ignorant, but what motivation stands behind the (new) editor (NWE), which must be started/executed from VE mode?

This task is about loading times. General questions about NWE and motivation should be asked on https://www.mediawiki.org/wiki/2017_wikitext_editor/Feedback instead. Thanks!

@Aklapper if you can get the this new editor load time to be comparable to current editor load times, then sure. That will get this Phab listing closed, and terminate the entire discussion here.

However it seems these topics are pretty directly related. It seems the load time is a direct consequence of the VE-based design. If that's true, then load times are a first-rank factor to weigh when evaluating whether a VE-based design is appropriate.

There are concerns that the WMF may not be applying the right weights when evaluating cost/benefit trade offs. There are concerned that the WMF may be over-emphasizing VE and VE-related concerns at the expense of our primary editor, at the at the expense of our core mission. The WMF seems to be focused on VE and VE-concerns as if it's our primary editor, as if it's supposed to be our primary editor. The reality of actual usage is that VE is a minor secondary editor, only used for about 5% of all edits. We shouldn't be degrading our core editing based on an imbalanced focus.

It's unclear this "bug" can really be fixed. Perhaps all these dev-hours are better invested in our existing wikitext editor, and other things we need.

In Safari 10 on my Mac just now, https://en.wikipedia.org/wiki/List_of_named_minor_planets_(numerical) opened in:

  • seven (7) seconds with the 2010 wikitext editor, and
  • nine (9) seconds with VisualEditor's wikitext mode.

The user experience of performance varies considerably by location, account (how many gadgets do you have installed?), web browser, device, type of internet connection (shared? mobile?), etc. If you want to provide your details (either here or in e-mail), then that information might help the devs determine why your experience of performance is so different from other people's.

My (unverified) hunch is that this is due to the preloading of link existence that action=visualeditor does when returning the wikitext for the editor to use. That's needed for the VisualEditor to mark links as existing, but I'm not sure that the source editor requires it?

This was done in rEVED3577035825ee: Bypass warming red link cache for wikitext requests.

why your experience of performance is so different from other people's.

You mean why my experience is different from WMF staff. If you check the RFC, every non-staff report for List of planets is upwards of 110 seconds, plus awful load times elsewhere. We should investigate why staff's experience is so vastly different from non-staff. I have an idea. Send me a paycheck! Maybe that will fix it! :)

Firefox browser. Broadband cable internet - I have a second computer sharing the connection, but it's only occassional e-mail usage. My PC is a 64 bit quadcore AMD A8-3800 (a few years old, but plenty of power). Active gadgets list:
Twinkle, Suppress display of fundraiser banners, Enable the Teahouse "Ask a question", Reference Tooltips, FormWizard: a wizard for creating and expanding project pages, Geonotice: display notices on your watchlist, Display watchlist notices, (This loads the base style for the watchlist. Please do not disable this option.), Form for filing disputes at the dispute resolution noticeboard, CharInsert, refToolbar, Add extra buttons to the old (non-enhanced) editing toolbar, Display green collapsible arrows in Watchlist etc, Add an [edit] link for the lead section of a page, Show radio buttons to switch between views of certain content such as some maps, Mark navigation links to featured and good articles in other languages, Allow /16 /24 and /27 – /32 CIDR ranges.

Has some one considered doing a screen sharing session with @Alsee to debug and measure this on his machine ? Arguably the screensharing would influence the performance even further, but it's better than nothing.

:en:List of named minor planets (numerical)

Ordinary computer in the Czech Republic, one of the fastest internet connections, OS Arch Linux, Google Chrome 54, default settings on enwiki (except allowed NWE naturally):

74 seconds (1st time)
66 seconds (2nd time)

Alsee, are you running Windows? I've got a Mac, and Windows is distinctly under-represented among the devs.

It took me about 40 seconds, but I have a relatively fast computer so 100 seconds sounds reasonable to me. I watched the network tab, all requests finished in under a second (speedtest.net says my internet is a B, I'll can again tomorrow at school where the internet is a D+, but I don't think network is really a factor here) - then my browser started using up an entire CPU doing some JS processing for about 40 seconds until the loading bar went away. We probably need to do some JS profiling of what's going on.

I did just try it on Windows/Chrome and Windows/Firefox, and NWE opened to an editable state in 10-ish seconds. It was noticeably slower in Firefox, but not much -- maybe 15 seconds.

As I said before, basic solution would be to load wikitext (in VE editable content) as fast as possible to be editable almost immediately by users (by refactorizing JS and by excluding every source processing currently being done before user gets to editable state); and then after that load all the background JS, top bar, gadgets and all the other stuff. This is current behavior of OWE that in my opinion should be preserved in new editor in the future. I understand VE's the load time could be a little bit slower than in WE, but I don't understand current load times in NWE. Finally proper solution would be then rewriting that "other stuff"'s background (JS refactorization, performance improvements, all-embracing user load time experience analysis, background functions order and so). If devs really stands up for commons base of VE and NWE, this should be the first priority to focus.

Alsee, are you running Windows?

Yes.

Summary of load times reported at the RFC:
Alsee: United States 30 seconds. List of Planets 127 seconds.
Daß Wölf: List of planets 114 seconds. Village pump proposals 21 seconds.
Yodin: United States 35 seconds. List of planets 122 seconds.
Fram: Leuchtenberg Gallery 15 seconds. Exposition des primitifs flamands à Bruges 50 seconds.
Whatamidoing: United States 9 seconds. <--- One anomalous report

For me, Chrome, Windows 10, time from clicking Edit Source to being able to type:

Note that the Minor Planets page has been split. Anyone wanting to test that load time should use the link in Samwalton9's post above.

Two comments:

  1. https://en.wikipedia.org/w/index.php?title=List_of_named_minor_planets_(numerical)&oldid=764463566&veaction=editsource opens for me as follows:

A. Without NWTE: about 7 seconds
B. With NWTE: about 45 seconds

  1. While for smaller articles the difference between the NWTE and wikitext may only be a a few seconds, there does seem to be a big problem with this page and I imagine with other long pages. This is something that I would expect to be both found (as it has, thank you @Alsee) and addressed before NWTE fully replaces the legacy Wikitext editor.
Alsee renamed this task from New Wikitext Editor: Major improvement to load time to edit to New Wikitext Editor: Major improvement to load time to edit. (Consensus this is a blocker issue).Mar 21 2017, 5:44 PM
Alsee raised the priority of this task from Medium to High.
Alsee updated the task description. (Show Details)

I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.

Aklapper renamed this task from New Wikitext Editor: Major improvement to load time to edit. (Consensus this is a blocker issue) to New Wikitext Editor: Major improvement to load time to edit.Mar 21 2017, 9:20 PM
Aklapper lowered the priority of this task from High to Medium.
Aklapper updated the task description. (Show Details)

Thanks for informing about the closing of the RfC on the English Wikipedia!

(I have reset the Priority field as per guidelines and also adjusted the task summary, as such information is already present in the task description.)

@Whatamidoing-WMF: Here are my times for "List of named minor planets (numerical)":

  • Old Wikitext editor: 5–9 seconds
  • New Wikitext editor: 51–60+ seconds (if it takes longer than 60 seconds, Firefox gives me an "unresponsive script" error)

I'm using Firefox 52 on a MacBook Air from the WMF office.

Adding report by JAn Dudík:
United States 75 sec.
List of planets 140 sec.

There might be some interference with media player (e.g. Anthem in infobox for United States) (Opera 45/Win10)
When I want to edit with NWE, there is long time when only moving thing on page is wheel over anthem . After player is displayed, progress bar moves again.
When I move cursor during loading, player loads quickly and page is enabled for editing in significantkly shorter time

Alsee renamed this task from New Wikitext Editor: Major improvement to load time to edit to New Wikitext Editor: Major improvement to load time and preview time.Jun 22 2017, 2:53 AM
Alsee updated the task description. (Show Details)

My (unverified) hunch is that this is due to the preloading of link existence that action=visualeditor does when returning the wikitext for the editor to use. That's needed for the VisualEditor to mark links as existing, but I'm not sure that the source editor requires it?

Yes, was fixed in https://gerrit.wikimedia.org/r/#/c/331934/

@Esanders: I tried benchmarking this again, but got some weird results. On the article United States, the first two times I tried to load it with NWE, I got a timeout error from the editor after 60 seconds: "Error loading data from server". After that, however, loading was smooth and fast: typically about 10 seconds or less. Any idea what may have caused the delays initially? Maybe a missing server-side cache? (It's also possible this was just an issue on my end with my internet connection.)

@kaldari that sounds odd, as we're just using a simple API request to load the wikitext (action=query). Could've been network downtime, or some sort of re-caching in process, but I don't think it's anything VE is doing wrong.

Visual Editor is a resource hog, particularly on large pages, regardless of whether it's in wikitext mode or not. It maxes out the CPU and I suspect overloads memory. (I have 6 gig RAM BTW.)

In one detailed test I captured the load time metrics that the editor was reporting back to the server. In that test VE's Wikitext mode took over 100 seconds to load, while the metrics sent to the server claimed approximately 4-second "time to interactive" metrics. So the "time to interactive" metrics are grossly broken, and we know the editor is doing something to bog down the system after that "time to interactive" reporting code is executed.

My most recent tests from home and the WMF office have shown no issues. In both cases, the United States article loads in about 10 seconds. @Esanders - Do we have any metrics on how often the "Error loading data from server" message is displayed in VE? I'm guessing not, but just thought I'd ask.