Changes to Store API loading for performance

The Store API provides a public endpoint for customer-facing cart, checkout, and product functionality. You can read more about Store API on the GitHub documentation page: WooCommerce Store API.

When a WooCommerce block, such as the mini cart block or the product collection block is being used on a public page, we preload a response from a relevant Store API endpoint as part of the page load (See Hydration Class). This prevents an extra request and shows meaningful information to the visitor quickly. However, this would also cause slowness because we would need to perform a REST API operation as part of the page load.

From WooCommerce version 8.9 (scheduled to be released in the second week of May), we are changing this behavior to reduce the amount of code that we load (see PR: 45134). Instead of sending a request over REST API, which loads all REST API controllers, we will only load the controller we need to get the response.

In our testing, this improves performance quite a bit, especially on starter servers, or on those installations where loading REST API is expensive. While exact improvements will depend on how much time REST API loading would take in the first place, for sensitive sites, we are seeing improvements of up to 30% on pages where blocks using Store API hydration were present.

Does this change affect me?

This is a backward incompatible change, but based on our search so far, this affects only a handful of plugins at least in the marketplace. You can assess if this affects your plugin or code by checking if you use any of these filters to modify the Store API response:

  1. rest_request_after_callbacks : This filter is usually used to modify an API response before it’s sent out. If you use this filter, check if you are modifying the Store API response, it will start with paths /wc/store. If you do use this filter, you may want to use the woocommerce_hydration_request_after_callbacks as well to make sure that requests are appropriately modified in the hydration context.

    Note that we don’t encourage modifying API responses this way, it can easily lead to broken experiences when the modified response is incompatible with the client.
  2. rest_dispatch_request: Similarly, this filter is called before a REST API request executes. If you use this filter, check if you are using it in the context of store API. If so, you may want to use woocommerce_hydration_dispatch_request as well for backward compatibility.

Thanks to GitHub user https://github.com/ppwebox for originally reporting the issue. As always, please reach out to us via a comment in this post (or a new GitHub issue) for any questions, concerns or comments!


Keep yourself in the loop!

Sign up for the WooCommerce developer newsletter:
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form


5 responses to “Changes to Store API loading for performance”

  1. oh dear. That looks like it’s going to be work for all 3 of my plugins. Can you show an example of how to use the new filters correctly?

    1. vedjain Avatar

      Hey Kathy, you should be able to use new filters like the old ones, since they have same signature. So for example, if earlier you were doing:

      `add_filter( ‘rest_request_after_callbacks’, ‘my_custom_function’ , 10, 3 );`

      where the function is like:

      `function my_custom_function( $response, $server, $request ) {`

      you would now also hook the function to the new filter (along with the old one), so the code will now become:
      `add_filter( ‘rest_request_after_callbacks’, ‘my_custom_function’ , 10, 3 );`
      `add_filter( ‘woocommerce_hydration_request_after_callbacks’, ‘my_custom_function’ , 10, 3 );`

      and everything else can remain the same.

      The easiest way to test would be to load WooCommerce with your plugin on perhaps a new install with 2024 theme, and making sure that the minicart block have correct cart content (assuming they were being modified).

  2. My website is telling me to update my theme for salient child theme. I was wondering were the update is.

    1. Jacklyn Biggin Avatar
      Jacklyn Biggin

      Hey Matthew! Woo doesn’t own or manage updates for the Salient theme. I recommend contacting the theme’s creator who’ll be able to help you out!

  3. […] WooCommerce 8.9, som släpps i maj, har en förändring i Store API:t, som ska vara bakåtkompatibel men som utvecklare av WooCommerce-webbar nog bör ha ett extra litet […]

Leave a Reply

Your email address will not be published. Required fields are marked *