Filter blocks: Performance issues

[dinhtungdu]

In this post, I’m documenting and discussing the current performance issues of filter blocks to ensure we’re fixing the right issues.

Content flashing

From the moment the page starts rendering to the point when the filter blocks finish rendering, filter blocks are flashed a few times. This makes the site feel laggy and janky.

Screen.Recording.2023-08-21.at.16.10.23.mov

Let’s analyze the flashing timeline of the Stock Filter block to identify the causes of the issue. In the following sections, I use the term ‘flashing’, not ‘rendering’, to indicate the state when a visual change occurs. The block is rendered multiple times between those visual states.

The first flashing

At this point, the react and block scripts are loaded, and the block finishes rendering and showing the loading state.

Before	After
<br><div data-block-name="woocommerce/stock-filter" data-heading="" data-lock="{&quot;remove&quot;:true}" class="wp-block-woocommerce-stock-filter is-loading"></div><br><br>	<br><div data-block-name="woocommerce/stock-filter" data-heading="" data-lock="{&quot;remove&quot;:true}" class="wp-block-woocommerce-stock-filter"><div class="wc-block-stock-filter style-list is-loading"><ul class="wc-block-checkbox-list wc-block-components-checkbox-list is-loading wc-block-stock-filter-list"><li style="width: 86%;"></li><li style="width: 40%;"></li><li style="width: 40%;"></li><li style="width: 85%;"></li><li style="width: 62%;"></li></ul></div><div class="wc-block-stock-filter__actions"></div></div><br><br>

The second flashing

Block content is replaced by <Suspense>  fallback component.

Before	After
<br><div data-block-name="woocommerce/stock-filter" data-heading="" data-lock="{&quot;remove&quot;:true}" class="wp-block-woocommerce-stock-filter"><div class="wc-block-stock-filter style-list is-loading"><ul class="wc-block-checkbox-list wc-block-components-checkbox-list is-loading wc-block-stock-filter-list"><li style="width: 86%;"></li><li style="width: 40%;"></li><li style="width: 40%;"></li><li style="width: 85%;"></li><li style="width: 62%;"></li></ul></div><div class="wc-block-stock-filter__actions"></div></div><br><br>	<br><div class="wc-block-placeholder"></div><br><br>

The third flashing

The block content replaces the fallback. We’re still in the loading state.

Before	After
<br><div class="wc-block-placeholder"></div><br><br>	<br><div data-block-name="woocommerce/stock-filter" data-heading="" data-lock="{&quot;remove&quot;:true}" class="wp-block-woocommerce-stock-filter"><div class="wc-block-stock-filter style-list is-loading"><ul class="wc-block-checkbox-list wc-block-components-checkbox-list is-loading wc-block-stock-filter-list"><li style="width: 86%;"></li><li style="width: 40%;"></li><li style="width: 40%;"></li><li style="width: 85%;"></li><li style="width: 62%;"></li></ul></div><div class="wc-block-stock-filter__actions"></div></div><br><br>

The fourth (the last) flashing

The loading state is replaced by the desired filter content. This is the point when the block finishes fetching collection data and building the options for display.

What should we do?

Ideally, the block content shouldn’t be flashing at all. We can do that if we server-side render the block (like what we do with the Mini Cart block), then render it client-side again when customers interact with it. But doing so means duplicating logic between PHP and JS, it’s not an issue with the Mini Cart due to the simplicity of the block markup, but filter blocks are way more complex than that. (I need your opinion on this, whether we should go with this direction or not).

If we want to keep rendering the block on the client side only, then we need to accept some trade-offs. Let’s examine those four flashings above further:

• Given that we’re rendering filter block on the front end, then we have to wait for React and blocks scripts to be loaded. The HTML content changes for the first flashing are inevitable. However, we can make the change not visually flashing by styling the two loading states (server and client side) the same way.
• The second and the third flashing can be avoided if we can prevent the <Suspense> from rendering the fallback.
• Finally, the block should behave like this visually:

1. After the page is loaded, the loading state should be showing up.
2. Once the collection data is fetched, the block should show the filter options.

It takes time for filter options to show up

The block only starts fetching the collection data only after it finishes rendering. On slow networks or hosting, the duration is more noticeable.

We can solve this issue by hydrating the collection data request, like Cart and Check block does with the cart data. The challenge here is to detect the filter blocks on the page to produce the right request to hydrate.

cc @roykho @sunyatasattva  What do you think? Is there anything I'm missing?

[roykho]

I wonder if the Interactivity API could help in this case woocommerce/woocommerce-blocks#10582

The challenge here is to detect the filter blocks on the page to produce the right request to hydrate.

Right, I've mentioned this also in my discussion topic https://github.com/woocommerce/woocommerce-blocks/discussions/10678

I guess some of the questions can be answered once we know how the filters are suppose to work in what context which is the discussion of the above linked discussion.

[dinhtungdu]

I wonder if the Interactivity API could help in this case woocommerce/woocommerce-blocks#10582

@roykho thanks for mentioning Interactivity API! I was gonna comment/update this post about it.

Currently, we're handling two cases:

1. Filter blocks are paired with All Products block, the page won't reload while filtering.
2. Filter blocks are used for Classic Template or Products (Beta) block (and Product Collection), the page will reload after customers change the filter.

With interactivity API, we can merge those two cases into one. But as we're rendering the the block on the client side using React, we still have to solve the issues mentioned in this post. To me, Interactivity API can fully replace React, removing the needs of rendering block client side. But doing so is just too risky atm. What do you think?

[imanish003]

CC: @luisherranz @DAreRodz Your feedback here could be incredibly valuable.

As I've observed on the P2 (pdnLyh-46Y-p2),

We intend to enhance the filters by making them context-aware, allowing us to query only the necessary products. This approach will improve the overall user experience by leveraging the capabilities of the interactivity API.

Given this context, I believe it's prudent for us to explore the utilization of the Interactivity API wherever feasible.

[luisherranz]

CC: @luisherranz @DAreRodz Your feedback here could be incredibly valuable.

Hey Manish, would you mind giving us a bit more context about the feedback that you want from us? It's not entirely clear to me what's the question/issue here. Thanks 🙂

[luisherranz]

If the feedback is about the Interactivity API and what Tung described in the opening post:

Ideally, the block content shouldn’t be flashing at all. We can do that if we server-side render the block [...], then render it client-side again when customers interact with it. But doing so means duplicating logic between PHP and JS,

Then, the answer is that the Interactivity API was designed specifically to solve this problem. No flashing, no code duplication.

[imanish003]

If the feedback is about the Interactivity API and what Tung described in the opening post:

Absolutely, this is precisely the information I was seeking. Thank you for providing the answer 🙌🏻

[dinhtungdu]

@senadir @mikejolley Are there any ways to prevent the fallback from rendering here? I tried returning just a string from the stock filter block (so no async request), but the fallback still renders.

[roykho]

@dinhtungdu

then render it client-side again when customers interact with it

Assuming we're using the filters with Products (beta) and Product Collection (beta), we don't need to re-render right? Because we're refreshing the page anyways right?

[dinhtungdu]

we don't need to re-render right?

We need to re-render the blocks using react to make it interactive. The initial PHP render only give use the basic markup, not the interaction part.

I think the main motivation drove us to render the filter block on the front end is:

• All Products block.
• The interactivity React gives us.

But as you mentioned above, we are:

• deprecating the All Products block (later this year).
• integrating the Interactivity API

which makes rewriting the filter blocks have more sense now.