Is there any way we can limit the CSS that is shipped to what is *actually* needed on a given page (both for server-rendered and client-rendered components)? Having to load ALL of “codex-css” and then Vue, and then Codex JS means a lot of code
See https://phabricator.wikimedia.org/T323179#8455644 for what the current proposed implementation path for how to ship CSS Codex components alongside the JS ones we are already building. That proposal is informed by the performance considerations explored here, but it is balanced with some practical concerns (minimizing risk, not needing changes to existing infrastructure, etc).
Here is a short summary of the performance implications of the approach under consideration:
- Codex components will be organized into a few different modules for use inside of MediaWiki, similar to how we currently do things with OOUI. To do this we'll need to create additional bundles using Vite that contain the JS and CSS for a sub-set of our components. For example a bundle that just contained Codex buttons and related components would have codex-buttons.js and codex-buttons.css. This is similar to how we are currently building the codex-search package as a separate bundle.
- These bundles will get included in MediaWiki as separate ResourceLoader modules. Each new codex "sub-package" will likely require two RL bundles: one for the styles (which can be used by itself if only CSS-based components are needed), and one with the JS. The latter module will have the former as a dependency.
This will allow for users of Codex inside of MediaWiki to gain the following benefits:
- They won't need to load ALL of Codex just to use a small number of components. Without more sophisticated front-end build tools (which all require a Node.js runtime) we can't do perfect tree-shaking, but at least this will allow us to avoid the worst inefficiencies (where all of Codex needs to be loaded when only one component is needed). We believe this will be acceptable for now from a performance standpoint (we do the same thing for OOUI). If more optimization is needed then we need to explore introducing a true front-end build step in MediaWiki.
- CSS can be loaded independently of JS – and subsequent loading of JS (to progressively enhance the page) will not require re-loading the CSS that has already been delivered. Simple features that don't need JS at all can just use the CSS style module for the components they need and be done with it.
- DST discusses potential problems and solutions
- DST determines a path forward based in tandem with choosing implementation path (see T323179) and documents work via subtasks of the CSS-only components epic