Testing on a basic device (Samsung Galaxy A13 5G) on Wifi, an average article took under 2 seconds to load:

Whereas a large article (largest 1%) took around 6 seconds:

Profiling the large article load showed around 1.5 seconds was parsing the article HTML string to (unattached) DOM, and around 2.5 seconds was parsing DOM into the ve.dm linear model and instantiating DM classes. (The CE classes are negligible, because section editing means only a small portion of the article is loaded into CE at any one time, thanks to our 2018 optimizations).

Possible optimization: Load only the linear model for the section

We could potentially claw back much of that 2.5 seconds if we loaded only the linear model for the section. However there are complexities:

• In order to show accurate reference numbering and contents, we'd need to load the reference structure for the whole article separately.
• Even then, there would be some complex offset calculation changes.
• We'd likely want to load the whole article by save time, in any case, since changes to references in the section being edited could have source implications for other sections.

This would only give an appreciable saving for large articles. Also, any move toward whole-article editing on mobile would undo these savings.

These benchmark timings suggest that >3 second waits should be rare on typical articles when internet connectivity is good. So any optimizations should be targeted at either large articles or slow internet connectivity. One optimization that would help with both scenarios is:

Possible optimization: start from an already-loaded Parsoid read view

On a wiki with Parsoid read views, we could potentially have the article HTML string (and even the unattached parsed DOM) waiting in memory before the user clicks Edit. This could save processing time on large articles (profiled as 1.5 seconds on the basic device tested above). It could also help with slow internet connectivity since the entire article doesn't need to be fetched. However it would have two new dependencies:

• It would only work on wikis where Parsoid read views are in use.
• It would depend on a Parsoid API to retrieve any additional editing-related data augmenting the read view HTML.

A trade-off would be the additional memory requirement of keeping an extra copy of the unattached parsed DOM before the user has clicked Edit. If we were to do this, we might to restrict it to, say, users who have ever saved an edit.

Possible optimization: Use IndexedDB to ensure VE code is cached

Going into the slow internet connectivity scenario, we could ensure reduced bandwidth for second and subsequent loads of VE by relying on caching. At present the ResourceLoader cache uses the severely size-constrained window.LocalStorage for caching, and so will not cache any module whose size exceeds 100kB. However modern browsers have IndexedDB with far higher size limits.

The cleanest way to implement this would at a MediaWiki platform level, i.e. T390220. However it would be technically possible to work within VisualEditor instead.

This would not directly help newcomers on their first edit, unless we did something like lazy loading VisualEditor code in the background.

I would prioritize the ideas above as follows:

1. Use IndexedDB to ensure VE code is cached. This is logically straightforward and would have a predictable benefit for users on a slower or less reliable network. This idea has the fewest unknowns.
   
   Estimate: I would assess an implementation wholly within VE to be a medium-sized change (small code change + medium testing requirements). A cleaner implementation, at the MediaWiki platform level, would not be logically more complex but it would have an inter-team dependency.

2. Start from an already-loaded Parsoid read view. This is logically straightfoward and would have a small predictable benefit on slow networks or for large articles. The trade-off is increased memory usage in read mode (i.e. before the user clicks Edit).
   
   Estimate: I would assess this to be a medium-sized change (small code change + medium inter-team discussion and coordination requirements). This obviously introduces a dependency on Parsoid read views, and also would depend on a Parsoid API to retrieve any additional editing-related data augmenting the read view HTML.

3. Load only the linear model for the section. This is logically more complex and would only produce a performance benefit where data processing time is a bottleneck (i.e. large articles on basic devices).
   
   Estimate: I would assess this to be a medium-sized code change. It would have no inter-team dependencies.