Page MenuHomePhabricator

Spike: Should the mobile site vary the ParserOutput cache?
Closed, DeclinedPublic

Description

The mobile skin performs various transformations on content that would be more efficiently done inside the parser itself rather than retroactively on the parsed and cached content.

To support our work in lazy loading of images and references to improve the experience for users on 2G connections we would ideally like to omit the HTML for the image tag and references list inside the parser itself. Obviously we do not want to impact the HTML version of the desktop site until we can make a strong case for performing these changes for all users.

Questions to answer:

  • Is this even an option, will @tstarling scream at us and chase us with a pitchfork?
  • What are the trade-offs of maintaining a separate parser cache?
  • How would we go about doing this?
  • Is it possible to vary parts of the parser output e.g. at the references level and images level?

Duration: 4hrs

Event Timeline

Jdlrobson created this task.Feb 4 2016, 9:50 PM
Jdlrobson raised the priority of this task from to Normal.
Jdlrobson updated the task description. (Show Details)
Jdlrobson set Security to None.
Jdlrobson added subscribers: jmadler, Bianjiang, Mholloway and 19 others.
Jdlrobson updated the task description. (Show Details)Feb 5 2016, 8:55 PM
daniel added a subscriber: daniel.Feb 9 2016, 5:08 PM

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

Bene added a subscriber: Bene.Feb 9 2016, 9:50 PM

@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
    }
}
Jdlrobson closed this task as Declined.Aug 11 2016, 8:43 PM

Answer: Probably not.
We may want to revisit this however if we find the increased use of MobileFormatter is causing more trouble than its worth.