Gutenboarding: dynamic previews performance boost

[simison]

How could performance be improved for dynamic previews?

• Any open core issues?
• Any clear bottlenecks?
• Loading smaller images in the previews?

[Addison-Stavlo]

How could performance be improved for dynamic previews?

I am not quite sure, it would be good to put a few more heads together on this.

Currently, an instance of the BlockPreview component will load its own BlockEditorProvider and any corresponding registry providers and assets that may go along with that. This may be a limiting factor for performance while running multiple previews?

Loading smaller images in the previews?

Currently, the BlockPreview renders the site at a desired width which is then transformed in scale to fit a small preview window. So our preview that is 400px wide, is first calculated at 960 or 1280px (or whatever we want to define the preview viewport width as), and then scaled down to 400px to fit the preview window.

To load a 'small' image designed for a 400px wide preview would first require that small image to be loaded into the full-width 1280px (or whatever it may be) size before the scale-down happens. Smaller images would likely render an improper size compared to the rest of the preview and we would probably have to customize the blocks themselves to fix this.

[simison]

Related WordPress/gutenberg#19082

[Addison-Stavlo]

Related WordPress/gutenberg#19082

I am not sure I follow the relation there?

[simison]

Just had a cursory look, might not actually be related 😅

[obenland]

On WordPress.com we're using previews in a selector for page templates and found that they can cause extremely long load times when you have multiple previews load at the same time.

We traced it back to state setting but so far have not been able to come up with a fix.