Below par performance and CDN

I believe you are correct that we are the only plugin that does not store images in the Media Library. As I understand it (I may be wrong) NGG actually predates the Media Library.

Unfortunately at the moment we do not have any kind of CDN support, but I have seen third party caching plugins that work by using output buffering to catch any images being served to browsers, upload them to a CDN, and then replace the content before sending it to the browser. This can make the initial page load pretty painful but afterwards it will result in NGG images being served by a CDN. I cannot say when it will be ready but CDN support is something we are working on.

Could you share a demo page of your site? I would be curious to see if I can diagnose a cause to your scrolling issues.

Hi Benjamin,

Thank you for your answer.

In the mean time imagely support has answered as well and confirmed the lack of CDN support. Some googling from my end found CDN requests for NGG from at least a year ago and some more diving into the reasons why found this thread https://github.com/wp-media/wp-rocket/issues/2353 (some images from the ngg galleries are served from the CDN, the ones, I assume, that are not served in Json blocks). All in all this is not very hopeful for expecting CDN support anytime soon.

You are free to examine how I use NGG (contact me privately please – here or [email protected]), however in the mean time I have been splitting up my galleries in smaller ones to get some performance. Sizes are now around 50 images, around 100 images and one bigger with around 200 images. This action was taken when the (what I suspect) ngg cache was re-created (I got some ok-performance after about 3h(!)).

Currently I feel a bit reluctant to clear the ngg cache for fear of having down-time again, but if it can help improve ngg we can talk about this.

Best,
Bob

Please keep us updated on this issue. As a brand new NGG pro user I just expected that my CDN would work. This is concerning and a basic need required for sites hosting multimedia.

Currently I feel a bit reluctant to clear the ngg cache for fear of having down-time again, but if it can help improve ngg we can talk about this.

I’ve thought about this some more, I should add: NextGEN’s image cache is just the “dynamic” images — say if you override the default thumbnail size for a Basic Thumbnail display then we create a second set of thumbnail images and store them in the cache.

NextGEN Pro’s Tile, Masonry, and Mosaic displays however don’t use the ‘full’ sized image and generate specially sized versions in order for those images to fit into their display and to conserve some bandwidth. If the generated / resized file does not exist the browser is given a special URL to the image (it starts with /nextgen-image/) that triggers the server to do the resize and serve the results to the browser. This can make the first time loading one of those displays pretty slow.

The feature to wipe NextGEN’s image cache is partially for people to reclaim disk space if necessary and partially because of a handful of bugs through NextGEN’s history; for most people it actually shouldn’t be used unless necessary. I’ve made a note to add a warning / confirmation to the “Clear image cache” button, that’s definitely on us for not having done so before and not explaining what it does before launching.

If you’re having to break up a single large gallery into multiple galleries.. this isn’t the friendliest answer but you could upload / create your large gallery and insert it into a private page and preview it — once the server has had the time to generate all of the new resized versions it will then have static copies that are much faster to serve and the page can be made public.

I hope that helps a little!

Hi Benjamin,

Thank you for the explanation and the info that clearing the cache is generally not really necessary. The solution you describe is not a really unexpected way to work, many “thumbers” approach it like this.

Is there a difference (after clearing the cache as I unnecessarily did previously) in adding a ngg gallery to a private page and viewing it to populate the cache vs simply viewing it on the published page?

I’m only using WordPress for 2, close to 3, years now and there is a lot to learn still on the innerworkings and details. My previous site was completely made by me, including simple cms etc. In time this became too time consuming to maintain, I needed more focus on the content. That’s why I moved to WordPress and the use of pre-made plugins.

For my own site I had a continues scrolling grid gallery (no masonry or mosaic) of close to 500 images. I used fresco, phpThumb and my own php code to render the gallery page. This page was lightning fast from the very start (read: no thumbs created yet) and there was no noticeable delay also no CDN. Obviously this was completely custom made, no overhead as you have in generic plugin as ngg. When I look at other picture heavy social-sites, for instance DeviantArt (too pick one), my galleries there are as I prefer them, continues scrolling and now around 400 images and no delay or stutter or noticeable loading at all. When I take this and then see the performance of ngg… downtime of my server regenerating thumbs, stutter in the continues scroll and very noticeable loading and delays. Is this just my experience? Is my configuration off? Are there preferred settings for larger galleries (I have been experimenting)? Etc.

@markyodo I’m hoping for an implementation soon as well!

Best,
Bob

Is there a difference (after clearing the cache as I unnecessarily did previously) in adding a ngg gallery to a private page and viewing it to populate the cache vs simply viewing it on the published page?

There is no difference, I just suggest using a private page so that your users don’t experience the extra loading time while the images generate.

I’ve added on my todo list to add an option to control whether the original or resized version of images are used in those display types. It was originally written that way in an attempt to find a good compromise on performance for most of our users, but it obviously isn’t best for everybody.