In-place editing preloads the whole CKEditor in view mode

Reproduction steps

1. Log in as a user who has edit right on the page
2. Visit http://localhost:8080/xwiki/bin/view/Sandbox/
3. Open the browser debugger and make sure "disable cache" is checked
4. Reload and look at the network tab, without ever starting to edit

Expected

The WYSIWYG editor code is not downloaded until the user shows the intention to edit the page.

Actual

About 955 KB is downloaded in view mode:

• ckeditor.js — 766 KB
• xwiki-platform-ckeditor-plugins/webjar.bundle.min.js — 136 KB
• CKEditor/Translations — 11 KB
• CKEditor/InlineEditor, CKEditor/EditSheet (both JSX and SSX), the wysiwyg webjar CSS
• an XHR to /bin/get/<Space>/?xpage=editactions

On a Fast-3G connection (1.6 Mbps, 150 ms RTT) a near-empty Sandbox page takes 15.5 s to finish loading, and this is the single largest contributor.

Analysis

The UI extension itself is correctly guarded — it checks inPlaceEditingEnabled(), $hasEdit, $xcontext.action == 'view' and !$doc.isNew() — and the preload is already deferred to after window.load, with a comment saying "Preload the content editor code without slowing down the page view". So the intention not to delay the rendering of the page is already there.

What is missing is not downloading the code at all until it is needed. The preload is triggered unconditionally from the top-level require(['jquery'], ...) in XWiki/InplaceEditing.xml, which calls preload(), which in turn calls initActionButtons() — the xpage=editactions XHR — and requires config.contentEditor, i.e. xwiki-ckeditor-inline, which drags in the whole CKEditor.

Deferring the download to after window.load helps the initial rendering but is still a significant cost for users on slow or metered connections, and it is pure waste for the many page views that never lead to an edit.

The only configuration available today is edit.document.inPlaceEditing.enabled, which turns the whole feature off. There is no way to keep in-place editing but load the editor lazily.

Suggested fix

Trigger the preload when the user shows an intention to edit — for example on the first hover or focus of the edit affordance — or run it through requestIdleCallback, and make the behaviour configurable.

As a side effect this also removes the duplicated tree.min.css request reported in the companion issue.