Performance: Mini Cart block adds an additional ~40 requests on pages it is present.

[nerrad]

First reported in this WordPress Support forum thread and I've confirmed in testing. The Mini-Cart block adds an additional ~40 requests to pages that have the block present (not counting what is lazy loaded). This seems unexpected and something that should be investigated to make sure we're not loading assets unnecessarily on initial page load.

To test, I did the following (in a block theme - I used Block Canvas):

1. Made sure header template does not contain the Mini Cart block.
2. Load the home page on the frontend (assuming the home page is using the header template). Observe the number of requests.
3. Edit the header template to add the Mini Cart block.
4. Reload the home page and observe the number of requests. You'll see an increase of ~40.

This looks like it may be a regression, I don't recall this large of an overhead being present when the mini cart was first released?

[github-actions]

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

[nerrad]

cc @Aljullu or @danielwrobert do you know if anyone has investigated this?

[danielwrobert]

cc @Aljullu or @danielwrobert do you know if anyone has investigated this?

@nerrad not that I'm aware of. Looks like it's still in the backlog pipeline, possibly got lost in the shuffle (unless @Aljullu knows something more).

Do we need to flag it as a high-priority item?

[nerrad]

I think we need to at least have an assessment that finds out:

• why are these extra requests happening just with the block appearing on the page?
• how difficult of a fix would it be? Are the requests valid or is this a bug?

With this being a big jump in the number of requests, I think it needs investigated.

[Aljullu]

Sorry, I missed this issue. If I remember correctly, this has been the behavior since the beginning. The reason is that we preload those scripts after page load so when the shopper interacts with the Mini Cart, they are ready to be executed.

So:

• they are downloaded after the page is loaded and finished rendering
• they don't block or slow down page rendering and they shouldn't affect negatively the performance of the page: they are downloaded in the background, but not executed
• once they have been downloaded once, they will be in the browser cache, so in practice they are only downloaded on the first page the shopper visits

There is a slightly more in-detail explanation of this mechanism in this post: https://developer.woocommerce.com/2021/11/15/how-does-woocommerce-blocks-render-interactive-blocks-in-the-frontend/#how-about-lazy-loading-the-block-and-its-dependencies

[nerrad]

That makes sense, but there still seems to be something a bit wonky. I would assume that this means the number of requests after the mini-cart is triggered to be minimal if things are pre-loaded but I'm still seeing an additional 15 scripts loaded after the mini-cart is triggered. Including some that don't make sense including active filters-related scripts.

[Aljullu]

I would assume that this means the number of requests after the mini-cart is triggered to be minimal if things are pre-loaded but I'm still seeing an additional 15 scripts loaded after the mini-cart is triggered.

Right, you mean these ones? (They are the ones which are loaded for me when I open the Mini Cart and there are products in the cart)

When the cart is empty, there are only three scripts loaded on open. I guess it might make sense to preload them as well.

Sidenote: I do believe there are improvements we can make here, products-table-frontend.js appears duplicated, and cross-sells looks weird if we aren't displaying any cross sell. 😕

Including some that don't make sense including active filters-related scripts.

For me, I can't see any script related to filters. 🤔 Could you share exactly what file name or path that filter has?

[nerrad]

Okay I did some more testing on an updated environment using the following:

• WooCommerce 7.1.0
• WordPress 6.1.1
• WooCommerce Blocks 9.0.0
• Twenty Twenty Three 1.0 (likely doesn't matter, but for thoroughness).

Loading on the home page of the site with the default front page of TT3.

I get the following with nothing in the cart:

I get the following with items in the cart:

The filter scripts were showing on a different dev site but it may be something related to an older version of WooCore or something there (same with cross-sells, I'm not seeing it now 🤔 ).

Sidenote: I do believe there are improvements we can make here, products-table-frontend.js appears duplicated, and cross-sells looks weird if we aren't displaying any cross sell. 😕

Agreed, we should definitely avoid duplicates where needed.

Would you mind updating the Support forum thread (linked to in the main description) with an update about how the scripts are loaded and why this shouldn't be a significant "performance hit" in most cases (given the non-blocking pre-fetching of scripts on load and browser caching)? Worth noting that this is still way below "industry leaders" such as Amazon when it comes to the number of requests/MB loaded in total.

[Aljullu]

Agreed, we should definitely avoid duplicates where needed.

Completely agree. 💯

Would you mind updating the Support forum thread (linked to in the main description) with an update about how the scripts are loaded and why this shouldn't be a significant "performance hit" in most cases (given the non-blocking pre-fetching of scripts on load and browser caching)? Worth noting that this is still way below "industry leaders" such as Amazon when it comes to the number of requests/MB loaded in total.

Done. 👍

[Aljullu]

I did an audit of the scripts loaded to render the Mini Cart block and, first of all, I wanted to reiterate what I said in my comment above: even though the block has many dependencies, most of them are very small and are lazy loaded so they don't block page load. In addition to that, we only execute them (in other words, we only render the drawer contents) when we have a clear indication that the user will interact with the Mini Cart: hovering or focusing the button, adding a product to cart, etc. Lastly, most of those dependencies are shared with the Cart and Checkout blocks, so they will be cached across page views.

Having said that, it's true that there were some improvement opportunities. I'm sharing what I have found so far. Heads-up that I looked at this exploration as "improve Mini Cart performance" in general, not as "try to reduce the number of requests". The reason is that I don't think the number of requests can be reduced significantly (besides a couple of instances I mention below); however, I think there are some gains we can do to avoid blocking scripts and being more intentional preloading scripts we know will be requested.

• One script that we must get rid of is @wordpress/components. We have this meta issue which should help remove the @wordpress/components dependency from several scripts, but I created a specific one for the Mini Cart drawer: Mini Cart Block: Move away from using Modal component #8606.
• I saw we are loading lodash, but we should probably avoid that in the frontend. I opened a separate issue for this: Remove lodash dependency from frontend scripts #8642.
• Regarding the two products-table-frontend.js scripts: even though they have the same name, they aren't duplicate: one is a component and the other one the Mini Cart block which renders that component. However, the code could be simplified as the component was under the Cart block directory, instead of in base-components. I merged a PR for this: Move CartLineItemsTable from the Cart block directory to base-components #8644.
• During my research, I noticed we called wp.apiFetch.createPreloadingMiddleware() in some cases when it wasn't necessary. I merged a PR that addresses this: Only print wp.apiFetch.createPreloadingMiddleware() when needed #8647.
• We are not currently preloading several frontend scripts of the inner blocks (ie: mini-cart-contents-block/title-frontend.js is only loaded when the shopper opens the Mini Cart, even though it could be preloaded). I opened a PR that will fix this: Preload Mini Cart inner blocks frontend scripts #8653.
• We were loading many scripts on page load which were dependencies of wc-blocks-registry (see Load wc-blocks-registry at the load of the page instead of lazy load it #7813 for more context). I proposed an alternative solution that should allow us to avoid having all those scripts block page render in Remove wc-blocks-registry from Mini Cart block dependencies so more scripts can be lazy-loaded #8657.
• We are using wcSettings to pass the scripts to lazy load from PHP to JS. I'm working on an alternative approach to set a JS variable directly and then read it from the frontend. This way we wouldn't need to set wcSettings as a dependency of Mini Cart frontend scripts and it could be lazy-loaded. PR: Remove wc-settings from Mini Cart block dependencies #8703.

Given all of this, I'm going to close this issue as complete as everything I identified has open PRs (or will have them by the end of this week) or has follow-up issues.