Available on requestPerformance· WooCommerce

TurboBlocks

Disable unused CSS and JavaScript on WooCommerce sites with per-page rules and context-aware detection. Reduce page weight and improve Core Web Vitals without breaking checkout.

Pricing on request

Why it exists

WooCommerce enqueues assets on the assumption that any page might be a shop page. wc-cart-fragments, wc-add-to-cart, the Woo Blocks vendor bundles and every payment gateway's script load on your homepage, your blog posts and your landing pages — pages where none of that code has anything to do.

The usual fix is a generic "disable scripts per page" plugin. Those work until they do not. They treat every handle as interchangeable, they have no idea what a mini-cart widget is, and the failure mode is that somebody dequeues wc-cart-fragments on a page that turns out to contain a cart block, and the store quietly stops working for a subset of visitors. That failure is easy to cause and hard to notice.

TurboBlocks is built around that specific risk. It knows what WooCommerce's handles are for and checks whether the current page actually needs them before removing anything.

What it does

Smart WooCommerce kill switch backed by content-aware detection
Keeps Woo handles on pages containing a mini-cart widget, Woo shortcode or woocommerce/* block
WooCommerce asset catalogue covering Core, Blocks, Stripe, PayPal and shipping handles
Each catalogued handle declares the conditions it requires, so decisions come from data rather than a hardcoded list
Rules engine scoping by URL match, URL regex, post type or WooCommerce context
Every rule can be inverted — “everywhere except the shop” is a checkbox, not a regex
Six developer filters for anything the defaults do not cover
Admin organised as Quick Optimization, Quick Disable, Custom Rules and Debug
Debug view shows what would be removed before you commit to removing it

Why it matters

Page weight is the most common cause of failing Core Web Vitals on WooCommerce sites. Cutting unused assets is the highest-leverage fix available, and the only reason it is not done more often is the risk of breaking checkout.

How it works

The detection layer is what makes this different from a generic dequeue plugin. It answers questions like: is a mini-cart widget present on this page — classic widget, block, or FSE template part? Does the content contain a cart-rendering shortcode or block? Any woocommerce/* block at all? Are we on a single product, the cart, the checkout, the account page or the shop?

Those answers become detection keys. A catalog entry such as wc-cart-fragments declares requires: ['cart_fragments']. On a non-Woo page the kill switch evaluates that key against the rendered content. True means keep. False means dequeue. The decision is made from what is on the page, not from what the URL looks like.

The admin screen is organised as Quick Optimization, Quick Disable, Custom Rules and Debug. The Debug view is the one to use first: it shows what would be removed before you commit to removing it.

Six filters are available for extending it:

  • zntb_woo_catalog — register handles for Woo extensions not covered by default
  • zntb_detection_check — implement custom detection keys, such as whether a Klaviyo form is on the page
  • zntb_should_dequeue — short-circuit any individual decision
  • zntb_woo_kill_switch_skip — keep Woo assets on a specific request, useful for a campaign landing page that uses Woo components
  • zntb_protected_handles — mark handles as untouchable
  • zntb_detection_post_contents — adjust which posts get scanned for shortcodes and blocks

Requirements and limits

WordPress6.0 or higher
PHP7.4 or higher
WooCommerceOptional — Woo behaviour activates when it is present
  • Licensed GPL-2.0-or-later

What it does not do

This reduces page weight by not loading unnecessary assets. It does not minify, combine, defer or inline anything, and it is not a caching plugin.

Per-handle async and defer actions, a multi-page scanner and a measured “X KB saved” figure are on the roadmap and are not in the current build — so the plugin cannot yet tell you the size of what it removed.

Detection reads the rendered content of the current request. Assets injected by JavaScript after load are outside what it can see. As with any asset-removal tool, test checkout end to end after configuring it.

Frequently asked questions

Will this break my checkout?

The kill switch only acts on pages that are not Woo pages, and keeps any handle whose detection conditions are met. Use the Debug view first and test a full checkout before going live.

Does it need WooCommerce?

No, but the Woo-specific features only activate when WooCommerce is present.

How is this different from a caching plugin?

A caching plugin serves the same page faster. TurboBlocks makes the page smaller by not loading CSS and JavaScript that page never uses. They solve different problems and are usually run together.

What about my payment gateway?

Stripe and PayPal handles are in the catalogue with declared conditions. Other gateways can be registered through the zntb_woo_catalog filter.

Can I keep Woo assets on one specific page?

Yes — the zntb_woo_kill_switch_skip filter, or a custom rule with an inverted scope.

Does it minify or combine files?

No. It decides what loads. Combining and minification are a different job.

How do I get TurboBlocks?

It is not in the WordPress.org directory yet. Contact us for a packaged build, or to have it configured against your store.

Interested in TurboBlocks?

Tell us about your site and we will send you a build or quote the work.