Details
-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
11.10
-
Unknown
-
Description
Reproduction steps
- Visit http://localhost:8080/xwiki/bin/view/Sandbox/
- Open the browser debugger, network tab
- Reload the page, and do not open the export modal
Expected
The export tree is not built, and no page tree query is sent to the server, until the user opens the export modal.
Actual
The tree inside exportTreeModal is instantiated during page load and its root node is expanded straight away, which sends 4 requests to /bin/get/<Space>/<Page>?... on every page view — server-side page tree queries for a modal that was never opened.
On a terminal page, where the exportTreeModal markup is not even emitted, the xwiki-export-tree and xwiki-export-tree-filter modules are still fetched and the initialisation still runs against an empty selection.
The modal markup itself is also inlined in the HTML of every page: about 5.8 KB for exportModal plus 4.5 KB for exportTreeModal, for anyone who can see the "More actions" menu, guests included.
Analysis
The last statement of the top-level require(['jquery'], ...) block in uicomponents/exporter/exporter.js is:
require(['xwiki-export-tree', 'xwiki-export-tree-filter'], function () { $('.export-tree').exportTree(); });
$.fn.exportTree ends in a call to .xtree(...), which calls jstree(...), and instantiating jsTree immediately triggers _load_node on the root node — hence the requests above.
Note that jstree.min.js and tree.min.css themselves are not wasted on a default flavor, because the Navigation panel displays a tree on every page and legitimately needs them. What is wasted here is the second, hidden tree instance and its server round-trips.
There is already a show.bs.modal handler in the same file, but it only refreshes an existing tree: waitForExportTreeReady() calls treeElement.jstree(true) and assumes the instance has already been created. So moving the initialisation into that handler requires making waitForExportTreeReady cope with a tree that has not been instantiated yet.
The sibling exportModal already uses exactly the wanted lazy pattern in the same file, so there is a local precedent to follow.
Suggested fix
Instantiate the export tree from the show.bs.modal handler rather than on page load, and adapt waitForExportTreeReady accordingly. Loading the modal markup itself on demand would be a further improvement, in the spirit of XWIKI-22266.
Attachments
Issue Links
- relates to
-
XWIKI-22266 Load the modal for watch settings asynchronously when needed
-
- Open
-