# Masonry view mode extremely slow (BlurHash canvas) with only ~20 items

**URL:** <https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846>\
**Category:** Dúvidas\
**Created:** [Setembro 14, 2026, 11:14am UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846 "2026-09-14T11:14:47Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Canada\_Gadget](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/canada_gadget/32/3702_2.png) [@Canada\_Gadget](https://tainacan.discourse.group/u/Canada_Gadget)\
**Post date:** [Setembro 14, 2026, 11:14am UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/1 "2026-09-14T11:14:47Z")

</div>

Hi,

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:

1. Is there a way to disable the BlurHash effect specifically (via settings or a filter/hook), while keeping Masonry’s visual layout?
2. 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?
3. 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

---

<div class="post-metadata">

**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\
**Post date:** [Setembro 14, 2026, 2:14pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/2 "2026-09-14T14:14:52Z")

</div>

Hi @Canada_Gadget!

Welcome to our community!

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:

> [@Canada\_Gadget](#):
>
> 1. Is there a way to disable the BlurHash effect specifically (via settings or a filter/hook), while keeping Masonry’s visual layout?

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;

> [@Canada\_Gadget](#):
>
> 1. 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?

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.

> [@Canada\_Gadget](#):
>
> 1. Are there recommended view modes for very large collections (thousands of items) that keep a “gallery/grid” visual style without this performance cost?

There is a list of things that make an items list heavy, I would rank them, more or less in this order:

1. 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.
2. 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
3. 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.
4. 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:

> **[Tainacan Wiki](https://tainacan.github.io/tainacan-wiki/#/dev/extra-view-modes)**
>
> Home for Tainacan's Documentation

---

<div class="post-metadata">

**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\
**Post date:** [Setembro 14, 2026, 2:21pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/3 "2026-09-14T14:21:42Z")

</div>

Issue created:

> <https://github.com/tainacan/tainacan/issues/1161>
>
> \*\*Context and motivation\*\*
> 
> Despite being cool and smart, the Blurhash solution …for displaying a blurred version of the image before the actual image is loaded doesn't always fits. One may complain of the server-load that it causes for calculating the string and some users reported issues caused by the rendering script which as slowing down things:
> 
> https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/2
> 
> \*\*Ideal solution\*\*
> 
> I think we could offer a Constant, Filter or even an option to disable Blurhash. It will be a bit hard to replace every place where it is defined, so maybe see if there is a way to internally disable the component.
> 
> \*\*Alternative solutions\*\*
> 
> I know that the WordPress Performance team has explored some ways of loading a predominant color wrapper for non-loaded images. That might be in good shape for a total replace in the future, but we must be careful because even the classes added by Blurhash in their components might have been customized by exenders.

Let me know if you have a link available for some testing from our side!

---

<div class="post-metadata">

**Author:** ![Canada\_Gadget](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/canada_gadget/32/3702_2.png) [@Canada\_Gadget](https://tainacan.discourse.group/u/Canada_Gadget)\
**Post date:** [Setembro 14, 2026, 8:02pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/4 "2026-09-14T20:02:31Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tintin](https://avatars.discourse-cdn.com/v4/letter/t/ed655f/32.png) [@Tintin](https://tainacan.discourse.group/u/Tintin)\
**Post date:** [Setembro 15, 2026, 7:39am UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/5 "2026-09-15T07:39:40Z")

</div>

I have had similar performance challenges with masonry. I noticed that on mobile phones it was faster, so wondered if it was browser dependent.

@Canada_Gadget did you try on a mobile too and had the same delay?

---

<div class="post-metadata">

**Author:** ![Canada\_Gadget](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/canada_gadget/32/3702_2.png) [@Canada\_Gadget](https://tainacan.discourse.group/u/Canada_Gadget)\
**Post date:** [Setembro 15, 2026, 1:59pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/6 "2026-09-15T13:59:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\
**Post date:** [Setembro 15, 2026, 2:14pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/7 "2026-09-15T14:14:09Z")

</div>

@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?

---

<div class="post-metadata">

**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\
**Post date:** [Setembro 16, 2026, 8:47pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/8 "2026-09-16T20:47:09Z")

</div>

Hi @Canada_Gadget!

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?

> **[tainacan.zip](https://drive.google.com/file/d/1SNKSNR8gure6rm6zN2YUj0IuhTCC6y5w/view?usp=drive_link)**
>
> Google Drive file.

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.

---

<div class="post-metadata">

**Author:** ![Canada\_Gadget](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/canada_gadget/32/3702_2.png) [@Canada\_Gadget](https://tainacan.discourse.group/u/Canada_Gadget)\
**Post date:** [Setembro 16, 2026, 9:17pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/9 "2026-09-16T21:17:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\
**Post date:** [Setembro 17, 2026, 12:43pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/10 "2026-09-17T12:43:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Canada\_Gadget](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/canada_gadget/32/3702_2.png) [@Canada\_Gadget](https://tainacan.discourse.group/u/Canada_Gadget)\
**Post date:** [Setembro 18, 2026, 3:34am UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/11 "2026-09-18T03:34:26Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![mateus.m.luna](https://yyz2.discourse-cdn.com/free1/user_avatar/tainacan.discourse.group/mateus.m.luna/32/3_2.png) [@mateus.m.luna](https://tainacan.discourse.group/u/mateus.m.luna)\
**Post date:** [Setembro 18, 2026, 12:27pm UTC](https://tainacan.discourse.group/t/masonry-view-mode-extremely-slow-blurhash-canvas-with-only-20-items/2846/12 "2026-09-18T12:27:07Z")

</div>

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.
