Ideally, we would not have to split the parser cache. We would cache the same HTML blob for "desktop" (static) and "mobile" (dynamic). For the static view, we would compose/massage the HTML on the server side, while for the dynamic view, we do that on the client. See also T106099: RFC: Page composition using service workers and server-side JS fall-back

@daniel not sure I'm following you here.
It sounds like you are talking about bloating the parser cache rather than splitting it?
e.g. ParserOutput has an extension property e.g. mobileFrontendHtml ?

@daniel I'd be keen to understand specifically what needs Wikidata has and whether they can be done successfully via the MobileFormatter class.

Currently MobileFrontend would like to lazy load images and references which ideally would be done in parser hooks resulting in 2 different versions of text on the ParserOutput object.

Maybe we should have a chat about this in IRC?

@Jdlrobson For Wikibase, we would like to do the following:

• omit a large JS config variable (the serialized entity) for the mobile view (or more generally, when editing is disabled, e.g. for old revisions).
• lazy-load the content of some sections (like the sitelinks and external identifiers) in the mobile view.

My approach would be to generate a ParserOutput without the serialized entity in the JS variable, and with placeholders for the lazy sections. Then, when serving to a "non-mobile" client, inject add the JS variable and inject the HTML for the sections on the fly, using a OutputPage hook.

The problem is that we'd want to cache the HTML for these sections too, and not re-generate it on the fly. So we need to attach it to the ParserOutput after all. We can do that using ParserOutput::setExtensionData. That way, the info is cached, but won't get served to the client, unless we explicitly splice it in. And we can do the splicing as appropriate for our client.

We have to be careful though that any distinction we make when constructing the OutputPage from the ParserOutput has to be consistent with how the web cache is split.

This all sounds very similar to what we have in mind. (you should catch up on what we are doing for lazy loading references - T123328 and experiments with the MobileFormatter which allows us to strip navboxes (T110613) by class name which we later want to lazy load.

Ideally the parser could be restructured so that instead of one god function getText we could get a structured json which represents the page and use that for mobile and desktop.

{
  sections: [
    {
      title: history, level: 2,
      html: "text bla bla bla
    }
}