You installed a side cart plugin to speed up the shopping experience. Add to cart, slide open, keep browsing. No page reloads. No friction.
But here’s the thing: if that side cart plugin runs on jQuery, it’s doing the opposite of what you hired it to do. It’s adding weight. Slowing down page loads. Conflicting with your theme. And quietly costing you conversions every single day.
Let’s talk about why.

jQuery in 2026: The Plugin Tax Nobody Mentions
jQuery was the backbone of WordPress for over a decade. Every plugin used it. Every theme loaded it. It worked.
But WordPress itself started moving away from jQuery back in 2020. The block editor doesn’t use it. Modern themes don’t need it. WooCommerce is actively migrating its own blocks to a new standard called the Interactivity API.
So what happens when your side cart plugin still requires jQuery?
- Extra JavaScript loaded on every page. jQuery is 87KB minified. That’s 87KB of code your store loads whether it needs it or not.
- Full DOM manipulation on every cart update. jQuery doesn’t know what changed. It redraws everything. Every add-to-cart, every quantity change, every coupon applied: the entire cart re-renders.
- AJAX round trips for every action. Click “add to cart,” wait for a server request, wait for the response, then watch the cart rebuild from scratch. That’s 300-800ms of delay per interaction.
- Theme and plugin conflicts. jQuery version mismatches are the #1 cause of WooCommerce plugin conflicts. If your theme loads jQuery 3.6 and your cart plugin expects 3.5, things break.
None of this is theoretical. Run a PageSpeed Insights test on your store with your side cart plugin active, then deactivate it and run it again. The difference will surprise you.
What the Interactivity API Actually Is
WordPress 6.5 introduced the Interactivity API as a stable, core feature. It’s WordPress’s answer to a simple question: how should plugins handle dynamic, interactive front-end behavior in 2026?
The short answer: reactively.
Instead of loading a heavy JavaScript library, manipulating the entire DOM, and making round trips to the server for every click, the Interactivity API works differently:
- Declarative. You define what should happen when state changes. The framework handles the rest.
- Reactive. Only the specific elements that changed get updated. Not the whole cart. Not the whole page. Just the price that changed, or the quantity that updated.
- Built into WordPress core. No external libraries. No jQuery. No React bundle. It’s already there.
- Server-aligned. It uses the same rendering on the server and the client, so there’s no flash of unstyled content or layout shift.
This is the same architecture that WooCommerce is building its own blocks on. WooCommerce’s own Mini Cart Block moved to the Interactivity API in WooCommerce 9.6. The product collection blocks followed. The checkout blocks are next.
WooCommerce is betting its entire front-end future on the Interactivity API. That’s not speculation. It’s on their public roadmap.
The Performance Gap: jQuery AJAX vs. Interactivity API
Let’s get specific about what this difference looks like in practice.
jQuery/AJAX side cart (typical):
- Customer clicks “Add to Cart”
- JavaScript intercepts the click
- AJAX request sent to the server (~100-200ms)
- Server processes the request (~50-150ms)
- Server sends back the full cart HTML (~100-200ms)
- jQuery removes the old cart from the DOM
- jQuery inserts the new cart HTML
- jQuery re-initializes event listeners
- Cart is ready (~300-800ms total)
Interactivity API side cart (Caddy 3.0):
- Customer clicks “Add to Cart”
- Cart state updates via WooCommerce Store API
- Only changed elements re-render (~50-100ms)
- Cart is ready
That’s not a marginal improvement. It’s a fundamentally different approach.

On mobile (where 60-70% of WooCommerce traffic comes from), that 300-800ms delay compounds. Every interaction feels sluggish. Every sluggish interaction increases the chance of abandonment.
Where the Major Side Cart Plugins Stand
Here’s the reality of the WooCommerce side cart market in 2026:
| Plugin | Architecture | jQuery Required | Cart Update Method |
|---|---|---|---|
| XootiX Side Cart (80K installs) | Traditional | Yes | AJAX reload |
| FunnelKit Cart (20K installs) | Traditional | Yes | AJAX reload |
| Modern Cart by Brainstorm Force | Traditional | Yes | AJAX reload |
| CartPops (4K installs) | Traditional | Yes | AJAX reload |
| Addonify Floating Cart (10K installs) | Traditional | Yes | AJAX reload |
| Caddy 3.0 (4K installs) | Interactivity API | No | Reactive re-render |
Every major side cart plugin except Caddy still runs on jQuery and traditional AJAX. Every single one.
That’s not a knock on those plugins. They were built when jQuery was the standard. But the standard has changed. WordPress core moved on. WooCommerce moved on. These plugins haven’t.
Why This Matters for Your Store (Not Just Developers)
You might be thinking: “I’m not a developer. I don’t care about APIs and JavaScript frameworks.”
Fair. Here’s what you should care about:
Speed affects revenue. Google’s research shows a 1-second speed improvement can increase mobile conversions by up to 27%. Portent found that conversion rates drop 0.3% for every additional second of load time. A side cart that adds 300-800ms of delay to every cart interaction is working against you.
Compatibility is getting worse, not better. As WordPress and WooCommerce move further toward the Interactivity API and block-based architecture, jQuery-dependent plugins will hit more conflicts. More broken carts. More support tickets. More lost sales on a random Tuesday when a WooCommerce update breaks your cart.
Mobile performance is non-negotiable. Your customers are shopping on 4-year-old phones with spotty connections. jQuery’s weight hits hardest exactly where your traffic is highest.
What to Look for in a Side Cart Plugin
Whether you choose Caddy or not, here’s what to check before installing any side cart plugin in 2026:
- Does it require jQuery? Check the plugin’s dependencies. If it enqueues jQuery, it’s adding weight.
- How does it update the cart? AJAX reload = slow. Reactive re-render = fast.
- Does it work with block themes? If it relies on classic theme hooks (wp_footer, wp_head), it may break on newer themes.
- Is it HPOS compatible? WooCommerce High-Performance Order Storage is the new standard. Plugins that don’t support it will break.
- What’s the JavaScript footprint? Use your browser dev tools (Network tab, filter by JS) to see how much JavaScript the plugin adds.
Caddy 3.0: Built for Where WooCommerce Is Going
Caddy 3.0 was rebuilt from scratch on the WordPress Interactivity API and WooCommerce Store API. Not wrapped around them. Not adapted to them. Built on them.
- Zero jQuery dependency
- Instant reactive cart updates (only changed elements re-render)
- Works with classic themes and block themes
- HPOS compatible
- Built-in WP Rocket cache handling
- The same modern architecture WooCommerce uses for its own blocks
The free version is on WordPress.org right now. It includes the sticky side cart, free shipping meter, in-cart product recommendations, save for later, and coupon field.
If you want multi-tier rewards (free shipping at $50, free gift at $75, discount at $100), the announcement bar, custom icons, and Google Analytics integration, Caddy Pro starts at $99/year.
Try Caddy Free on WordPress.org | See Caddy Pro Features

Your side cart should make shopping faster, not slower. If yours is still running on jQuery, it’s time to ask why.