4.45 KB of static doc-extra tab wiring 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. Find the inline <script> block starting with var hashviewer = ... in the HTML source
3. Visit another page and compare the two blocks

Expected

The tab-switching code, which is the same for every page, is served as a cacheable resource.

Actual

The block generated by flamingo/docextra.vm:112-158 is 4,448 bytes — 4.8% of the document — and is byte-for-byte identical between Sandbox.WebHome and Main.WebHome. It wires up the Comments / Attachments / History / Information tabs and is inlined, uncompressed and uncacheable, on every page view.

Suggested fix

Move it to a Velocity-evaluated JS skin file with the locale as part of the cache key, as the skin already does for other generated scripts — flamingo/editinline.vm:24:

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

Only the small amount of genuinely per-page state (which anchor is active, taken from the URL hash at docextra.vm:113) needs to stay in the document.

No trade-off: after the first visit this is a cached file rather than 4.45 KB on every page view.

Not in scope here

The same block also makes the first doc-extra pane load eagerly (docextra.vm:122-127, #if ($foreach.count == 1)), which is why ?xpage=xpart&vm=commentsinline.vm is fetched on every page view. That looks intentional — the first tab is meant to be shown, and it does end up visible — so it is deliberately left out of this issue; it would be a separate discussion about server-side rendering or viewport-deferred loading of that pane.