A few ideas:
- Disable this feature in the main namespace in WMF production. This is similar to other optimizations in core, and could be conditional on $wgMiserMode.
- Split this feature by namespace ID. Instead of reading MediaWiki:Subjectpageheader we could read MediaWiki:Subjectpageheader-1 where 1 is the namespace ID. This is similar to how we handle Editnotice. This would mean the expensive code only runs in namespaces where a given community has chosen to enable it. This could be combined with the first idea, e.g. split by namespace to avoid the overhead in most namespaces, and as defense in depth explicitly disallow the NS0 (MediaWiki:Subjectpageheader-0) under $wgMiserMode.
- Split this feature by content model (per original use case T151682#10065952 and T355159). Instead of reading MediaWiki:Subjectpageheader we could read MediaWiki:Subjectpageheader-css, MediaWiki:Subjectpageheader-Scribunto etc where the last segment is the content model ID ($wgContentHandlers key) . We can then cleanly exclude "wikitext" from the feature, because wikitext pages can and should should simply place any shared template in their wikitext slot instead. This would not need to involve wgMiserMode or WMF-specific configuration.
Another idea:
- Move the computation from the uncached skin layer, to behind the ParserCache, e.g. in setExtensionData or some other extra field that the skin can pull out afterward.
Afaik the return value does not vary by user or request, only by title.
See also:
- T408264 which proposes ParserCache for this message for a different reason (to allow categories). This task is orthogonal from that. We can compute this in the ParserOutput object while continuing to process it as an interface message without any metadata exports, which I suggest we keep that way within the scope of this task.
- T151682#7623800 which talks about why we can't do per-namespace caching