Beyond `wp_enqueue`: Surgical Asset Management for High-Performance Sites

A lot of WordPress® plugins follow the path of least resistance. They enqueue their CSS and JavaScript globally to ensure their features “just work” on every page. While this approach is safe for the developer, it’s less than ideal for site performance. Every unused byte of JavaScript adds to the browser’s execution time. This negatively impacts Total Blocking Time (TBT) and Largest Contentful Paint (LCP).

In this guide, we discuss how to move past basic script registration. We will look at how to interrogate the internal WordPress script queue and surgically remove the assets your visitors don’t actually need.

The Baseline: Contextual Loading

The first line of defense is ensuring your own code only loads when necessary. Don’t forget that the wp_enqueue_scripts hook is simply an action. You can wrap your enqueues in logic to restrict them to specific contexts.

Using Conditional Tags prevents scripts from loading where they aren’t needed. For example, if you have a heavy script that only runs on a specific “Contact” page, there’s no point in loading it everywhere else.

add_action( 'wp_enqueue_scripts', function() {
    // Only load the heavy Map script on the Contact page
    if ( is_page( 'contact' ) ) {
        wp_enqueue_script( 'google-maps-api', 'https://maps.googleapis.com/...', array(), null, true );
    }
});

Using is_page(), is_single(), or even has_block() allows you to implement “Just-in-Time” loading. This keeps your initial page weight low.

Peeking Inside the `$wp_scripts` Global

The real performance bottleneck often comes from third-party plugins. To stop them, you first have to identify their handles. You can spend a big chuck of time hunting through plugin source files if that’s what floats your boat, but it’s probably faster to just look at the internal state of the WordPress script manager.

WordPress uses the WP_Scripts class to manage the queue. During the page lifecycle, a global variable called $wp_scripts holds every registered and enqueued script.

Identifying the Bloat

You can interrogate this global object to see exactly which handles are enqueued for the current request. To use the following snippet, you can add it to a custom plugin used on a staging site or in a local development environment.

It is important to use the wp_print_scripts hook. This hook fires right before WordPress begins printing scripts into the header. This timing ensures that every plugin has finished its enqueuing logic, giving you a complete picture of the final queue.

Run in Local or Staging Environments

You should only run this code in a non-production environment, such as a local install or a staging site.

Local vs. Staging: While a local site is “safe,” a staging site is often superior for this audit because it perfectly mirrors your production plugin configuration and database state.
Why Not Production? This snippet outputs data directly into your site’s HTML source code. On a live site, this looks unprofessional to visitors and can reveal your specific plugin stack to malicious actors. Additionally, running debug logic on every page load adds unnecessary overhead to your server’s performance.

add_action( 'wp_print_scripts', function() {
    // Only run this if we are logged in as an admin to add an extra layer of privacy
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }

    global $wp_scripts;

    // Check if the WP_Scripts class has enqueued handles [cite: 6]
    if ( ! empty( $wp_scripts->queue ) ) {
        // Output the enqueued handles to the browser's JavaScript console
        echo '<script>console.log("Delicious Brains Audit - Enqueued handles: ' . implode( ', ', $wp_scripts->queue ) . '");</script>';
    }
});

By inspecting the queue property of the $wp_scripts object, you can find the exact strings needed to target specific plugin assets.

Programmatic Dequeuing: The Surgical Strike

Once you have identified your target handles, you can use wp_dequeue_script() to remove them. However, success depends a lot on priority.

In WordPress, hook priorities act like a waiting list where a higher number executes later. Since most plugins enqueue assets at the default priority of 10, you should hook into wp_enqueue_scripts with a much higher number (like 100) to ensure your removal logic runs after the plugin’s loading logic.

Example: Pruning Plugin Bloat

Suppose a “Reviews” plugin is loading a 150KB JavaScript file on your homepage. If reviews only exist on your product pages, you can strip that script everywhere else.

add_action( 'wp_enqueue_scripts', function() {
    // If we are on the Home page, remove the Reviews asset
    if ( is_front_page() ) {
        wp_dequeue_script( 'plugin-reviews-js' );
        wp_dequeue_style( 'plugin-reviews-css' );
    }
}, 100 ); // High number = runs later

For aggressive plugins that still manage to load, you can swap to wp_deregister_script(). This is a more permanent “nuclear” option that completely unbinds the handle from its source file for that specific request.

The Dependency Trap

Before you start pulling the plug on every script you see, you must check for dependencies. The wp_enqueue_script() function allows you to define a list of other scripts that must load first.

You’ll break the site’s functionality if you dequeue a script that other enqueued scripts depend on. The browser will throw “not defined” errors in the console. Always check the registered property within the $wp_scripts global to see the dependency array for a specific handle before removing it.

Conclusion

Advanced asset management is a game of subtraction. By auditing the WP_Scripts global and implementing high-priority conditional dequeuing, you can significantly reduce the weight of your frontend. This surgical approach ensures your site stays fast and lean without sacrificing the plugin functionality you need.

This entry was tagged WordPress.