I found the issue has to do with 30 seconds ajax timeout in \mediawiki-1.27.3\resources\src\mediawiki\api.js . Changing the timeout to one minutes fixed the issue

This timeout can even be disabled by setting it to 0, which might work for you (and that's great), but I think most websites actually have some timeouts on the server, and I think it's more difficult for us to display a sensible error message when that happens than with a client-side timeouts. Maybe this should be configurable.

There are 200 media links in the test page. From looking at the parsoid logs, it looks as if most of the time is spent grabbing image information for each file from the Mediawiki database. Is the parsoid response time I am experiencing (~ 60 seconds) what one would expect?
Any way of making it faster (e.g., setting ParsoidConfig.prototype.fetchImageInfo to false)?

This would be expected if these were foreign files (e.g. using $wgUseInstantCommons = true;). If they are local files, then I'd say that's very unexpected, and a bug in Parsoid. Perhaps the Parsoid/PHP rewrite will also improve this, since it's going to be more closely integrated with MediaWiki.

Any way to provide better information as to what is happening to the user?

The recent patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/556510 improves the error message, which now reads "The server did not respond within the expected time.".

Thanks for the update. With respect to server timeout, you are right:, I also had to change the IIS timeout for this change to function.

With respect to your statement

If they are local files, then I'd say that's very unexpected, and a bug in Parsoid

I confirm the files on the test page are all local. The only thing I can say is that my instance of MediaWiki is running on a Windows infrastructure (the files are on a local drive, though). While debugging the issue, I performed extensive testing on two different environments: my dev environment (Windows also) and another environment (Linux)

• In the case of my dev Windows environment, I observed the same behavior (js timeout), even without the files actually being present on the drive (I copied the wiki page but not the associated files). I can also confirm that this happens for MW 1.27 and MW 1.33 (I just upgraded to 1.33 - and yes I also upgraded the parsoid version);

• In the case of the Linux environment (running MW1.31), as with my test in dev, the files associated to the page were not present on the server; the VisualEditor load time for the page was drastically smaller. Unfortunately, I do not have developper access to this environment so I do not know what their architecture is (e.g. do they use a caching server)