Optimizations for re-rendering

[enkelmedia]

Which Umbraco.Community.BlockPreview version are you using?

4.0.3

Which Umbraco version are you using? For example: 10.4.0 - don't just write v10

16.2.0

Bug summary

I've noticed that, e.g., during a drag operation, there will be a re-rendering from the server even if the content did not change. This re-rendering has a timeout of 500ms, which is kind of noticeable.

Steps to reproduce

Drag and drop blocks that are rendered on the server

Expected result / actual result

I would be interested in helping explore options here and maybe contributing a PR around this, but I was hoping for some context to avoid regressions.

Is there a special reason as to why the timeout is 500ms in the update method of the block-grid-preview.custom-view.element.ts?

BlockPreview/src/Umbraco.Community.BlockPreview.UI/src/blockEditor/block-grid-preview.custom-view.element.ts

Line 113 in 03eeb03

}, 500);

I have not looked into the exact details, but in an ideal world, we would avoid having to re-render a block if nothing has changed. Is this something that has been considered and rejected, or do you think it would be worth exploring? I would be happy to if this is interesting on your end.

#h5yr!

[rickbutterfield]

Hey @enkelmedia! I'm very happy to discuss this and change the functionality if we can stop the re-render and extra API call that's made every time a block is moved.

I can't 100% remember why the 500ms timeout was needed, but from my understanding of the Lit rendering lifecycle there should be a way we could hook into either the shouldUpdate or willUpdate... I have been having a play around tonight but not managed to get anything that works well!

[rickbutterfield]

I've opened a PR with my first pass at a fix for this

[enkelmedia]

Hi!

Sorry for the delay! A lot of work this week! Nice that you looked into this! I'll try to find some time asap to give the PR branch a spin.

[rickbutterfield]

I've been looking into it a little more and I think this may be an issue that is caused by the CMS and not BlockPreview. From what I can tell, when items are sorted (in any sorter powered by UmbSorterController) they are destroyed in the DOM and then recreated.

I've pulled this branch up to date with v4/dev and added some logging around connection/disconnection and this happens when a block is moved:

I may need to have a look into core and see what can be done to stop this from happening.

[enkelmedia]

@rickbutterfield Yeeh, I think you're right about the fact that there is really no way to avoid the re-creation of the component it self.

But, I think that the re-rendering it self should be very fast - the "problem" is the re-fetching of the HTML-content for the block. I'm not sure exactly how to get around that but maybe if there was a context that caches the rendered HTML. So that if the component is re-rendered the HTML content is already there (no need to fetch + render on the server).

Maybe we could store some kind of "hash" of the block model and compare the "current model" against the hash before re-fetching from the server - if nothing changed - use the cached version - otherwise fetch from the server?

[rickbutterfield]

I have opened a PR in the CMS that may go some way to resolving the performance issues

umbraco/Umbraco-CMS#21186

[rickbutterfield]

My changes in the above PR have been worked on more and merged in now, so running a nightly build of 17.3 gives much better performance!

Recording.2026-03-10.081136.mp4

[enkelmedia]

@rickbutterfield This looks awesome!

[rickbutterfield]

Hey @enkelmedia! A lot of the performance issues have now been resolved in the CMS, and I've pushed some additional changes to 5.4.0-rc to stop the 500ms timeout and handle moving/resizing blocks better. Give it a try and see what you think!

[enkelmedia]

@rickbutterfield! Sorry for taking so long to get back! Just tried 5.4.0-rc on Umbraco 17.3.4 and it seems to work very smoothly!