9.7 KB of static RequireJS configuration is inlined in every page instead of being a cacheable skin file

Context

Measured on a plain page view (Sandbox.WebHome, no images, no comments, no macros, 18.8.0-SNAPSHOT), the server sends a 93,113-byte HTML document of which about 63% is not useful at first paint: 33.5 KB of markup for dialogs and menus nobody opened, and 24.9 KB of inline <script>. The overhead is a near-constant 51-57 KB per page view whatever the page contains, and the document is not compressed, so those are real bytes on the wire every time.

Reproduction steps

1. Visit http://localhost:8080/xwiki/bin/view/Sandbox/
2. Look at the largest inline <script> block in the HTML source
3. Visit another page, and compare the two blocks

Expected

Static JavaScript that does not depend on the page or the user is served as its own cacheable resource, and only the genuinely page-specific values are inlined.

Actual

The largest inline script block is 11,358 bytes — 12.2% of the document — and it is almost entirely static:

• 99.91% identical between an Admin and a guest on the same page. The only difference is three lines: XWiki.hasEdit, XWiki.hasProgramming, XWiki.hasBackupPackImportRights.
• 99.76% identical between Sandbox.WebHome and Main.WebHome.

Splitting the block:

That 9,729-byte part depends only on the wiki, the skin and the platform version — not on the page, the user or their rights. It is re-sent inline, uncompressed and uncacheable, on every single page view.

Source: flamingo/javascript.vm.

Suggested fix

Move the static part to a Velocity-evaluated JS skin file served at its own URL with a cache key, leaving only the ~800 bytes of page/user-specific values inline. The skin already does exactly this elsewhere, e.g. flamingo/editinline.vm:24:

$xwiki.jsfx.use('uicomponents/widgets/fullScreen.js', {'forceSkinAction': true, 'language': ${xcontext.locale}})

There is no trade-off here: in steady state it is one cached file instead of 9.7 KB per page view, it adds no request after the first visit and no latency to any interaction. Of everything found in this audit it is the best ratio of benefit to risk.