Note that this was accepted with provisions; it's unclear how adding the data-mw API call to the client improves the speed of the client, but instead would be a performance degradation. To be scoped out.

@Jdforrester-WMF, the main speed-up for VE would come from using Parsoid HTML for views, which in turn requires small HTML, which in turn means fetching data-mw separately. Until then, it won't improve performance.

That said, there are many intermediary steps on the road to Parsoid HTML for views. Storing data-mw separately is basically one of those.

So should we re-phrase this into loading data-mw from a separate API call alongside the body content in ApiVisualEditor.php?

Roan suggests that, instead, this should be RESTbase's problem and VisualEditor continues to dumbly expect data-mw in the payload it gets from the server.

In T88623#1109568, @Jdforrester-WMF wrote:

Roan suggests that, instead, this should be RESTbase's problem and VisualEditor continues to dumbly expect data-mw in the payload it gets from the server.

Given that T90374 will almost certainly be done before T78676, it would be nice for RESTbase to offer recombined HTML. In VE, we may want to load data-mw separately for encoding efficiency, but given that reference data has been moved out already, that doesn't seem very urgent, nor is it even obvious that it's a good idea.

In T88623#1109590, @Catrope wrote:

Given that T90374 will almost certainly be done before T78676, it would be nice for RESTbase to offer recombined HTML. In VE, we may want to load data-mw separately for encoding efficiency, but given that reference data has been moved out already, that doesn't seem very urgent, nor is it even obvious that it's a good idea.

One thing we discussed a while ago was for VE to load template metadata separately and only when the user actually wants to edit/create a template instance. This would help maintain the initial data-mw load (whereever it's coming from) small once we enable HTML template parameters editing.

Why is this in mobile mvp?

In T88623#1514091, @Esanders wrote:

Why is this in mobile mvp?

Reduction of HTML payload to reduce traffic.

Not really part of the minimum viable product. This is fairly large piece of work that should block mobile.

In T88623#1523974, @Esanders wrote:

Not really part of the minimum viable product. This is fairly large piece of work that should block mobile.

If it blocks the MVP then it's part of the MVP…

Note that we are at least 3-4 weeks away before both Parsoid and RESTBase are ready with code, storage, and API changes. At that point, we will also have to evaluate which of the clients are ready to switch over, and if not, what the performance impacts are on the Parsoid cluster (to convert from the new to the old version), and whether any of the clients have any blockers on this deployment. But, I am updating tasks and creating new tasks on all Parsoid HTML clients to start surfacing any issues that need to resolved for T78676: Store & load data-mw separately to be enabled in production.

Update. This is no longer blocking mobile, as instead with the sections API we're now able to grab html and data-mw per section (which is the reason this task was here).

However, once T55784: [EPIC] Use Parsoid HTML for all page views is done, for efficiency, if we're starting from the read HTML without data-mw and we're trusting the local HTML, we'll want to zip the data-mw into the page on load somehow, but that need is probably a long way away.

I'll re-purpose this task for that.