Gallery loading time optimization

Firstly, thank you so very much for this great plugin, it’s awesome! I started building a galllery of old guitars based on Tainacan (http://bohemianguitarvault.com/museum) integrated as a block into the page, but the loading times are pretty long and seemingly increasing as I keep adding more items. Could you please send me some tips for optimizing it – anything that I can do to make it load faster? Thank you so much in advance!

+1 from me. (Following this post)
Maybe even some settings that could work with popular caching plugins (wp faster cache, wp rocket etc ??)

Hi @Farrold!

We’re glad that you are enjoying the plugin! Your repository is shaping up really nice, I enjoy all the customization work that you’ve been doing. Also, don’t forget to let us know when you consider it finished so we can add it to our use case list.

But let’s focus on the performance. There are numerous pain points that we’ve been tackling over the years to improve it, but of course lots of work can still be done. The problem is that many areas can be covered, I can give you some hints of things that we’ve been working on and maybe some suggestions for you to try:

What is heavy for the database
Complex queries are responsible for increasing the loading time from a database perspective. One thing that has large impact is calculating facets (the numbers that you see alongside the filter options that indicate how many item have that value before applying a filter). I assume that you have taken a look at our Optimization page:

(Sorry for most of it being in Portuguese, we still need to improve this. You can try with the help of Google Translator or DeepL)

One of the things that we mention there is disabling those facets, which can be done via a PHP constant set in the wp-config.php file:

define('TAINACAN_FACETS_DISABLE_COUNT_ITEMS', true);

Just to make sure, have you tried this? Because:

  1. If you have, then there is one error in our plugin, as we should not make new requests for the facets endpoint every time a filter is applied (and I can see from the Network inspector that this is happening).
  2. If you have not set it, then there is some error in your installation (we need to investigate further), because I can also see from the inspector that the total_items value is returning null and that would be the reason why your filters are not displaying the facets alongside the checkbox values.

Requests for large amount of items
I’m assuming that is not your case, because your item’s list has very few items, but in case you have things private and I’m only seeing a few public ones… Large amount of items with large amount of metadata can increase loading time. This knocks into some limitations that are tied to the structure of WordPress post types database, from which we are build on. But in general, if your server is well configured and has good capacity, this should start hitting when we hit the mark of 5.000 items. If that is your case, then I should strongly advise you to try using the ElasticPress plugin, which we do have an integration with built-in. It enhances speed with an ElasticSearch extra database for indexes.

Having large amount of collections it’s also something that can be painful, but I guess that is now your case.

Amount of XHR requests being loaded
The items list is a big javascript component that builds all of its elements from a series of XHR requests to our JSON API. Tie this to a lot of image requests and your browser may not like the long sequence of concurrent requests, even blocking some to wait for others to finish. We’ve been working hard to reduce this amount of requests. In fact, recently @dshshproject complained about it and I found a couple of unnecessary duplicate requests, which shall be fixed in the next point release. We also have an open issue which we shall look into the next months, to try to combine this requests into once.

Amount of JS and CSS assets being made
We have done substantial work last year to make sure that only necessary code is loaded in each part of the Tainacan environment, specially in the public side of pages. One thing that I’m looking for to do is to find a way to only load necessary code for the currently enabled view modes (if you only use Masony, you should not have logic for the table view mode loaded). This is something in my to-do list.

One thing that I can suggest for your website in this field is to disable unused plugins. I see that you have the Extra View Modes enabled but does not seems to be using any of them, so it only becames extra CSS and JS that your browser has to deal in the page load.

Image optimization
We also try to load only the necessary size for image components. If you have resources to use an optimized image hosting service like the ones AWS have, we happen to know some use cases that were able to use them with Tainacan seamless, using only traditional WordPress plugins. All of our images are hosted inside the WordPress structure, so limitations to one apply to the other and these plugins can offer optimized hosting for images.

This may be a place to mention that caching plugins should integrate automatically as well, but I have not made any technical investigation on how this go, so if you have any suggestions @Alkis, we would love to hear :slight_smile:

I big pain point that I can see that you might have is the image gallery in the Item Single page. That component requires all images to be loaded in full resolution and I am aware that we could find methods to load them better… still need time to give a try for them.

Server side work
That said there are numerous things from a server perspective that we cannot be aware that you might have access depending on your hosting provider. I’m talking memory increase, PHP constants tweaks for timeouts, etc… It really has a big impact the kind of server that you have access to.

Block & theme settings
I see that are using Blocksy and they are known for having a well optimized theme, with some good care for performance. Our integration with them takes advantage of this, but one thing that maybe could be better for your case is to use the default items list (http://bohemianguitarvault.com/guitars), instead of this one you created in this page (http://bohemianguitarvault.com/museum/) using the Faceted Search block. That’s because the Faceted Search block is a sort of solution for themes that do not have their own integration with Tainacan. When using it, you have more components to be loaded due to it’s customizable block nature, things that are handled a bit faster in the integration page. In any case, I suppose you did for having a greater control of layout… in that case, I can provide you with some CSS code snippets to achieve similar results. But anyways, its a smaller issue compared to all other things that we mentioned.


This is as much as I can think of by know. If you can provide us with more specifics, maybe we have more insights. I hope some of it helps or at least give you an idea of what we’ve been working on.

Let us know what you think! :tainacan:

1 curtida

Using the webp image format can help.
Wordpress supports the format since version 5.8. and the files are much smaller than the jpg.

10x small

Musikwinkel-parlor-guitar-pre-war-1-of-8.jpg 492 KB

Musikwinkel-parlor-guitar-pre-war-1-of-8.webp 56,0 KB

Good point @sergio.sakakibara! I’m doing some tests in my collection with them and the results are impressive.

The only negative aspect is that for users new to educational work the file format is still little known,
is being gradually incorporated into programs, Windows only supports version 10 and above.

@mateus.m.luna Thank you very much for all the extensive information - I actually did disable the facets in the wp-config file. I would love to use the direct interface in place of the block integration, if you could send me the CSS snippets to make it blend better with the rest of the page, I would be most grateful.

That’s awesome! Thank you too, I will use the .webp format from now on.

I was able to solve this, should be ready for next release. This will be great because some view modes like Map depend on other libraries that can increase the size of the final bundle. My recommendation is that for now on, only enable view modes that you are certain that you will use :wink:

Couldn’t work on this today, but I’ll see If I can give you something before the weekend. Have you played around with the Blocksy options? Customizer -> <Your Collection> Items list

Thank you again, I tried adjusting the Blocksy settings and I am getting close, but it seems that performance-wise, the difference between the direct interface and the block solution is negligible in my case. Are there any particular minimum server specs / parameters that I should look for / adjust in the administration if possible, in order to improve the performance a bit further?

There might be some minimum server specs:

But it is hard for us to give this as it depends on so many factors that are related to your repository… And as we mentioned before, there may be pain points in different areas (first load, content load, items request, filters request, image load…)

For now, you can try out our development version where I implemented the dynamic loading of view modes. If you only have the necessary ones enabled in the Collection/Block settings, it should help a bit with the page first-load:

Remember, when installing new versions of the plugin like this it is always good to give a full page refresh (CTRL+SHIFT+R) to get rid of cache from previous versions.

This should only affect the javascript load time. About the API requests, I just noticed that you have a considerable amount of filters enabled. One thing that you could try is to set some of them (the ones that you consider to be less relevant) to “Begin with filter collapsed”. This option avoids the request to the facet values until a user goes there and expands the filter on purpose.