When “Add to cart” is slow, it’s either the add itself that takes time, or the requests WooCommerce sends afterward to update the cart in the header. Often it’s the latter, and it doesn’t only affect the button: on many stores, every single page sends an extra request that can’t be cached, ?wc-ajax=get_refreshed_fragments.
This guide covers what happens when a customer adds a product to the cart, how to find out where the time goes, and what you can do about cart fragments, the cart calculation and sessions.
What happens when a customer clicks “Add to cart”?
On category pages, WooCommerce usually adds the product with a background request, ?wc-ajax=add_to_cart. On the product page, the form is submitted and the page reloads. Either way, WooCommerce does the same thing: it creates a session for the customer if there isn’t one, adds the product, recalculates the totals and sends back the updated parts of the page, such as the mini cart in the header.
From that moment, the customer has a cart, and many page caches stop serving cached pages to them. Everything they see after that is built from scratch. Why that is is covered in our guide to WooCommerce caching.
Find out where the time goes
Open your browser’s developer tools (F12), go to Network, and add a product to the cart. Look for three requests:
| Request | What it does |
|---|---|
?wc-ajax=add_to_cart or the product page itself | The add and the cart calculation |
?wc-ajax=get_refreshed_fragments | Fetches the updated mini cart. Can also appear on ordinary page views |
Calls to /wp-json/wc/store/v1/ | The newer Mini-Cart block, which fetches the cart through WooCommerce’s Store API |
The one that takes longest is where you look. Also open an ordinary page without touching the cart, and see whether get_refreshed_fragments is sent anyway.
Cart fragments and get_refreshed_fragments
Cart fragments is WooCommerce’s script for keeping the mini cart up to date, even on pages served from the page cache. It does this by asking the server for the cart with ?wc-ajax=get_refreshed_fragments. That request can’t be cached, so it goes through PHP and the database every time. If it runs on every page view, every visitor sends an extra uncacheable request per page, including those with nothing in the cart.
Since WooCommerce 7.8, the script is only loaded on pages that show WooCommerce’s Cart widget, according to WooCommerce’s own best practices for the cart fragments API. But many themes and page builders show a mini cart in the header on every page, and then it’s loaded everywhere again. The same goes for plugins that request it themselves.
What you can do depends on what the header needs to show:
- If the header only needs to link to the cart, use a cart icon with no contents, and the script isn’t needed.
- If it needs to show the count and contents, consider WooCommerce’s Mini-Cart block, which fetches the cart through the Store API, or a theme that only asks the server when the customer has a cart.
- If you use a performance plugin that can turn off cart fragments, test afterward that the count in the header is still right on cached pages after the customer has added something.
When the add itself is slow
If it’s add_to_cart that takes time, the cause is in the cart calculation. Every time the cart changes, WooCommerce runs through prices, discounts, tax and often shipping, and plugins can hook into each step. Typical culprits are plugins for quantity discounts and dynamic pricing, B2B pricing, bundles and add-ons, and plugins that check stock against another system while the customer waits.
These are the same mechanisms that slow down checkout, and the approach is the same: find the slow request, and see which plugins use the time in it. It’s in our guide to a slow WooCommerce checkout.
Sessions in the database
When a customer adds something to the cart, WooCommerce stores the cart in the wp_woocommerce_sessions table, with a cookie pointing to it. Expired sessions are cleaned up by a scheduled job. If WP-Cron doesn’t run, or rarely runs, the table grows and lookups in it get slower. Why WP-Cron should run from the server is covered in the section on background jobs in the troubleshooting guide.
Bots can create sessions too. If a crawler follows links with ?add-to-cart=, it adds products to the cart and gets a session for each. Check the server’s access log for many of those requests from bots, and ask your hosting provider to block them.
Both the sessions and the cart calculation get faster with an object cache, because much of the data WooCommerce looks up is then in memory. The setup is in our guide to the Redis object cache.
Frequently asked questions
Can I just turn off cart fragments?
Yes, if the mini cart doesn’t need to be up to date on cached pages. Otherwise you risk the header showing an empty cart even though the customer has added something. Test it in a private window before it goes live.
Why is the product page slow after I add something to the cart?
Because many page caches step aside as soon as there’s a cart. The page is built from scratch, and that shows how fast the server is without a cache. Those are the pages that need to get faster.
Want help?
A slow cart hits customers at the moment they’ve decided to buy. If you’d like us to find out where the time goes in your store, read about optimizing a slow WooCommerce store. We take a free look at your store first and tell you what it will take.