Conditional Loading for WordPress Snippets: Run Code Only Where You Need It

The default setting in every snippet plugin is the dangerous one: run everywhere. It is the right default for a one-line add_filter on the_content. It is the wrong default for a 40 KB slider script, a WooCommerce tax hack, and a CSS override aimed at a single landing page.

Conditional loading is how you say where a snippet is allowed to execute. WordPress 6.9 spent a lot of release energy on LCP and late styles. Globally injected snippet CSS undoes that in one save.

What you are actually conditioning

There are two layers people conflate.

Registration vs execution. A PHP snippet that calls add_action( 'woocommerce_before_cart', ... ) is already "conditional" in a weak sense: the callback only runs on the cart hook. But the snippet file still loads, parses, and registers on every request if the plugin includes it globally. On a large library, that is real PHP time.

Asset vs logic. CSS and JS do not have hooks in the same way. If you print them in wp_head with no condition, they ship to /wp-login.php, the blog, and checkout. Pixels and layout CSS are the usual offenders. See HTML vs JavaScript vs PHP snippets if the type is wrong before the condition is.

A good rule: PHP snippets should register cheaply and do work in the right hook. CSS/JS snippets should not be enqueued at all unless the request needs them.

Conditions that hold up in production

These are the ones we see agencies actually use:

• Page / singular. One landing page, one thank-you page, one legal template. Prefer a page ID or slug over "URL contains promo" — query strings and translated permalinks will fool you.
• Template / content type. All products, all posts in a category, all archive views. is_singular( 'product' ) beats a regex on the path.
• User role or capability. Staff-only admin CSS, or a logged-in discount. Check current_user_can, not wp_get_current_user()->roles[0] === 'customer' (that breaks when a user has two roles).
• Admin vs front. Half of snippet fatals we see are front-end PHP that called an admin-only function, or admin CSS that leaked to the storefront. is_admin() is not enough by itself — admin-ajax and REST are easy to get wrong.
• WooCommerce request. Cart, checkout, account. Do not run checkout-only PHP on the homepage "just in case."
• Device. Use sparingly. Server-side device detection is a lie on iPadOS and on caches that ignore the UA. Prefer CSS. WordPress 7.0's responsive block visibility is the better tool for hiding blocks; snippets should not reinvent that.

Combine conditions with explicit AND/OR groups. "Home or a landing page, and not logged-in" is a real rule. Nested ifs inside the snippet are how the next developer misses a branch.

Conditions that look smart and fail

• strpos( $_SERVER['REQUEST_URI'], 'shop' ). Breaks on pretty permalinks, language prefixes, and REST.
• "Not admin" implemented as ! is_admin(), then the snippet runs on cron and rest and starves a queue.
• Cookie-based A/B in a cached HTML page. The condition runs on the cached user, which is nobody. Use a JS snippet for the variation, or a cache-aware plugin.
• Multiple plugins conditioning the same pixel. WPCode says footer + not admin; the theme already printed it in header.php. Conditions cannot save a double insert.

How SnipVault models this

Conditional loading is group-based: you build match groups from context, route, and runtime signals, and the snippet does not execute unless a group passes. The point is to keep the rule outside the PHP so you can read it in the list view.

That list view is the underrated feature. A library of 80 snippets with "everywhere" on 70 of them is not a library. It is a second theme. Tags and project workspaces help you see that; conditions help you fix it.

If you generate a snippet with the Snippet Engineer, ask for the condition in the prompt: "CSS only on the pricing page," "PHP only when WooCommerce is active." The agent should not default to global.

Performance is the easy sell; correctness is the real one

Yes, skipping a script on 90% of pages helps INP and LCP. The better argument is blast radius.

A PHP fatal in a snippet that only loads on /checkout is a checkout incident. The same fatal on init is a site incident. We walked through recovery in fatal PHP errors in snippets. Conditional loading is what makes those two sentences different.

The same applies to security. A snippet that reads $_GET['preview_price'] should not run for anonymous users on every URL. Put the capability check in the code and put an admin-or-shop-manager condition on the snippet. Defense in two layers.

A cleanup pass you can do this week

1. Sort snippets by "runs everywhere."
2. For each CSS/JS item, name the page or template it is for. If you cannot, it is a candidate for deletion.
3. For each PHP item, check whether the hook already scopes it. If yes, you may still want a plugin-exists condition (class_exists( 'WooCommerce' )) so the snippet is inert on sites without that plugin — useful when you sync one library to many sites.
4. Move shared helpers (the ones that *should* run everywhere) into a clearly named project. Everything else earns a condition.

"Run everywhere" is a starting point, not a strategy. The sites that stay fast and stay up are the ones whose snippet list reads like a deployment manifest: this code, this context, nowhere else.