Image performance questions/requests. Cache, pre-rendering, progressive

Features
1

As we’re getting closer to launch we’re focusing more and more on frontend performance. I’ve got three questions related to image cache.

  1. Each time we’re building the app it seems the docker load clears the work directory (where I believe the built image variants are stored). How can we keep this untouched between deploys? We are running in the Enonic cloud using docker images.

  2. Is there any way we can intercept uploading of images using ImageSelector? I’d like to set max dimensions and file size on the originals on the way in. I’ve done this on previous CMS’es with great success. It allows users and web editors to throw anything at the system, and successive variant rendering will be much faster and less cpu/mem intensive.

  3. Progressive jpegs. Could you please consider an option of creating progressive jpegs when using the otherwise quite powerful imageUrl scaling?

2 Likes
2

Three topics in one…

  1. can be solved through configuration, we are already doing this somewhere else by storing the work directory as data - @esu knows how.

  2. Technically you could through contentProcessors, but at the moment it would require building a new XP distro we haven’t documented or made them pluggable yet. Also for this specific purpose maybe it should be intercepted even earlier in the initial phase of createMedia()?

  3. I guess that should be possible.

We’ll look at #2 and #3 for our upcoming roadmap meeting!

1 Like
3

Thanks, Thomas, for the quick response as well as considering the feature requests in your roadmap. Looking forward to response from @esu about the image cache.

4

Hi.
You need to update storage/Dockerfile to define /enonic-xp/home/work as a volume like this:

VOLUME /enonic-xp/home/repo /enonic-xp/home/work

Note that this may wipe the storage container, so make a supportcase and we can do it and deployment together.

1 Like
5

We have added #2 and #3 to our backlog. No ETA yet.

2 Likes