Problem/Motivation

In #2780789: Disable render_cache for paragraphs? we have disable render cache for Paragraphs entities but this can be reenable when if nothing changed in a Paragraph entity, skip saving.
Once this works, a render cache would make sense again as the host entity builds much faster.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#4 paragraphs-2790071-4.patch972 bytestim@lammar.be

Comments

yongt9412 created an issue. See original summary.

miro_dietiker’s picture

Priority: Normal » Minor

For now still low prio.

We need to check performance for huge documents though.

andyrigby’s picture

I wanted to raise an issue we found with the render cache and node preview in case this issue is actioned and render caching is re-enabled.

In version 8.x-1.0 the render cache is enabled. If you edit a paragraph and click "Preview" the new data is not shown. Instead, the old data is shown.

Steps to reproduce:

* Ensure caches enabled, drush cr
* View a node /node/564
* Edit the same node /node/564
* Amend some content in a wysiwyg field
* Click preview

Expected: preview shows the changed field

Actual: preview does not show changed field, instead it shows cached content from the initial render of /node/564

Applying the patch in https://www.drupal.org/node/2780789 (disable render caching) resolves this issue.

I've not dug any deeper into the issue to get to the root cause, but let me know if any more info is required.

tim@lammar.be’s picture

StatusFileSize
new972 bytes

We needed this back active:
usecase:
We have pages with paragraphs that reference views or other entities.
Because there is no separate render cache for paragraphs, there in only one render cache record for the node view. This get's all cachetags from all the paragraphs in it, causing all paragraphs to be re-rendered if one gets invalidated, even though the other paragraphs did not need change.

berdir’s picture

You can also put this in an alter hook instead of a patch. I get the use case, we often do similar stuff, but writing the caches is also overhead and duplicates things even more, your views list is then cached in the view, in the paragraph, in the node, in dynamic page cache and in the page cache, often with many diffferent variations. The others are already there, this is just one more.

Another problem is that paragraph theming might depend on the order, so you might do some alternating classes or logic depending on previous/next paragraphs, that would break if some are render cache hits.

For that use case, it might be more benificial to invert it and make the embedded view use a lazy builder, 11.3 provides a number of improvements for that, such as bulk loading of all placeholdered elements as well as forcing things to not be processed with bigpipe, to avoid layout shifts for this.

Are you using block_field or something else. Again, challenge could be context, but there could be an option in the block_field renderer to use a lazy builder for this.