Topic on 2017 wikitext editor/Feedback

When I tested the new editor some time ago, it seemed to share Visual Editor's often atrocious loading times... which are upwards of 40 seconds on many articles. The current wikitext editor loads even the largest page with almost no noticeable delay.

It appears the goal is for the new editor to eventually become the default wikitext editor. I believe the community will consider this sort of load time to be an unacceptable degradation of the current editing experience, both for new editors and experienced editors.

This should be categorized as an "actionable blocker". Loading times need to be roughly comparable to the current wikitext editor, even on large complex pages, before it is considered suitable for anything other than fringe opt-in usage.

I would agree that the load time should basically be a blocker to deployment beyond the beta stage.

I've also experienced lengthly loading times, although on a slowish older PC. The editor is still clearly too slow for productive editing. 2A02:908:2F32:2C80:B8CE:2B40:B43E:EBA2 22:12, 14 December 2016 (UTC)

FWIW, on the Obama page just in quick informal testing on my machine, it takes:

• … about six seconds to load in read mode (https://en.wikipedia.org/wiki/Barack_Obama);
• … about six seconds to go to old wikitext edit mode (https://en.wikipedia.org/w/index.php?title=Barack_Obama&action=edit);
• … about seven seconds to go to source mode directly following a link (https://en.wikipedia.org/wiki/Barack_Obama?veaction=editsource);
• … about nine seconds to go to visual editor mode directly following a link (https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit).

Switching from read to visual editor mode seems to be about five or six seconds; switching from read to source seems to be about three or four.

None of these times is great. Obviously with a faster computer/network/etc. they would be faster, and with a slower one they'd be slower. I don't think an extra second or two is critical (and the testing we've done agrees), but where users have particularly slow set-ups and yet want to do particularly big/slow things it's not likely to make them happy if they have to wait more than (say) ten seconds.

One thing I've thought about is asking users in those situations if they want to switch to the non-JS mode. This is what Google does when loading GMail, for instance. The non-JS editor is much faster, but very unfriendly — just an empty box with no tools, no help, essentially nothing.

The standard wikitext editor takes six seconds to finish loading the (very rarely used) toolbar at the top, but that's not really relevant. Time to begin editing Barack Obama:

• Standard wikitext editor: 2 seconds.
• New wikitext editor: 15 seconds.
• Visual editor: particularly variable, 30 seconds and up.

Firefox. Win 7. 64 bit system. AMD quadcore 2.4 Ghz.

These numbers are a lot higher than what I'm seeing as well - mine are pretty close to Jdforrester's on Firefox, and faster on Chrome. Low memory could be an issue as well.

• Read mode: 6 secs (mostly [5.5secs] waiting for server to start delivering data)
• Old editor: 7 seconds (again, mostly waiting for first of the data to arrive)
• New editor: 9-13 seconds (5-6 secs for first data, 2,5 before VE starts loading, which takes 2-4 seconds)
• VE: 10-18 seconds

All tests with warmed up caches. Safari and Chrome are a bit faster, but not much (1-5 seconds differences). From Netherlands, pretty new iMac and good internet connection. I also note that the first two, are significantly faster in anonymous mode, more towards that 2 second time that Alsee describes. This indicates significant delay, due to logged in users not getting purely cached data.

This is all measured to what I consider the screen to be 'interactive' as a user. Not necessarily fully finished loading completely. When you switch between modes, it seems faster, probably because i'm skipping some of that initial 5-6 seconds because that stuff already arrived.

Maybe an idea to make some screen recordings once by several users around the world? Anyway, I think there is still some space for improvement here, likely by improving on the smarts of the delivery.

We actually spent a lot of time optimising VE last year, especially around the API calls. There are a lot of unavoidable costs in processing long documents in JS that the textarea editor doesn't have to deal with. We'll continue to look into this though.

There are unavoidable differences. It will always be faster to load a page that contains no images, no transclusions, and little formatting than to load a page that contains about 50 images, heavy formatting, 700+ transclusions, 2000+ internal links, 900+ external links, etc.

That's why it can be faster to open large and complex pages for editing in any of the wikitext editors (except WikEd, depending upon what your settings are) than to load the same page for plain old reading. I don't believe that any reasonable person will expect any editing tool that actually displays the images, links, and other formatting on screen to be as fast to load as any editing tool that provides none of that.