@Owyn A fair amount of the separation called for here has been achieved over the past few years. Especially these two changes:
- resourceloader: Move queue formatting out of OutputPage. (See ResourceLoaderClientHtml.php and T87871)
- resourceloader: Move any module loading from OutputPage and Parser to Skin. (0048c3e25, c7e00974c7, as grand way of resolving T130632).
The RFC also states (emphasis mine):
One advantage of [this refactor] is that since 100% of the data to render a page is prepared before page rendering, it provides another opportunity for caching.
This is something I also describe in T140664 (Prepare MediaWiki for API-driven frontend). The objectives in that task align very much with this RFC. In a nut shell: All data required by the Skin must be injected into it. This means we can cache the "whole" page (like HTMLFileCache), but still apply the Skin on-demand in the remaining lightweight PHP layer.
In addition, it would enable larger deployments such as at Wikimedia Foundation and Wikia, to consider moving the Skin to a separate service. For example, we're experimenting with using the client-side Service Worker feature, to compose the web response from pre-cached skin HTML template, the page data from RESTBase (cached in Varnish). This means logged-in users and logged-out users both benefit from edge caching. The only difference being that for logged-in users (and logged-out users with an edit session) we'd periodically fetch user information from the API that is needed by the Skin (e.g. edit rights, user groups, talk notifications, etc.). This could happen in the background and not block individual page views.
Related thinking: