BUGFIX: Improve UI loading performance by removing UI nodedata script tag and using less data

[Sebobo]

What I did

With this change the minimal required nodedata for each node in the rendered
content is inserted as data attribute and not as inline script anymore.
This improves performance as no extra function call is executed for each node.

Additonally the reduction in rendered node attributes reduces the output filesize and again improves loading time.

To prevent just-in-time loading of nodes all incomplete nodedata is requested after the guest frame has finished loading.

One big benefit of that is that the scripts tags won't interfere with JS plugins anymore and using the Fusion Augmenter will not wrap a single object with a ContentWrapping with another tag due to the script tag.

Fixes neos/neos-development-collection#2988

How to verify it

• Check whether content is still properly editable
• Inspector shouldn't show a loading spinner when content is selected
• preview document should be smaller (10-30%) than before and load quicker (10-40%)
• No script tags with node data in the raw preview html document

• Load nodedata async after guest frame has loaded
• Visualise for user that backend still loads data before page is fully editable

[Sebobo]

I'm not sure how breaking this could be right now, therefore draft for now ;)

@grebaldi I remember you started working on a replacement for the script tag, so your insights here would be very welcome.

This doesn't need to be included in 8.3 but maybe we can :)

[Sebobo]

Some test results with 82 nodes (haven't found a good way to measure time to interactive with the iframe):

With Script Tag + with full Properties

Document size: 245KB / 14.6KB
Document rendering time: ~220ms
Transferred: 3.3MB
Finish: ~1.7s
Load: ~620ms
Requests: 28

Without Script Tag + with MinimalProperties + ondemand node loading

Document size: 198KB / 13.3KB (~80%)
Document rendering time: ~140ms (~65%)
Finish: ~1.6s
Load: ~620ms
Requests: 28

Without Script Tag + with MinimalProperties + Node batch loading

Document size: 198KB / 13.3KB (~80%)
Document rendering time: ~140ms (~65%)
Finish: ~2.1s
Load: ~660ms
Requests: 29

[bwaidelich]

Are those changes related?

[Sebobo]

Not a 100%, just some optimisation as the locale is switched twice for every node triggered by the augmentation

[Sebobo]

I tested a variant of this change in my customers project and the document size was reduced from 1.8mb to 1.2mb.
Without any nodedata it's 700kb. So I think we should invest further time in the future to really only include what we need.

Also there are two child nodes queries for each node to get document and content child nodes. Maybe we also don't need those for the initial rendering with some adjustments. Right now it would break some parts of the ui.

[Sebobo]

OK optimised a bit more and completely removed nodedata from the guest frame:

Without NodeData in augmenter

Document size: 108KB / 7.5KB (~44%)
Document rendering time: ~123ms (~55%)
Finish: ~2.1s
Load: ~610ms
Requests: 30

When clicking through the demo site each page is about 50% quicker to load which actually feels much nicer.

[bwaidelich]

Great initiative, thanks for taking care.
Just one consideration: additional HTTP requests are fast locally, but they can be a bottleneck on remote servers. Not suggesting, that it is in this case but we should keep it in the back of our heads and test with throttled bandwidth

[Sebobo]

Yes of course. At the end we need the same amount of nodedata. But we kill the overhead of the function calls and document parsing.
Even if the combined loading time is the same as we load the nodedata, it feels faster as the page is already displayed much earlier while the data is fetched and the JS doesn't block the rendering. We send a bunch of queries at the initial load, so while the user starts moving the mouse to an element ideally the data is already there and simply be injected into the store instead of being parsed.
This makes especially a difference when you quickly navigate between pages.
The inspector also shows a loading spinner if the node is not fully loaded yet. So we have to check whether other places might need some visual feedback that we are still loading something if the connection is slow.

[Sebobo]

@bwaidelich I tested the loading performance a while yesterday with "Fast 3G" connection + Caching in my local Dev Context.

Result: The page loads much faster, but if you try to immediately edit text in a CKEditor, the first click only selects the element instead of showing the caret to start editing. The second click then works.

I want to test this on an actual remote server in Production Context to get a feeling for it.

I also checked whether I can adjust the LoadingBar to wait for the GuestFrame to be initialised, but this is not a simple change right now. I would make sense to have a loading indicator of some kind for the guest initialisation too. This is already currently problem, when initializeGuestFrame takes a bit longer. Just now with my change it takes a bit longer depending on the connection.
But the request runs in parallel with other requests like fetching node policies etc. So it's not simply adding to the loading time. But of course this depends a bit on the setup too.

We currently also load some nodes twice as the structure tree needs them too. I want to check whether I can then skip some of them.

[Benjamin-K]

Thanks for taking care of this. As a side effect, this will also help with some CSS selectors, as with the current approach selectors like .element:last-child don't work as expected in the backend.

[Sebobo]

Realised today this will also fix the issue neos/neos-development-collection#2988 with the Fusion Augmenter when augmenting a single content element. Previously it added another tag as it counted the element itself and the script tag instead of modifying the outside tag of the content element.

[Sebobo]

The two main performance hogs which makes the async request for the nodedata slow is in \Neos\Neos\Ui\Fusion\Helper\NodeInfoHelper::renderChildrenInformation which queries each nodes children twice.
In my tests this takes at least 50-60% of the duration.
The other one is the very inefficient conversion of each node context path from the query to an actual node.

It seems this was less of a problem in the previous version as during rendering the same first-level-node-cache was automatically used where possible.
I think this could be optimised quite a bit in a separate PR.

Right now I'm getting great results by optimising \Neos\Neos\Ui\ContentRepository\Service\NodeService::getNodeFromContextPath in skipping the creation of a completely new context with site and domain for each requested node.
For the child node query I don't have a great idea right now. This could be easier with Neos 9 maybe.