30+ page stories causes image/template browsing feature to use 4X client memory

[brianpetro]

To reproduce, in a story with 30+ pages,

1. Hard refresh.
2. Scroll through the images or templates section.
3. Observe substantially increased memory usage when compared to a new/blank story.

Note: the difference in memory usage between the blank story and the 30+ page story is less than 2X.

These features work well when the story is short. But then stop working, or crash the client's computer, when the story is long.

What might be causing this?

Thanks

[swissspidy]

Thanks for raising this!

We're painfully aware of the performance shortcomings in the editor, especially in those two areas.

That's why we're overhauling the templates section in the next release to replace the dynamic previews with simple static images (see #9289). Especially when scrolling through the templates list the experience will be much smoother.

Besides that, we're actively working on addressing memory and performance issues throughout the editor, from the canvas to the media library.

We'll take a look at this specific scenario that you're mentioning to identify possible causes for this.

cc @choumx @miina - let's discuss this further to get to the bottom of this.

[brianpetro]

Thanks for the always-speedy response @swissspidy!

[dreamofabear]

Thanks for the report, Brian!

Scroll through the images or templates section.

Can you clarify which sections?

Does "images" mean the "WordPress media" tab on the left-side in the editor? Or the second "Third-party media" tab?

Does "templates" mean the templates on the dashboard or the "Page templates" tab in the editor?

[brianpetro]

@choumx yeah, of course, I was referring to both the "Third-party media" and the "Page templates" tabs in the editor.

Thanks!

[brianpetro]

Similarly, "rearranging pages in Grid view" may be added to the list.

[swissspidy]

Ah yes, that's a good point. I think our reordering components (in grid view and the carousel) as well as the Moveable integration in the library are really not performant

[miina]

I think our reordering components (in grid view and the carousel) as well as the Moveable integration in the library are really not performant

Moveable should in theory make a difference in the library only for the element that's being hovered on since it's only displayed for a hovered/active element. Or do you mean the dragging itself is not performant?

Rendering a page seems to be quite slow itself, especially if it has many elements (there's a discovery issue for it as well #8255). When loading a story, these processes also start, this happening at the same time with 30+ pages can probably slow down everything quite a bit:

• Rendering all the page previews in the carousel with all the elements
• Generating an image for each page for the thumbnails
• In media library, calculating the average color for the media elements (as noted by Pascal in #9550)

[swissspidy]

Moveable should in theory make a difference in the library only for the element that's being hovered on since it's only displayed for a hovered/active element. Or do you mean the dragging itself is not performant?

Check the React dev tools and toggle the "Highlight updates when components render." checkbox. You'll see that all media items (specifically, LibraryMoveable) re-render when doing anything on the canvas / in the editor.

Rendering all the page previews in the carousel with all the elements

We display colored "skeletons" though, right? And then switch to the images once generated. Using requestIdleCallback

Generating an image for each page for the thumbnails

Related: could we perhaps store these images with the story JSON blob so when you open an existing story we can display these existing images?

---

Still, none of these issues seem to explain why memory increases that much, especially when simply browsing

[miina]

Check the React dev tools and toggle the "Highlight updates when components render." checkbox. You'll see that all media items (specifically, LibraryMoveable) re-render when doing anything on the canvas / in the editor.

Hm, okay. Looks like the InnerElement is re-rendering all the time when doing anything (even when removing the LibraryMoveable), e.g. while dragging an element. I'll create a separate issue to investigate this specifically.

We display colored "skeletons" though, right? And then switch to the images once generated. Using requestIdleCallback

Yep, we first display skeletons, then display the thumbnails as small pages and then generate the images from those (since the page has to be displayed first for being able to generate an image)

Related: could we perhaps store these images with the story JSON blob so when you open an existing story we can display these existing images?

Could be an option, wondering how large it could make the JSON blob.

Still, none of these issues seem to explain why memory increases that much, especially when simply browsing

Were you able to reproduce this as well?

[brianpetro]

I opened up the same story again today and observed:

1. Grid-view, and possibly some other features, trigger using upwards of 8GB of memory soon after opening the editor.
2. If the browser doesn't crash, then the memory use stabilizes around 1GB.
3. The left-side tabs don't seem to trigger any issues at the "stable" phase reached in 2.
4. Opening grid-view for a second time triggers a memory increase somewhere north of 8GB (crashed every time).
5. Closing grid-view does not halt the memory increase which takes about 30sec to reach its maximum.

[swissspidy]

Woah 8GB?! That definitely does not sound right.

On which OS and browser was that?

[brianpetro]

Windows, Chrome Version 95.0.4638.54 (Official Build) (64-bit)

[brianpetro]

In case it helps, the story has 35 text-only pages that were created using a wide variety of the included page templates.

To clarify, "text-only" means that the "show images" option was toggled off when importing the page template. And only the text has been added or changed. No additional media has been added.

[miina]

Based on some discussion related to the image generation for the thumbnails: Looks like every time the grid view is opened, image generation starts for each page displayed in the grid view. This starts all over again every time when opening the modal, making the image generation logic useless (and harmful) for the grid view, since these images are not stored outside of the component and are removed every time the grid view is closed.

That's a likely culprit here with the grid view issues.

@barklund Since you'll be looking into this related to the page carousel work in #9641, I'll assign this issue to you for now -- if it comes out that this does not fix the issue, let me know and we'll continue investigating separately.

[csossi]

Verified in QA

[miina]

@brianpetro A new version (1.15) of the plugin was released with a potential fix for the issue. Could you update the plugin and try with the new version to see if the memory issue is still happening for you? Thanks!

[brianpetro]

@miina Using the same story & environment that was used earlier:

Memory peaks at ~5GB in about ~2min before it settles around ~1GB. And then the features work as expected. This seems to happen once per page load.

These tested features were unusable prior to the settling point:

• Page templates tab: scrolling doesn't work.
• Grid view: drag-and-drop does not work.

At a quick glance, I'd say things are looking good. We should be able to increase the ~20-page per story limit we had in place because of this issue. I'll have to gather further feedback from our writer after her next assignment and report back.

Thanks for the update 😊

[swissspidy]

Page templates tab: scrolling doesn't work.

Is this for the default page templates or the saved ones?

[brianpetro]

Is this for the default page templates or the saved ones?

The default ones.

[miina]

Hm, okay. Great that things have improved but looks like this will need some additional investigation.

Could be that the carousel thumbnails generation adds quite a bit to the initial memory peak then, and could be avoided if we'd store the thumbnails instead of re-generating at every load, as discussed in #9749.

[BrittanyIRL]

@miina mind if pea pod takes a stab at further improvements here? we've got some room this month and i was hoping we could work on performance.

[miina]

@BrittanyIRL Generally sure -- the only part that we already partially started looking into, is the general thumbnails generation logic for the page carousel which is likely a part of the issue (cc @barklund). There might be more areas to improve so feel free to look into everything other than this.

[BrittanyIRL]

will def keep dialog open on anything we find. thanks!

[brianpetro]

I'll have to gather further feedback from our writer after her next assignment and report back.

To quick follow up on that, she said that their was no improvement at all.

Furthermore, I combined two of these partial stories, bringing the total pages to ~50. But then, any subsequent attempt to load that story crashes the browser(memory limit).

And possibly related, that ~50 page story that crashes in the editor, it also fails completely, as in just white pages with a single non-wrapping line of text, when opened in preview mode.

[swissspidy]

Is this one still an issue?