Active
Project:
Paragraphs
Version:
8.x-1.x-dev
Component:
Code
Priority:
Minor
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 Aug 2016 at 14:23 UTC
Updated:
16 Apr 2026 at 11:19 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
miro_dietikerFor now still low prio.
We need to check performance for huge documents though.
Comment #3
andyrigby commentedI 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.
Comment #4
tim@lammar.be commentedWe 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.
Comment #5
berdirYou 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.