TipTap with Blocks using multiple Compositions loads slow

[marcemarc]

Which Umbraco version are you using?

v16.0

Bug summary

We are experiencing an issue with slllllloooooooowwwwness with Umbraco 16.

Both sites are on Umbraco Cloud

The first is a project 'not live yet' which started on V15, and has recently been bumped to V16, in terms of whether the move to V16 introduced the issue, is not clear, because it's only now that content is being entered on a grand scale before launch.

The second project is a migration of a V13 site, and because we have seen the issue on the first project, we could see it occurring there too.

The issue is with 'how long' it takes for the TipTap Rich Text Editor to display 'ready for editing' - after the rest of the UI elements have been loaded. This is intermittent, but can be 3 to 4 seconds later, and because the toolbar and content finally appearing causes layout shift (it can be quite disruptive).

The issue seems to be related to pages which use the Block List, with Blocks containing the RTE, I haven't seen the slowness when the RTE is used on the Document Type itself.

Essentially when you add a new block ,or open a block the UI starts to load and once all the other elements have loaded there is a good few seconds of the TipTap editor loading 'snake' three dots, until it appears. If you close the block and immediately open it again, it will sometimes be fast, and sometimes be just as slow - it therefore doesn't appear to be a 'first time - then cached' situation, it appears more to be some kind of race condition or dependant on other factors outside of the UI, my machine was not maxed out and there is no strain on the SQL Server, and it's running on Umbraco Cloud so the instances are 'big'

The issue happens on dev / staging and live so I think, rules out the issue being related to DotNet Environment settings.

I've not been able to recreate it locally with a vanilla V16 and Paul Seals starter kit :-( but can invite you to either Cloud project to observe.

Specifics

I made a video

https://youtu.be/Y99tIKrYkYE

(the same behaviour is observable without dev tools open)

Basically any block that is opened, with a TipTap RTE, has about a 30% chance of taking 3-4 additional seconds to load, this RTE allows inline blocks to be inserted (2 types) but this is also the case with RTE's without inline blocks enabled.

On both projects, I can see long running requests to the Management API endpoint

eg
https://the-project-uksouth01.umbraco.io/umbraco/management/api/v1/document-type/262e9d93-e32e-4fae-bc32-4c36fde90f4c

With the block list there is often multiple requests to this endpoint with the same guid - but assuming this is the world of webcomponents, rather than anything sinister, the timings for these requests seem long.

The first project is a new build, there are

34 Page Document Types, supported by 9 Composition Document Types
37 Element Types for blocks, 11 Settings Element Types, supported by 4 Composition Element Types.

However, anecdotally, the 'slowness' appears to occur after the requests to the Management API have been made, it doesn't appear to be blocked waiting for the data to return from the Management API endpoint, but what do I know!

Third party packages installed:
Slimsy
TheDashboard
ClientDrawer
Contentment

Steps to reproduce

I guess, create a new Umbraco Cloud site,

build a project with 30 DocTypes using 10 compositions, and using the Block List editor, with 30 different block types using 5 different compositions...

Make sure the Block list element has a TipTap RTE

Add two inline blocks to the configuration of the RTE

Then populate the site with content, A homepage, 6 sections, containing 5 to 6 pages within, and then a News section with 30 odd articles...

I guess you only need to add the content and the multiple different doc types if the issue isn't immediately recreatable with just a block list (I couldn't recreate it with Paul Seal's starter kit for example).

Then try opening a block with RTE Content in repeatedly, perhaps having nested blocks too, and see if you can see the slowness.

Expected result / actual result

