It's worth noting that Juicebox galleries depend on two requests that must go through the Drupal menu system, one to construct and deliver the page that contains the actual embedded gallery, and another to construct and deliver the "config" XML that describes the gallery. This means Drupal must be bootstrapped twice each time a gallery is displayed, and furthermore, each time this happens some processes are repeated (the process of building the entity or view that's being displayed, etc.). This all leads to a bit of redundancy that could potentially be avoided by caching rendered data across multiple page requests. The specifics of all this get a bit tricky and the consequence of not doing this caching is pretty negligible for most cases, so this has not been a priority for the first version of this module.

No matter what I figure it's worth mentioning. I may also want to add some notes to the readme about it.

When core page caching is on, both the main gallery page and its config XML data will be cached by Drupal, so any caching this module could do itself would not offer any advantage in this case. I suppose this fact alone makes all this a fairly negligible concern for now.


rjacobs’s picture

Title:Allow custom classes to be added to Juicebox parent div» Notes on performance when core page caching is disabled.

Fix title.

rjacobs’s picture

Component:Code» Documentation

For now I think it's just a matter of getting this documented as I don't think there are any "issues" here. I don't think performance will be an issue for most use cases.

rjacobs’s picture

Status:Active» Closed (won't fix)

I just updated the project page and the readme to reference these notes. The relevant commit is:

If anyone sees this as a real performance concern please re-open and we can look into building some custom caching options into this module itself.

rjacobs’s picture

Issue summary:View changes

Needed to re-purpose this (repeated) issue for another topic.