Your cart page takes 6 seconds to load and the customer is gone
Open the /cart page of your site right now. If it takes between 3 and 8 seconds for the cart and checkout button to fully appear, the customer closes the page right there. This isn't just intuition; Google data says 53% of mobile visits are abandoned when load time exceeds 3 seconds. For a WooCommerce store, that number means abandoned shopping carts, not just a lost visit.
Where's the problem? WooCommerce by default re-renders the entire cart page with every small change (changing quantity, removing an item, selecting a shipping method). This means several heavy AJAX requests to the server, each with many database queries. The solution lies in properly configuring cart fragments.
What are cart fragments and why they're dragging your site down
WooCommerce uses pieces called fragments to update the cart without a full page refresh. Each fragment is a section of HTML that needs to be reloaded after a change in the cart. The problem starts when other plugins (like shipping plugins or custom code) register new fragments, forcing WooCommerce to re-read all those sections from the database with every change.
Do you recognize the signs of this problem? If you look at the Network tab in Chrome DevTools and add an item to the cart, you'll see several ?wc-ajax=add_to_cart requests, each taking 1 to 2 seconds. This is where site admins make a mistake: they think the problem is the hosting and upgrade their plan, when the real issue is the number and size of unnecessary fragments.
Code to diagnose the problem
Add this code to the functions.php file of your child theme to see which fragments are registered:
add_action('wp_footer', function() {
if (is_cart() || is_checkout()) {
$fragments = WC_AJAX::get_refreshed_fragments();
echo '<!-- Fragments: ' . count($fragments) . ' -->';
}
});
If the number of fragments is above 10, your site is doing more work than necessary. The normal range is between 4 and 7 fragments.
Proper fragment configuration; three practical steps
Step one: Keep only the fragments that are actually used. If your theme displays the cart item count in the header, you need that fragment. If not, remove it:
add_filter('woocommerce_add_to_cart_fragments', function($fragments) {
// Remove the cart stats fragment in the header if not used
unset($fragments['a.cart-contents']);
return $fragments;
});
Step two: Caching the cart page for logged-out users. WooCommerce by default doesn't cache the cart page for logged-in users because each user's information is different. But for guest users who haven't logged in yet, you can enable caching. If you use a caching plugin like WP Rocket or LiteSpeed Cache, enable the "cache for guest users" option. This alone can reduce cart page load time by up to 40%.
Step three: Disabling unnecessary scripts on the cart page. WooCommerce loads many scripts on all pages, even where they're not needed. This code loads only the scripts needed for the cart on that specific page:
add_action('wp_enqueue_scripts', function() {
if (is_cart()) {
wp_dequeue_script('wc-checkout');
wp_dequeue_script('wc-city-select');
}
}, 20);
Caching checkout pages; where everyone makes mistakes
Never fully cache the checkout page (/checkout). This page contains security forms, payment fields, and CSRF tokens that are unique to each user. Caching it means the next customer sees a form whose token has expired, and payment fails with an "invalid token" error.
However, you can cache the static sections of the checkout page: logo, help texts, icons. Do this by caching static assets (CSS and JS), not the entire HTML of the page. Caching plugins usually have an option to "exclude checkout page from cache." If you don't see such an option, add this code to wp-config.php:
define('DONOTCACHEPAGE', true);
This constant tells all reputable caching plugins not to cache this page. But if you want only the checkout page excluded from cache while the rest of the site remains cached, use the following filter:
add_filter('woocommerce_checkout_redirect_empty_cart', function() {
if (!is_user_logged_in()) {
// Redirect guest user to cart page
return true;
}
return false;
});
The role of the database in WooCommerce speed; something nobody checks
After configuring fragments, it's time for the database. WooCommerce runs several queries against the wp_options and wp_postmeta tables for each AJAX request. If your store has more than 10,000 orders and each order has 20 metadata entries, your wp_postmeta table has over 200,000 rows. Without proper indexes, each query on this table takes several hundred milliseconds.
Run this query in phpMyAdmin to see which tables are heavy:
SELECT table_name, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'MB'
FROM information_schema.tables
WHERE table_schema = 'your_db_name'
ORDER BY (data_length + index_length) DESC LIMIT 10;
If wp_postmeta is above 500 MB, it's time to clean up. Plugins like WP-Optimize can remove orphaned metadata (rows not connected to any post). This usually reduces database size by 20-30% and noticeably speeds up queries.
Measuring before and after; without numbers, no optimization means anything
Before making any changes, take a baseline measurement. Use speed testing tools and note the TTFB (Time To First Byte) value. If TTFB is above 800 milliseconds, the problem is server-side and fragment configuration won't help. First, you need to check the hosting.
After applying the changes, measure again. The numbers you should see: TTFB below 400 milliseconds and full cart page load time below 2 seconds. If you don't reach these numbers, there are two possibilities: either you have a heavy plugin sending external requests (like calls to third-party APIs), or your theme is loading unnecessary scripts.
To diagnose, open Chrome DevTools, go to the Performance tab, and refresh the cart page. Look for requests that take more than 500 milliseconds. Usually, the culprit is requests to external domains (like Google Fonts or third-party CDNs). You can disable these requests with a plugin like Asset CleanUp.
An explicit choice: full page caching or fragment caching?
If your store has fewer than 500 products and daily traffic is under 10,000 visits, full page caching for product and category pages is sufficient, and you don't need to touch fragments. But if you have a large store and customers constantly modify their carts, fragment caching works better than full caching.
Full caching of the cart page for guest users is a common mistake. WooCommerce stores the cart in the user's session, not in a cookie. If you cache the cart page, the next user will see the previous user's cart. This is exactly the bug where a customer calls and says, "Why is my cart full of things I didn't buy?"
The safe approach: use fragment caching and only cache sections that are identical across all users. WooCommerce does this itself with fragments; you just need to reduce their number.
Infrastructure; when everything is correct but the site is still slow
Sometimes after all these configurations, the site is still slow. This is where you need to look at the infrastructure. If you're using shared hosting and your site has more than 50,000 monthly visits, it's time to migrate to WordPress hosting with more dedicated resources. WooCommerce on shared hosting with CPU and RAM limitations can't load under 2 seconds even with the most optimized code.
Before migrating, run this test: in your current hosting panel, check CPU usage during peak hours. If it's above 80%, the problem is infrastructure. If it's below 40%, the problem is your code, and migration won't help. Take this distinction seriously; many people pay for migration and then realize the problem was a poorly coded plugin.
For continuous speed monitoring, set up an uptime monitoring tool that checks the cart page every 5 minutes and emails you if load time exceeds 3 seconds. You can do this with free monitoring tools. See the guide on website uptime monitoring to set up alerts without false positives.
Frequently Asked Questions
Why is my WooCommerce cart page slow?
Cart page slowness usually has three causes: too many cart fragments that re-render with every change, lack of caching for guest users, and a heavy database due to extra rows in wp_postmeta. Check all three with the instructions in this article.
Is caching the WooCommerce checkout page safe?
No. The checkout page contains one-time security tokens generated for each user. Caching it causes an "invalid token" error during payment. Only cache the static assets of this page, not the entire HTML.
How do I reduce the number of cart fragments?
By adding the woocommerce_add_to_cart_fragments filter to the functions.php of your child theme, you can remove unnecessary fragments. First, check the current count with the diagnostic code provided in the article, then keep only the fragments your theme actually uses.
What's the difference between TTFB and full load time?
TTFB is the time the server takes to send the first byte of the response. Full load time is the total time until all page elements are displayed. If TTFB is high, the problem is the server or database. If TTFB is low but full load time is high, the problem is the size of scripts and images.
Comments 0
No comments yet — be the first!