Note that core already does a lot of 'expensive' startup work wrt loading extensions/etc on every request. So it doesn't really make sense to super-optimize this when we're still sitting behind core startup. Although latency is certainly additive, we should get a quantitative sense for what percentage of the request startup time Parsoid is responsible for.

In addition, any cache here will complicate deployment of mediawiki-config changes, which then have to flush any caches after the configuration changes leading to various new race conditions.

See also T270307: Parsoid needs a way to unregister extension modules for testing -- some parser configuration changes (like which extension tags are enabled) are currently bundled in SiteConfig. We'd probably want to do some refactoring to make SiteConfig more purely static before caching it, or else have some way to disable caching when running unit tests and parser tests.