I’m building a museum collection site (WordPress + Tainacan 1.3.0, tested also on 1.1.0) on a local development environment. Currently I have only ~20 items in one collection, with plans to grow to around 3000 items in another.
When viewing the collection in Masonry view mode (via the Faceted Search block), the page takes 4-5 seconds to load and render just 12-24 items. Using Firefox’s Profiler, I found that the bottleneck is a canvas-based function (CanvasRenderingContext2D.putImageData) inside tainacan/assets/js/988...js, which I believe is the BlurHash placeholder effect generating a blurred preview for each thumbnail.
Switching to Table view mode, the same items load in under 1 second — no canvas/BlurHash processing involved.
My questions:
Is there a way to disable the BlurHash effect specifically (via settings or a filter/hook), while keeping Masonry’s visual layout?
Is this expected to scale linearly (or worse) with the number of items shown per page? With 3000 items in a collection (even paginated to, say, 24-48 per page), will this become unusable?
Are there recommended view modes for very large collections (thousands of items) that keep a “gallery/grid” visual style without this performance cost?
Thanks in advance — happy to share screenshots/profiler data if useful
To be honest Blurshash shouldn’t add that delay… it does have an impact of 0.5s which is the animation duration for transitioning from its version of the content to the loaded one, but never something like 4s.
I’ll see if I can investigate possible causes (like a bad generated hash string) for this behavior. Could you share with us a link so we can take a look at your case?
Answering to your questions:
There isn’t as of today, but I think it is a valid request, will open an issue so we can take a look at it in the future;
Since the blurshash script happens when the view is being mounted it should only be affected by the number of items being loaded at the moment (3000 items at once would be an issue for backend, which is why we need to paginate things). But again the delay that you are experiencing it is not our normal use case.
There is a list of things that make an items list heavy, I would rank them, more or less in this order:
Facets (the amount of filters that load their possible values for the current pages), such as checkboxes, are the worse. They can be overcome by using other filters or changing their appearance to collapse/hidden.
Amount of metadata enabled for display. View modes like Masonry or Mosaic only load basic core metadata such as title and image, thus are quicker than Table, Records or List, which can increase their loading time depending of how many extra metadata are you loading with them
Amount of items, which is always the reason to increase the other variables. We set the default max 96 items per page because we believe it is the reasonable for basic shared host experience. Loading more than that in a single request is rarely acceptable considering the way things are stored in a traditional WordPress Database, no matter the view mode. Still, if you paginate, you can have a total of 5.000, even 10.000 with acceptable output. If your collection ever increases to values greater than 20.000 it will also be a moment to start investigating things like Elastic Search Integration with Elastic Press.
Finally image size obviously matters, but each view mode tries to render a cropped version available in the WordPress file system that is closer to its needs. Masonry and Mosaic render tainacan-large-full, because their layout may need that much pixels depending on how their rows and columns were lined up. Table loads the smaller tainacan-small and Records the medium-term tainacan-medium-full.
I’ll see if I can find any reason for the blurhash guess. Meanwhile if you are eager to solver this, you can build your own View Mode using the criteria that best fits you:
Thank you for the quick reply, and for confirming the ~0.5s figure — that helps narrow things down.
Unfortunately I can’t share a live link right now, as the site is still in local development (LocalWP), not yet on public hosting.
I also found a very similar topic from last year (“Collection items in a Masonry view mode are loading very slow”, Daniel_G, Sep 2025) where the loading was traced to REST API response times and database clutter. In our case it seemed different — using Firefox’s built-in Profiler, the bottleneck was clearly inside a canvas rendering function, consistently reproduced across two separate site backups and after updating Tainacan from 1.1.0 to 1.3.0.
As a workaround, we switched from Masonry to the Books view mode (from Tainacan Extra View Modes), and after some custom CSS adjustments (transparent background, fixed thumbnail size, responsive grid), the same collection now loads in about 2 seconds total, with no canvas-related slowdown. So we’ve resolved our specific issue, and it seems to be something particular to Masonry/Mosaic’s BlurHash rendering path rather than Tainacan in general.
Thank you again for the help — wanted to close the loop here in case it’s useful for others hitting the same thing.
I haven’t tested it on a mobile device yet since the site is still under development on my local computer. However, I did test it in Google Chrome, Firefox, and Opera, and experienced delays across all of them. We tried several different ways to speed up the loading time, but nothing worked. This lag happened with only 40 items, and my actual collection catalog will have much more than that. Because of this, I switched from Masonry to the Books view mode.
@Canada_Gadget once you have a link for us to test please share it, it will help investigate the issue because I could not reproduce on my side. Do you see any browser console error during the blurhash loading?
While investigating the Blurhash component I did found an improvement that could be done… I’m not 100% sure if it will solve your experience completely but I’ve seen some improvement for me. Could you please give it a try with this on-development version?
Since this is a new build with the same version (1.3.0) you’ll have to make sure your browser and server-side cache are clean. Don’t forget to reload your items list page with CTRL+SHIFT+R after uploaading and activating the new version.
Let me know if it has some improvement. If not I am already on the ways to implement a kill-switch that will be able to disable Blurhash for all view modes if the user wants.
Awesome, thanks for the update! We’ve already set up the booking view and are moving ahead. I’ll make sure to hard-refresh the cache to test this 1.3.0 build. I’ll also check it against the old backup as soon as I have some time. Appreciate the help
Great, please let us know. Despite working, getting rid of the books wouldn’t be bad. After all is one less plugin to have. Core view modes also have a logic for enqueuing their css only when needed, while the ones from the plugin are not that smart.
Thanks a lot! I installed and tested the dev version you provided. Now everything loads quickly and works great, though there’s still a slight blur visible before the images fully appear. The Books view mode shows the images instantly, so it’s a touch faster. But overall, both options are now working well. Thank you!
Great to hear that. Thank you for bringing this detailed issue analysis, it made us discover a bug that we weren’t aware. I’ve even made other small tweaks that shall make ir quicker when officially released in version 1.4.0. Will post further updates when it is ready.