- Mentioned Here
- T106099: RFC: Page composition using service workers and server-side JS fall-back
T124356: Incorrect TOC and section edit links rendering in Vector due to ParserCache corruption via ParserOutput::setText( ParserOutput::getText() )
T125899: Spike: Should the mobile site vary the ParserOutput cache?
T119078: [Task] Move wbentity JSON to the end of the HTML
Hah! Very timely.
I'm pondering the same question. We are keen to lazy load content (references and images) in the mobile web experience for mediawiki.
So it looks like I was right: mobile uses a separate web cache, but shares a parser cache. That makes it tricky to serve a different representation of the content for mobile. See T125899: Spike: Should the mobile site vary the ParserOutput cache?
Quick summary of the investigation:
- mobile uses separate web cache keys, so no problem there.
- mobile shares the parser cache with the desktop version
- if we remove the blob from the cached ParserOutput for mobile, we need to split the parser cache. That may be doable, but isn't great, see T125899.
- it would be nicer to never put the serialized entity into the ParserCache, but add it on the fly when serving the editable (desktop) interface.
- We'd need a mechanism for manipulating the ParserOutput when it gets pulled from the ParserCache.
- We may want to cache the serialized blob separately (which means more fun with purging).
- compare T106099: RFC: Page composition using service workers and server-side JS fall-back
I suggest to put any data we want to optionally serve into the ParserOutput's extension data slots. That way, the info is cached, but won't get served to the client, unless we explicitly splice it in via an OutputPage hook. We can do the splicing as appropriate for the specific type of 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.