Page MenuHomePhabricator

mobile-html: Consider moving /page/metadata endpoint into mobile-html
Open, LowPublic

Description

Background information

The /page/metadata endpoint contains information that is buildable from the mobile-html page

What

Consider removing the /page/metadata endpoint and adding the JS required to build it to the mobile-html page

How

Expose the information available via /page/metadata via new functions in pagelib.c1.Page

Open questions

Is the parsing slow enough in a mobile browser that'd it be better to download the cached, pre-processed data from the server?

Event Timeline

JoeWalsh created this task.Aug 7 2019, 3:53 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 7 2019, 3:53 PM
Jhernandez added a subscriber: Jhernandez.EditedAug 13 2019, 4:17 PM

Re: Open questions, it seems like the JSON blob can be quite big, so embedding it in the HTML may have implications for the time to interactive on the browser. Scraping it from the HTML is doable and it shouldn't necessarily cause repaints/reflows that would impact performance, but it may take a chunk of main thread UI time. I'm not sure if that would have an impact on the user's interactions with the webview.

From grooming:

TOC generation could be done client side, but we are getting language links, categories and other things from the mediawiki API and bundling it there.

So moving it into mobile-html would mean the mobile-html endpoint would be slower and not improve the bandwidth usage.

Another option could be move some of the things on metadata (the ones that depend only on the parsoid HTML) to the page library JS client side. Categories, table of contents, and some of the other things could be moved. Others like language links would not, would still need language links.

It was commented that it would be interesting to make an audit of what is actually needed by apps from this service before making any decision, given there may be information we can deprecate that would help on making the right call here.

Waiting for @JoeWalsh to come back and discuss.

Jhernandez lowered the priority of this task from Normal to Low.Aug 14 2019, 3:52 PM
bearND added a subscriber: bearND.Aug 16 2019, 4:20 AM

The things we can't get from Parsoid are:

  • language links
  • protection
  • description source

I think if for language links we just need the number of language links then we could embed that in the head of mobile-html. If a user does click on the languages button then the app could make the MW API request.
Protection is fairly small.
Description source is small, too. Not even sure if the latter is needed anymore since mobile-html already provides the correct edit description header.

@bearND description source is already in /page/summary so it could be removed here. If it's easier to move language links or protections to summary I think that'd be fine as well, but I think at last check the thought was to try to remove as much from /page/summary as possible due to performance concerns

@JoeWalsh I don't see description_source in https://en.wikipedia.org/api/rest_v1/page/summary/Dog.
I think we want to avoid adding more to /page/summary without the web teams consent. They use the summary endpoint for their page previews.

language links: Do we need more than just the number of language links for the footer?

@bearND ok - I was wrong, I'm not seeing the description source there either.

I believe language links were removed from the footer in the new designs in T226094 and the only way to access the language list would be through the native toolbar button. CC @cmadeo @schoenbaechler to confirm that the language links item was removed from the unified footer

@bearND + @JoeWalsh confirmed, we would like to encourage users to access languages via the toolbar button.

Do you show the number of language links in the toolbar button? If not we could probably consider delaying getting the languages list for this until the user actually clicks on it.
I'm assuming that this is relatively rare. Do we have any data showing this?

@bearND we do not show the number of language links in the toolbar button