[UI initialization performance] Research how the UI is initialized (the flow) and which steps take significant amount of time

[Reinmar]

Part of #12592.

[niegowski]

While analyzing the UI init flow, I checked different approaches to cut that time. 

Lazy render

The first idea was to postpone DOM element creation to the first moment that it would get visible. There are some view classes that have a separate isVisible property, so I was trying to move that property to the base View class and skip rendering until the first isVisible change. Unfortunately, there are a lot of places that expect the View#element property to be initialized by View#render(). The most common is FocusTracker#add( element ) and KeystrokeHandler#listenTo( element). Another obstacle to this approach is ViewCollection that expects a DOM element in ViewCollection#setParent().

This approach would be baked into the UI engine and would not require changes in features code but OTOH it could break some custom UIs that expect DOM element to be ready to use just after calling render().

Lazy init

Another approach was to postpone the construction of view instances that are expected to be not visible on the editor initialization (like dropdown panels, and widget toolbars). There is a branch that shows some improvements in UI init time: ck/12682-performance-reference...ck/12682-performance-lazy-init

This branch does not include all possible optimization places but already there is a visible performance improvement (see table at the bottom of this comment).

Toolbar grouping

We've seen that disabling this option improve the load times. In scenarios where the initialization time is critical, we recommend disabling it. See config.toolbar.

SVG parsing overhead

I checked whether SVG parsing (for IconView and WidgetTypeAround) takes a significant time (by disabling SVG loading completely) and I think that it does not impact the init time too much.

DOM element clone vs create

Another idea to verify was to clone existing DOM elements instead of creating new ones. In tests, it looked like it performed the same or even the performance was worse.

UI Init time measurements

Reference: https://github.com/ckeditor/ckeditor5/compare/ck/12682-performance-reference
Lazy init: ck/12682-performance-reference...ck/12682-performance-lazy-init
Without SVGs: ck/12682-performance-reference...ck/12682-performance-without-svg

[Reinmar]

Research summary:

• 🔴  Lazy render is tricky. Possible, but may cause instability by increasing the complexity.
• 🟢  Lazy initialization worked great. It's the first thing to change.
• 🟡  We recommend avoiding automatic toolbar grouping when initialization performance is crucial. No actions from this item for now, though.
• ❓  SVG parsing might be negatively impacting the performance. We were testing completely disabled SVGs. We'd need more time to verify a more realistic case where they are created, but without parsing.
• 🔴 Cloning vs creating new elements. No difference or even worse results.

Plan:

• Let's work on lazy initialization.
• Let's devote some more time to check SVGs. Especially that we were considering this anyway: Why are icons scattered across packages instead of having them all in ckeditor5-ui? #12515.

[Reinmar]

• 🟢  Lazy initialization worked great. It's the first thing to change.

Extracted to #12890.

[Reinmar]

• ❓  SVG parsing might be negatively impacting the performance. We were testing completely disabled SVGs. We'd need more time to verify a more realistic case where they are created, but without parsing.

Extracted to #12891.