Just want it to load pretty snappy, with all the different components loading at different times it gives a really unsmooth jerky experience, like the system is struggling to get the things in front of your face (when really it's doing it as fast as it can) - it might be a less stressful experience if it takes longer but all the UI elements are loaded, but appreciate that's a different thing to this issue - all we are expecting here is the RTE being ready to go in a second, only a mere flash of the three dots loading...

I appreciate this is a really vague description, but I'm pointing the info out there in case this is a really super obvious thing you are aware of and working on, so I can stop investigating, or if other people are experiencing same but it feels to vague a thing to raise, at least there is a ticket people can add observations too, and I guess we'll continue digging here and update ticket if we find something or have a more reliable way to recreate it.

---

This item has been added to our backlog AB#54707

[github-actions]

Hi there @marcemarc!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[leekelleher]

Thank you @marcemarc, I appreciate the level of detail provided, very helpful! 🙏

There are a couple of points that sprung to mind while reading through your bug report.

1. The Tiptap RTE loading layout shift.
   I agree, that can be quite jarring, it'd be good to have placeholders for the toolbar buttons.

2. The Management API calls for document-types.
   Issue BlockGrid Loads Document Types Twice #19604 reports that the Block editors are making twice the calls to the server. I'd made a PR for a fix this morning, Repository Details Manager: Prevent making requests for empty arrays #19731. If that's a similar case for you, then it should dramatically reduce the number of server requests, (given the amount of element-types/compositions you have).

I'll schedule some time to try to reproduce this locally and investigate further.
If I'm unable to do so, then I'll reach out to organise access your Cloud project.

In the meantime, please do feel free to add any further details or observations here. 🕵️

[marcemarc]

@leekelleher Thanking you, I will try to do a further recording, it is the strangest thing, but we have a bit of a workaround... as soon as you get the three dots slow down once, if you grab the Url you are working on and bung it in a new tab (because of how the Urls now track and link to any open block list or picking panels) then it's super fast again - it's possible to cut and paste the Url and have it load fully in your new tab, before the 3 dots have finished loading in the old tab... and once you have done this, the 3 dots slow loading doesn't occur again, for about 5 minutes...

I mean it's not a 'good sell' work around but everyone is very excited, having struggled for two weeks, and are just happy to be able to get stuff in quickly as the deadline approaches.

This makes me feel like either, 'something builds up' memory leak, or number of requests overwhelms tab? or there is something else in this particular site, that when you land on it, causes an issue in the tab, so it feels like a few minutes and it comes back, but that's only because you've hit the custom dashboard or loaded a collection 'or something else'... that creates the slooooow conditions.

.. testing continues ...

In terms of multiple requests for DocTypes, via the Management API, it's often more than twice, I think 12 requests I counted once, and these aren't cached in the browser, but appear cached serverside...? CachePolicy. is how they get called from the repository, and when it's quick, these multiple requests are still being made... so maybe a red herring, unless it is just the number of requests in quick succession annoying the browser tab.

[leekelleher]

Thanks @marcemarc, noted.

Without sounding like Captain Obvious, with the browser caching, make sure that you don't have "Devtools > Network > Disable Cache" enabled. I've been caught out by this before. 🤦

[marcemarc]

@leekelleher if you see in the original video it is not disabled :-P and also slowness occurs without dev tools open! but good to suggest it, as I thought same thing, am I exacebating it by investigating... but also it is the editors reporting the issue and they don't have dev tools open.

This is the switching tabs workaround...

SwitchTabSolution.mp4

Interesting thing here is that the 'tree icons' aren't loaded at first, but when I go to the new fresh tab, and everything loads directly on the page, they are.. hmmmm - but you can see how exciting it is to have it super fast for a few minutes after switching...

[marcemarc]

@leekelleher exciting update... disabling all browser extensions - its fine...

But here's the thing, different people have different browsers and different extensions, and we've experienced the issue across both Edge and Chrome - it doesn't seem to be a specific extension.

I started reenabling one by one

Dashlane - ok
Dashlane + LastPass - not ok
LastPass - ok
LastPass + SilkTide - not ok
SilkTide - ok
SilkTide + Dashlane not ok...

The QA team have SilkTide and Dashlane but don't use LastPass, with them disabled all ok.

Different members of the client team have LastPass, a few had Silktide and other plugins

For Jeavon, it was a plugin called 'Slides Timer', when he disabled this, all was ok...

When using Umbraco 13, with these same plugins in place all ok,

but if it is 'this'.... and do see the video:

superquick.mp4

...then not sure what the policy would be, having observed the backoffice now with the extensions turned off, it does seem something is preventing TipTap from 'staying loaded', - it feels like it's initialising TipTap from scratch each time.. but without the extensions it works normally... I mean all the extensions 'manipulate' the dom to check accessibility or suggest passwords...

Also understand if we now close this issue and never mention it again :-P

[leekelleher]

Hi @marcemarc, would you be able to check something for me (please)? When opening the block modal (that has the Tiptap RTE), could you monitor the devtool's Network tab and check the Protocol column? (It wasn't enabled in my browser; I had to right-click on the headers to enable it). A little how-to if needed: https://stackoverflow.com/a/54164719/12787

I'm particularly interested if your server (Cloud site) is HTTP/1.1 or HTTP/2 (h2). Thanks! 🙏

[marcemarc]

@leekelleher I'm getting h3's ?

if that helps!

[leekelleher]

Thanks Marc. Okay, that should be better/faster. 🚀

I was looking into how the document/element-type compositions are loaded, and they are all pieced together on the client-side, each composition is a separate request. My thinking was if this was HTTP1, then that'd cause a major bottleneck, but HTTP3 should be much less of a problem (of course, less requests is always better).

I'm unsure where we are at with the repository "stores" concept, as in to keep a local cache of document/element-types. I'll chat with the team about it, see where we're at with it.