See also T208428 .

Loading https://en.m.wikipedia.org/wiki/Nemegtomaia on my Nexus 5X (over fibre internet)

Loading the page again with various caches filled is very similar but for the first step which is skipped.

There are a couple of interesting observations:

1. Document metadata/HTML doesn't start loading immediately because Mobile isn't using ArticleTargetLoader like we have on Desktop, it is waiting for VE code to load first. We should create a task for this. (Edit: Filed as T209052)
2. The discrepancy between the time it takes to download code and the time before the next step is presumable the time it takes to evaluate and run that code.
3. Document metadata is very slow to load, despite being much smaller than document HTML. This is because of the work being done on the server to generate it, whereas HTML is cached by RESTBase. We should look into improving this. (Edit: Filed as T209078)
4. Building the CE takes a long time, so client side section editing would vastly improve this. I would expect that 1000ms to drop to ~100ms.
5. Parsing the HTML takes a fair bit of time (~700ms). That would only be improved by server-side section editing, but there are lots of speed improvements to be made without it.
6. Toolbar building is slow - there may be ways to improve this, e.g. lazy-building tools that are hidden in sub-menus.

With network throttling:

• Fast 3G: Not much change, metadata takes 800ms and HTML takes 600ms. As metadata is the slower of the two in parallel this is only 80ms slower than above.
• Slow 3G: Metadata take a similar amount of time to HTML, ~2000ms.

In T64803#4976635, @Esanders uploaded a patch:

[mediawiki/extensions/VisualEditor@master] ApiVisualEditor: Remove red-link cache warming

Red-link metadata was already added to Parsoid 18 months ago.
On long pages evaluating this information is very slow (hundreds of milliseconds) and completely redundant.

https://gerrit.wikimedia.org/r/492358

This is awesome. Thanks Ed!

Saving over half a second of time, very neat. This is a win in three categories:

1. Cutting down time spent waiting for the metadata to arrive - while being computed in PHP with various database queries.
2. Cutting down time spent transferring the metadata - less bandwidth.
3. Cutting down time spent in JavaScript - by removing the need to process this metadata.

That first point, I also measured with XHGui just now. The profile I recorded, saved as 5c7088c6 on performance.wikimedia.org/xhgui, shows it normally takes about 0.4 seconds for that first point alone.

This is an visualisation of the performance improvements over the past few months (loading html/metadata early, speeding up metadata, client side section editing), based on my initial measurements from November:

This is wonderful, Ed. And so too is the visualization you created.

Here's how it will look after T215717 is fixed:

Here's the same graph without the intermediate step